December 2010 - Posts - The IT Governance Evangelist

This Blog

Home
Contact

Syndication

December 2010 - Posts

Who is Responsible for Failed Projects, The Biz or IT?

Published: December 21 2010, 10:09 AM | 2 Comment(s)
by Steve Romero

Who is responsible for failed projects in your enterprise? I have found very few organizations with a ready answer to this allegedly simple question because it is anything but simple. At the risk of excusing a rampant lack of accountability, consider the following:

Most organizations don't even use the "f-word" and failure is not even in their vernacular, let alone something they track http://bit.ly/9K9MDQ
Even if they use the f-word, I have found few organizations with a consistently applied definition of a "failed project"
Given the numerous if not countless number of people involved in most projects, how can you assign singular responsibility if the effort fails?

I've broached the subject of project failure on numerous occasions. My latest foray into this unpopular topic is inspired by an @standishgroup tweet I received last week:

43% of IT executives believe the executive sponsor owns the responsibility of a failed project

There were a number of things about the tweet that instantly piqued my interest. The first aspect I found interesting was the use of the word "believe." This implies the IT executives are of the opinion that the executive sponsor should be held responsible. The tweet does not answer the question of who is actually being held responsible. The second aspect was yet another implication: that these IT executives were being defensive and possibly deflecting the blame for failed projects. And the aspect I found most intriguing was, who do the other 57% believe is responsible?

I have personally experienced and continue to witness the finger-pointing between IT and the business when it comes to failed projects. I can still remember efforts to establish the convention of assigning both a business-sponsor as well as an IT-sponsor to every project. As soon as we overcame that hurdle we ran smack dab into the next challenge of determining who was in-charge when. When our attempts to identify the responsibility boundaries and demarcations devolved into an Abbott and Costello "Who's on first?" routine, we settled on the shared co-responsibility approach. We soon found ourselves right back at the square-one finger-pointing issue that launched us on our responsibility assignment quest in the first place. My guess is that the Standish Group tweet is along these same lines.

So who is responsible for failed projects? Is it the executive business sponsor who identifies and articulates the need and oversees its delivery? Or is it the executive IT sponsor who validates feasibility and defines and executes the means by which the endeavor will be accomplished? My answer: neither.

Before I give you my rejoinder we need to first fix the question. The question should not be who is responsible. Check out Merriam-Webster's definition(s) of the word:

Responsible:

1a: liable to be called on to answer

1b: liable to be called to account as the primary cause, motive, or agent

1c: liable to legal review or in case of fault to penalties

Projects fail for numerous reasons. How can one person be liable for the failure each and every time? The responsibility of the failure can only be determined in a post-mortem. The word that should be used in the question is accountable. Let's look at Merriam-Webster's definition:

Accountable:

1: subject to giving an account: answerable

I want to know who should be held accountable for a project failure. This is the person who is answerable independent of whomever or whatever is responsible for the failure. Though the executive business or IT sponsor could be responsible for the failure, I don't necessarily hold them accountable. So who is accountable? The Executive Project and Portfolio Management (PPM) Steering Committee.

Recall their charter from one of my previous blog posts http://bit.ly/d68Ngz and the main activities associated with PPM (described in even more detail in another post http://bit.ly/9G1xzR):

Should we? Is the investment in the best interest of realizing our strategy?
Can we? Does our organization have the capacity and capability to undertake the investment?
Are we? Once approved, are we making the progress required to realize the projected value of the investment?
Did we? Once completed, did the investment deliver the expected value?

These are the questions that must be asked and answered by the PPM Executive Committee to ensure their portfolio of investments delivers appropriate value. This executive decision-making body decides if the effort should be approved in the first place. This group monitors project progress to ensure it is on track or if it needs fixing or killing. And this group is responsible for the benefits realization to determine if their other decisions were correct and achieved the desired outcome. I contend that if the project fails, then the PPM Executive Committee made an incorrect decision during the course of the project, and they should be held accountable.

If assigned accountability, this decision-making body will likely dig deep to determine responsibility for project failure. They will need to investigate the failure to determine:

Why did we approve the failed effort in the first place?
Why didn't we fix or kill the project before it ended in failure?
What can we learn from this failure to improve our ability to make the decisions required to decrease the potential of future project failure?

I guarantee if you hold these executives accountable for project failures, they will be thoughtful and thorough before they approve projects. They will stay involved during project execution to ensure they are progressing as planned and the projected value is still attainable. They will ensure benefits realization processes are in place to prove they made the right decisions and learn from their wrong decisions. They will accomplish each of these critical objectives by fostering and performing the rigorous investment governance that only Project and Portfolio Management can provide.

Executive ownership of project success accountability and sound PPM practices will eliminate the finger-pointing that too often results from failed projects. And the less time we spend pointing fingers, the more time we can devote to solving the epidemic of project failures.

Steve Romero, IT Governance Evangelist

Share this post:

By: Steve Romero
Steve Romero is the IT Governance Evangelist at CA Technologies, Inc. His mission is to help enterprises realize the full potential of their IT investments for strategic and competitive advantage. In this capacity, he acts as a strong advocate for the customer, speaking around the world to users, prospective...
Read More..

IT Business Innovation

Published: December 09 2010, 01:29 PM | 1 Comment(s)
by Steve Romero

In my last post I discussed the agility aspect of IT agility and innovation. As promised, this post is devoted to IT innovation. And just as there were two types of IT agility (IT's ability to move with quick easy grace and IT's ability to enable the business to move with quick easy grace), there are two types of IT innovation:

Introducing something new in IT
Introducing something new in the business

IT and innovation have gone hand-in-hand since the first mechanical relay closed to change that binary zero to a one. Innovation was a hallmark of IT long before my first job as a data-processing technician more than 30 years ago. What appears to be new is the need for IT to enable business innovation. I have lost count of the number of the experts and pundits who are forecasting the demise of every CIO who doesn't "step up" and contribute to if not drive business innovation.

I said, "appears to be new" because this oft labeled "future state of IT" is being characterized as a shift. The calls are for IT to "change" from antiquated "business-enabler" to revolutionary "business innovator." This aggravates me to no end. What has IT been doing for the past 40 years if not continually innovating the business it supports?

I think the answer to that question lies in the wide-spread perception of IT being separate from the business. I believe this "us-and-them" mentality, which has been epidemic on both sides of the fence for years, prevents us from realizing that every innovation inside of IT is by definition an innovation inside of the business that reluctantly pays its bills.

I've dedicated numerous posts to IT Governance enabled IT-business alignment so I have no intention of going down that rabbit hole here. I have lamented it more than enough so I will choose to go with the flow and focus on solving this teeth-gnashing problem.

Let's start with one of the best illustrations of this "future state" by looking at this quote from the CIO Executive Council's December 2010 "Future State of the CIO" study:

"The Future-State CIO® will not only be accountable for IT function success and business process transformation, but will adopt a more company-external focus and concentrate the majority of his/her time on using information to drive innovation and strategic advantage in pursuit of business goals."

That sounds like a good idea to me. (See, I'm going with the flow.) So what's in the way of such a great idea? Try these obstacles on for size:

The greatest benefit of IT is in its potential to enable business innovation, but the majority of businesses do not look to IT for its innovative value.
Anyone can innovate but few people are empowered to be innovative. (No formal mechanisms to foster and develop ideas.)
Innovation offers incredible promise and potential but most organizational cultures are risk averse and/or afraid of failure.

In regard to the first obstacle, consider the following:

"IT's contribution to efficiency is deemed more important than its innovative value." According to the ITGI 2008 Survey of 255 Non-IT Executives
Only 25% of respondents said the CIO's primary role in innovation is to drive new business value. Only 55% viewed the lead IT executive as both a business and IT leader. According to the Diamond Consulting 2010 Survey of 724 senior business and IT Executives
42% of IT orgs said that they reported to the CFO, and 53% of CFOs said that they would like to move to this reporting arrangement. According to the 2010 Gartner/FERF Technology Study

If IT is to have any chance of participating in or driving business innovation, doesn't the business first need to view IT as a source of business innovation? (I threw that third bullet in because I don't think CIOs are sent to report to the CFO so they can drive business innovation. They're sent to the CFO so they can have the cost pummeled out of them.)

So while IT is waiting for all of those business leaders to read the articles on the "IT organizations of the future," IT can prepare itself for the day the business actually looks to IT to help drive business innovation. Here are three things I suggest:

Understand the business

"what" (products, technologies and services created)
"who" (customer segments and needs served)
"how" (operating processes and capabilities employed)
"where" (the channels used to go to market

Understand innovation - to empower everyone in the organization to innovate

Innovation is a process that must be fostered and managed
Innovation is the competency to combine market-winning ideas with capabilities wherever they exist

Understand IT Innovation: creating business value by doing something new with IT

Technology infrastructure improvements
Business process improvements
New products, services, channels

That last sub-bullet is the jackpot of IT-driven business innovation. But if IT is to have any chance of driving new products, services, and channels it needs to master the very first bullet - understand the business.

There are tons of great articles on innovation. One of my favorite came out of the Kellogg School of Management at Northwestern University. It was written by Professor Mohanbir Sawhney and Professor Robert C. Wolcott of the Kellogg Innovation Network. It is called, "The Seven Myths of innovation" and it was published in the Financial Times - "Mastering Innovation" August 2004. Don't be dissuaded by the date, it is a timeless piece of work. It is a quick-read to help you understand innovation and take the first steps to empower your organization to be innovative. I especially love the discussion of homes, processes, and mechanisms to enable innovation. It's in the public domain but let me know if you have trouble finding it.

In regard to the third obstacle I listed above, the professors talk about the problem of culture-based-failure-aversion in their article. I have also broached the subject on numerous occasions and I have included a link to a post I dedicated entirely to the subject:

http://community.ca.com/blogs/theitgovernanceevangelist/archive/2010/10/07/learn-from-failure.aspx

As if the subject of IT-driven Business Innovation wasn't complicated enough, I'll leave you with this chicken-and-egg dilemma:

IT & business innovation collaboration actually fosters greater understanding of the business in IT and greater appreciation of IT's role in business innovation.

Now we just need the business to enable IT to enable business innovation so they can have an appreciation of IT's role in business innovation which would have placed IT in a position to enable business innovation in the first place.

Can you hear my teeth gnashing? Oops! Go with the flow...go with the flow...