Published: July 02 2009, 09:22 AM | 1 Comment(s)
by Steve Romero

I have written a number of posts discussing the rate of IT project failure. According to every study I have seen over the past 10 years, at least half of all IT projects fail. I believe there are many factors that contribute to this trend but during a recent interview with SearchCIO http://bit.ly/3w5S3, Kristen Caretta asked me to choose one. Whenever I am asked this question I always cite the lack of sound Project and Portfolio Management (PPM). I have seen few organizations that have the appropriate decision-making processes and relationships to ensure their IT investments are reasoned and rational.

Sound PPM enables enterprises to determine the optimal mix and sequencing of proposed programs and projects to best achieve the organization's overall goals. PPM enables investments to be expressed in terms of hard economic measures, aligned to business strategy goals, while honoring constraints imposed by management or external real-world factors. Without this capability, I argue many projects are doomed before they begin.

My discussion with Kristen reminded me of a recent visit I had with a CIO who is in the beginning stages of revamping an IT organization for a major insurance provider. We talked about many things in our two hours together, including IT investment governance in his organization. In our conversation, he offered a much simpler explanation for the rate of IT project failures. He contended enterprises are "Happy with crappy." He said so with a mischievous grin and I couldn't help but laugh.

I am sure you have heard that there is an element of truth in every joke, and his clever comment caused me pause. In the past, I have theorized that our inability to correct this disturbing trend was partially due to a complacency born of a belief that technology projects inherently:

• Take longer than we plan
• Cost more than we anticipate
• Don't usually deliver what the user wants - the first time (for a variety of rationalized reasons)

Did his comment provide more insight into my theory? Are we happy with crappy based on our rationalization that technology projects are inherently difficult to estimate and deliver successfully? Let me know what you think.

Steve Romero, IT Governance Evangelist

Published: June 16 2009, 10:32 AM | no comments
by Steve Romero

Are you looking for "the" solution to a specific problem in IT? Are you looking for a single solution for all of your problems in IT? Do you seek the "one" best practice that will make things better? Do you want that silver-bullet?

Don't look here, because I can't give it to you.

I have said this, time and time again. And there have been occasions when it was not well received at all. In fact, you might be wondering why you should even continue reading this post. You likely know plenty of sources to which you can turn that are more than willing to give you "the" answer.

I have been working as CA's IT Governance Evangelist for more than 2½ years now. I have had the honor to present and speak to thousands of people around the world. In those interactions I have been asked over and over, "Steve, here is our situation, what do we do?" My answer (though it makes my stomach hurt each and every time I say it) is always the same, "It depends." Even in those cases where there is a single solution, the approach, starting point, sequence and implementation roadmap will vary greatly from instance to instance.

I am certain this is not what they want to hear. Some are openly frustrated by my response. A few dismiss me outright and turn quickly towards others who will be delighted to tell them exactly what to do. Thankfully, most folks let me explain.

I am sure I don't need to convince you that the world of IT is incredibly complex. This intricate atmosphere creates multifaceted challenges, problems, issues and opportunities. The circumstances and variables are countless. Given this complexity, how can there be any single or simple answer? In fact, it will be a series and sequence of integrated solutions that will simplify and unify their complex IT environments, ultimately reduce its complexity, and make it far more manageable.

I tell everyone they have some homework to do before they can adequately answer their question. I provide them a laundry list of things they need to understand:

• Business problem or opportunity and related risks
• Industry and business sector
• Current capacity and capability
• Strengths and weaknesses
• Culture and organizational constructs
• Governance and decision-making mechanisms
• Policies, Standards, Processes and Procedures

In addition to understanding the elements I list above, they then need investigate:

• Disciplines and frameworks
• Approaches and Best Practices
• Standards and conventions
• Solutions, systems and tools
• External resources and potential Partners
• Mountains of research

Confronted with these lists (and please, I entice you to add to them) they will find they have a sometimes overwhelming myriad of choices and alternatives. This approach requires acute understanding, in-depth analysis, accurate interpretation and courageous decision. Most importantly, it requires time. If you don't have sufficient and adequate time then you must understand, mitigate and potentially accept the risk of not taking the time.

I was inspired to broach this subject because in addition to being asked what to do, I have had the luxury of immersing myself in research and interacting with countless brilliant and astute people in my profession. I enjoy their ideas, insights and theories. At the same time, I am bothered by some of their conclusions. I have witnessed a propensity if not an obligation to accompany investigation with one-size-fits-all recommendation. Why? Go back to the first paragraph of this post. Too many of us want "the" answer. We want the solution to be singular, simple, and even easy. As I have said countless times, if it was easy, we would already be doing it.

I urge caution in those instances when specific recommendations follow research. I will give said researchers the benefit of the doubt that these recommendations are based on their devoted and fervent desire to help others succeed. It is quite reasonable to accept the notion that following the singular recommendation is better than doing nothing. Enterprises are likely subscribing to the 80/20 rule, which is many cases is adequate. My hope is that those adopting this approach are doing so due to reasoned and rational necessity as opposed to expediency or worse, recklessness. I also hope they luckily if not accidentally select a recommendation that is "coincidently" appropriate for them.

Whatever the case may be, I will continue my quest to evangelize IT Governance and resist the urge to downplay its complexity. I will try to persuade folks there is power and promise in the discipline when it is applied thoughtfully and appropriately. I will try to convince them to take the time to do the right things, and to do them right. I will inform them that their approaches and paths to success will vary greatly from their contemporaries as well as their counterparts. I will tell them it is a journey that requires audacity, courage, perseverance and resilience. I will continue to insist there are no easy answers, and I will warn everyone to question any "one size fits all" recommendation or solution.

One last note, I drafted this post on my flight to Boston to attend MIT's CISR Executive Summer Session. This is my third trip to MIT and I don't want to give you the impression my time with these incredible minds (led by Peter Weill and Jeanne Ross - both heroes of mine) inspired this post, quite the contrary. I have never seen them oversimplify the answers to the incredibly complex question of how enterprises derive value from technology. MIT CISR has been addressing that question for 35 years and they are the first to admit, there are no easy answers.

Steve Romero, IT Governance Evangelist

Published: June 11 2009, 11:52 PM | 2 Comment(s)
by Steve Romero

Have you been "reorged" lately? I would bet if you have been in the same IT organization for more than three years you have been involved in at least one reorganization. And this is under "normal" circumstances. Given the disastrous economic downturn, I am sure countless Enterprises have turned to the infamous reorg as a response to the need to do things differently in IT.

Do you recall your response to the news of your last reorganization? Were you excited and encouraged? Or were you dismayed, frustrated or even angry? What was the outcome of the reorganization? Were things notably better? Were they worse? Was there any change at all (other than to whom you reported)?

I can't begin to recall and recount all of the reorganizations in which I have been involved in my over 30 years working in IT. And I must confess, I was not always on the receiving end. I participated in driving and implementing a few reorgs in my time. One thing I can recall, none of the reorganizations resulting in substantial change or marked improvement. (I can admit this now, needing also confess to the myriad rationalizations that followed our inability to transform IT.)

And consider these reorganizations are seldom met with optimism and hopefulness. In fact, they are almost always met with resistance, incredulous apathy or even subversive ridicule. So when things aren't working, why do Enterprises turn to this convention over and over again?

I contend it is a lack of adequate and appropriate IT Governance. Yes, I know. You saw that coming. So here is my argument:

In my last two blog posts I noted how I declare all organizations have IT Governance, even if they don't recognize it. I base this assertion on the simplest definition of governance: the processes and relationships that lead to reasoned decision-making in the use of IT. I maintain if an organization is making technology decisions, they have IT Governance. I merely point out that their governance is comprised primarily of relationships (people) and non-existent, ad-hoc or chaotic processes.

Given this line of reasoning, I can explain and understand why Enterprises reorganize IT over and over again. What else can they do? If you don't have adequate processes in support of your IT Governance, then your only alternative is to turn to the other dimension of the discipline - relationships. People! Hence, reorg.

When IT is not aligned with the business, not delivering value, not managing risk, resources and performance, then we have to do something. We have to change. We have to change our IT Governance. Given the immaturity and inadequacy of IT Governance processes in Enterprises today (based on abundant research) we have little choice but to turn to the people and their relationships that result in technology decisions. How do we overtly affect relationships? Reorg.

So until you establish, manage and optimize your IT Governance processes to support the people making technology decisions, brace yourself for your next reorg. It is just a matter of time.

Steve Romero, IT Governance Evangelist

Published: June 08 2009, 10:16 PM | no comments
by Steve Romero

In my last blog post I noted how I use the basic definition of governance to convince organizations they have IT Governance, even if they don't recognize it. I make this assertion so often that I hardly took note of my brevity in presenting the argument. Upon reflection I thought I should elaborate on this position and invite others to share their thoughts on my contention.

First, I must admit that I did not always have this belief. In fact, I spent a lot of time and energy during my first year as CA's IT Governance Evangelist pondering and attempting to help other folks solve the challenge of persuading their organizations to embrace and establish IT Governance. The question of how to "convince" leadership came up soon after I delivered my first IT Governance presentations. I spent the months that followed refining my opinions and suggestions to bolster my endeavor to help people gain Executive Sponsorship for IT Governance.

My favorite suggestion was to understand the challenges and opportunities of their Enterprises. I told folks if they understood what kept their Leaders up at night they could map those concerns to the appropriate aspect of IT Governance to showcase its potential. I am not a process-for-the-sake-of-process person and I believe we should always have an acute understanding of the business problem we need to solve before undertaking any process effort.

In addition to understanding the problem or opportunity I suggested variations of the following:

• Understand how your organization defines value and establish a business case that shows the value of IT Governance
• Understand and speak the language of your organization to ensure your message and recommendations resonate with Executive Management
• Find a willing and influential Sponsor on the Leadership Team to advocate your cause
• Work at the grass-roots level to identify and solve a problem using an IT Governance construct in the hopes of showcasing the discipline's potential if it is applied at an Enterprise level

As I continued to amass these clever ideas I decided one evening to write them done for future reference and continued refinement. As I began listing them in my head I had an epiphany, I don't need to help convince organizations to "do" IT Governance...they are already doing it!

Let's begin with the most basic, if not simplest definition of IT Governance: The processes and relationships that lead to reasoned decision-making in the use of IT. This simple definition has three major components:

• Processes
• Relationships
• Decision-making

So to test if an Enterprise has IT Governance, we need ask only 3 questions:

1. Are they making technology decisions?
2. Do they have relationships (people interacting with other people)?
3. Do they have processes?

It is practically incomprehensible to think there are enterprises not making technology decisions, so the answer to Question 1 is most likely "yes." Every organization I have ever seen has people, so the answer to Question 2 is also "yes." Question 3 is a little less straightforward, as I have encountered numerous organizations that mistakenly claim, "We are not a process shop." Yes, mistakenly.

I have heard the following from many people, "My organization does not have processes." I then hear one of the two following statements, "We've tried to put processes in place and they failed," or "We decided we are not a process shop." Let's dispel this mistaken notion right now, ALL organizations, enterprises, companies etc., have process. It is simply a matter of whether or not the processes are informal or formal and to what degree.

I follow a process when I brush my teeth. I don't have a documented process design, and I never formally implemented my tooth brushing process, and I don't officially manage the process. But it is a process none-the-same. For those organizations claiming they don't have processes, they in fact do. It is just that their processes are:

• Ad hoc, informal, inconsistent
• Unknown, unnamed, unrecognized
• Fragmented, haphazard, disjointed, disconnected
• Incoherent, complex, chaotic
• Lacking continuity, uncoordinated, not integrated
• Not managed, not measured

So if you accept my contention that all organizations have process, and the other two aspects of IT Governance are a given (relationships and technology decisions) then ALL Enterprises have IT Governance. The major differentiator from one organization to the next is simply the nature and formality of the processes in place to enable IT Governance. For those that don't have processes, all of their technology decisions are simply based on relationships - people making decisions about technology.

So the question is not, "Should we have IT Governance?" The question is, "How well is our IT Governance working?"

If your making money hand-over-fist, if your shareholders and constituents are delighted, if your employees are happy and self-actualized, if you have enough resources to get all of the work done, if your programs and projects are successful, if everyone loves IT, then you are good to go. If your technology is aligned with your business, if your technology investments deliver appropriate value to the business, if you are properly managing technology risk, resources and performance, then don't change a thing. If not, then take a look at your IT Governance framework, constructs and mechanisms. I'll bet we can do something about the IT Governance processes needed to help people in your organization make reasoned and rational technology decisions. We can introduce and establish the IT Governance required to make them successful.

Did I convince you that any Enterprise making decisions about the use of technology has IT Governance? Let me know.

Steve Romero, IT Governance Evangelist

Published: May 27 2009, 01:17 PM | no comments
by Steve Romero

I recently responded to a blog post that delved into our motives when making decisions and getting things done. The post included the following interesting dilemma, "One person's influence is another person's politics." This is SO true, but only in the absence of the constructs and conventions capable of exposing the true nature or our behavior.

Consider the definition of "play politics" - which I found listed as an Idiom at Dictionary.com when I looked up the word politics:

- To deal with people in an opportunistic, manipulative, or devious way, as for job advancement.

I am sure countless examples of this come immediately to mind. I contend the pervasiveness of this behavior is due to (and please don't laugh), the lack of Governance. That's right. I am saying Governance deters politics.

Consider the simplest definition of governance: the processes and relationships that lead to reasoned decision-making. I use this basic definition to convince all organizations that if they are making decisions, they have governance. I simply point out that their governance is comprised primarily of relationships (people) and non-existent, ad-hoc or chaotic processes.

When organizations lack adequate governance, especially when it comes to projects and programs, they rely almost completely on people (and their associated relationships) to make decisions. This situation does little to prevent people from playing politics and in many cases, actually enables it due to the lack of the processes and associated controls and measures that ensure "reasoned and rational" decision-making.

In such cases anyone can argue either side (influence vs. playing politics) and there is little in place to reconcile differences in perception. And when somebody is accused of playing politics, they can easily justify their political behavior with the argument of "the ends justifying the means."

Sound governance will not completely eliminate this destructive behavior, but it goes a long way to inhibit and expose it.

Steve Romero, IT Governance Evangelist

Published: May 22 2009, 10:11 AM | no comments
by Steve Romero

In every presentation I deliver, I talk about value. Many of my recent posts have addressed the elusiveness of understanding and determining value in enterprises today. We don't know the value of our processes, our methodologies, and most regrettably, we don't know the value of our investments.

A recent IT Governance Institute (ITG) IT Governance Survey of 255 Non-IT Executives showed that Value Delivery was the leading motivator for implementing IT Governance in an Enterprise. (Value Delivery is one of the five principles of IT Governance, in addition to IT/Business Alignment, Managing Risk, Managing Resources and Managing Performance.) Before this survey, Risk Management had always been the #1 driver.

I am encouraged by this recent trend and thrilled that organizations recognize the importance of understanding the value technology delivers to an enterprise. But my delight is tempered by the difficult proposition of proving value. And this goes beyond proving the value of IT investments. I am asked how to prove the value of project management processes, of processes such as ITIL, and even of IT Governance processes themselves.

When folks ask me how to prove the value of any process I evangelize I tell them their very first step must be to determine how value is defined by whoever is paying for the process. It is only then that they will have any chance of knowing:

• if the process value can be determined using the given definition of value
• if the process has the potential to deliver this value
• if the process, once implemented, is delivering the value

This same approach must be applied when proving the value of investments. Simply replace the word "process" with the word "investment."

As long as an enterprise is able to define what value means to them, it is possible for them to establish the governance to determine the value of any process and more importantly, of any investment. I say "possible" because the severe lack of sound governance in many enterprises makes this valuation process quite difficult and elusive. Even so, we have to begin somewhere, and defining value is the right place to start.

Let me know how value is defined in your organization, and how you determine and prove the value of your processes and investments.

Steve Romero, IT Governance Evangelist

Published: May 20 2009, 09:19 AM | 3 Comment(s)
by Steve Romero

I just read a blog with this title on Aras' "How to Manage a Camel - Project Management and Recruitment site. http://projectcentric.co.uk/how_to_manage_a_camel/projectmanagement/guest-pm-blogger-whats-wrong-with-the-triple-constraint/. In summary, the premise of the post is that the three dimensions of the project management triple constraint (Time, Cost, Quality) are insufficient. The author suggests another factor, Benefits, should also be considered when making project decisions.

I like the idea that the author identified a fundamental drawback of the Triple Constraint Model and proposed a thoughtful solution. As noted in one of the replies to his post, there may be even more legs to this "stool," such as Risk.

Let's consider this for a moment...A five-legged stool? Can you see where I am going?

Though I agree the model is flawed, I don't agree that making it more complex is the answer. So in the hopes of keeping the model simple, I suggest the flaw lies in the legs themselves. I offer these 3 legs instead:

• Speed
• Value
• Performance (or maybe Quality - I need your help on this one)

For those of you who have attended my Metrics presentation, you've already heard my thoughts on the "classic" project management metrics: Time, Cost, Within Scope. I have contended for some time that they are outdated and insufficient in making sound project decisions. Here are my arguments:

Time - If you give a PM and the project team 12 months to complete a project, how long do you think it will take? I can just about guarantee it will take at least 12 months - if not more. The team will inevitably end up using all of the time they are allotted. They will establish a plan to complete the project in 12 months, and when things inevitably go wrong, they will likely miss the mark. Instead, replace this metric with:

Speed - I want to give my project teams the "must have date" and have their first response to be, "How can we beat that date?" They will respond in this manner because they know nothing contributes more to a project than getting it done! I read a Forrester report a few years ago citing schedule as the #1 factor in determining project success. Their research found that projects 50% over the original timeline almost always have zero chance of delivering their intended ROI. One of the 9 objectives I advocate for PMOs is to reduce project cycle times. I want projects completed as fast as possible.

Cost - Oh how I despise this factor. I think it is one of the worst metrics we have ever had for projects. Let me get right to my point, I don't care what a project costs. I only care about Value. Cost is a factor and metric we use because we are terrible at defining, estimating and determining value.

Value - I love this word. This is what I care about when it comes to all of my investments, the value they deliver. I have written a number of posts now on the subject and I believe organizations able to establish the governance processes to define, estimate and measure value make the best investment decisions. I understand how elusive valuation is but I am determined to advocate improved financial management systems. Imagine if you gave your project teams a new program and the first thing they considered was, "How do we get more value out of this investment?"  I want them to seek opportunities for additional investment capable of delivering exponential returns. These folks are close to the work, they are close to the customer, and we would be amazed at what they might suggest if we stop them from thinking, "We better not go over budget."

Within Scope - It does not matter to me that I stayed within scope. I care whether or not I am providing the customer with the performance necessary for them to meet their business needs. I admittedly struggled with the "Quality" leg of the stool. In the past, I was replacing "Within Project Scope" with "Performance." That change is pretty straightforward. I find it is not as easy to dismiss Quality because I actually list performance as a potential dimension of Quality in my Metrics Presentation. I also list: accuracy, conformance, completeness, reliability/durability, aesthetics, and serviceability. This one requires more reflection. In the meantime:

Performance - I like this leg of the stool because it gets directly to the customer of the product or service I am delivering. As I said above, am I delivering the performance they need to meet their business objectives? I am not going to hide behind the fact I may have met "their" requirements. Good project management processes ensure requirements reflect what is needed to meet business needs.

Using these dimensions, I believe we cover the two main inadequacies of the original 3-legged stool. First, any changes in benefits will be factored into Value, and risk can be addressed in all 3 dimensions.

Are there any factors you think won't be addressed by considering Speed, Value and Performance when making project decisions? Do you think my third leg should be Quality or Performance? Is Risk a 4^th leg? Let me know.

Steve Romero, IT Governance Evangelist

Published: May 13 2009, 08:14 AM | no comments
by Steve Romero

This blog post was inspired by Kristen Caretta of Search CIO @kcaretta who is writing an article about an organization's issues with legacy systems and she is looking for analysts, consultants to weigh in. I started writing her a response and thought it would make a good post. I have been writing on the topic of value with some frequency lately, so understanding the value of our systems and applications is timely.

Kristen's article will likely take on numerous dimensions. I suspect many will be tactical and operational because there are countless challenges associated with operating, maintaining, enhancing, integrating and ultimately retiring legacy systems. I focus largely on the strategic aspect of the problem - which is the very infrequent practice of Application Portfolio Management.

Application Portfolio Management (APM) attempts to use the lessons of financial portfolio management to measure and justify the financial benefits of each application in comparison to the costs of the application's maintenance and operations. This is incredibly important because large organizations have hundreds and even thousands of applications. APM provides the information needed to:

• Rationalize and prioritize applications
• Identify strategic and most critical applications
• Reduce or eliminate system redundancy
• Understand the value of program and projects requesting to invest in existing applications
• Free application maintenance dollars for higher-value uses

Many companies don't understand the value of their systems and applications. For most, the only time they consider the criticality of their applications (and by definition, the value) is during their annual Disaster Recovery or Business Continuity Planning. What they should be doing is using this essential insight to make daily decisions about their systems i.e. considering a project/program request that wants to invest in a legacy system with low value. Application Portfolio Management provides the insight necessary to determine if investing in a given system is a good business decision.

In addition to ensuring we know the value of these systems when considering project and program requests, application portfolio management identifies the low-value systems we should target for retirement (especially considering they are likely consuming a disproportionate percentage of operations and maintenance costs due to their age).

Application Portfolio Management also helps to counter the contrary behaviors of some of our system metrics. When I worked in Computer Operations, we focused on our 99.99-whatever availability. That was the measure of our success. We did not care whether the application was used by 5000 people or 5! There were even times when we didn't even know who was using some of our systems so we unplugged the server and monitored the Call Desk - to see if anyone called!

So for me, the first step in dealing with the "issues of legacy systems" is to understand their value to the organization. Application Portfolio Management is a great governance process that enables us to do so.

Steve Romero, IT Governance Evangelist

Published: May 11 2009, 12:43 PM | no comments
by Steve Romero

I am sure all of you have written or reviewed Project and Program Business Cases. In addition to those you have personally encountered you have seen many more examples, templates and recommendations for business cases.

In my experience, the #1 purpose of the business case in most organizations is to get the project approved. I think this is a recipe for disaster because it potentially promotes the wrong behavior. If all I care about is getting my initiative approved, then I need only understand my organization well enough to provide me the insight into obtaining that approval. This may be no more than knowing:

• Who to ask or schmooze
• What to say - the buzzwords du jour
• How to say it - manipulating if not exploiting the project approval process

I've seen some organizations manage to rise above these practices by installing the processes and mechanisms to ensure projects are aligned with Enterprise strategy and pledge to realize a targeted ROI. Even organizations achieving these higher-level business case practices are subject to the frequent problem of underestimating the full scope and impact of the project, what is actually required for success, and how to truly determine if it is a good investment. This is even more problematic with technology projects. They may approve the new technology that has all the earmarks of being the right thing to do and find all-to-late they did not have an adequate understanding of the associated business aspects required for success.

So we need a business case that provides us the information necessary to raise the potential for success. Once again, I turn to the ValIT Framework from the IT Governance Institute for a superb list of attributes for a great project or program business case. They suggest the following content:

• The business benefits targeted, their alignment with business strategy - who in the business will be responsible for securing them
• The business changes needed to create additional value
• The investments needed to make the business changes
• The investments required to change or add new IT services and infrastructure
• The ongoing IT and business costs of operating in the changed way
• The risks inherent in the above, including any constraints or dependencies
• Who will be accountable for the successful creation of optimal value
• How the investment and value creation will be monitored throughout the economic life cycle, and the metrics to be used

I love this outline because it does not neglect the associated and peripheral business dimensions of the initiative (note the word "business" is used 6 times - the term "IT" is used only twice). They also use the word "value" 3 times and rightfully acknowledge the requisite business changes and business accountability for ensuring success. I believe this level of detail and insight would enable most Enterprises to:

• Ensure they are investing in the right things
• Ensure the program/project includes all of the activities required for success
• Reduce the intolerable number of project failures
• Accurately measure the value of the program/project
• Improve their investment decision-making process

What do you think of this business case outline? Let me know if you believe anything is missing or if you have anything to add.

Steve Romero, IT Governance Evangelist

Published: May 04 2009, 08:39 AM | 2 Comment(s)
by Steve Romero

Do you know the project failure rate in your organization? To have any chance of answering this critical question, you first need to define and characterize project failure. How you define project failure?

You may recall a post I wrote a year ago titled "Straight Talk About Project Failures." http://community.ca.com/blogs/theitgovernanceevangelist/archive/2008/04/28/straight-talk-about-project-failures.aspx. I had just completed a podcast with Tim Jennings of the Butler Group. They had just published a study of project success rates and found that 50% of all projects were indeed failing.

I am revisiting the topic of project failure after reviewing the recently released Standish CHAOS 2009 Report Summary http://www.standishgroup.com/. In my last post, I provided the results noting the highest project failure rate in over a decade (according to Standish measurement methods). Once again, here is the summary:

• 32% Succeeded - delivered on time, on budget, with required features and functions
• 44% Challenged - late, over budget, and/or with less than the required features and functions
• 24% Failed - cancelled prior to completion or delivered and never used

Please note the 3 categories Standish uses to characterize project results: - Succeeded - Challenged - Failed. I'll get back to these categories in a bit.

The 2000 Standish CHAOS Report found 23% of projects failed. Each subsequent study (conducted every two years) had lower project failure rates, until this year's figure of 24%.

The Standish Group appropriately notes the cause for alarm, but some folks might actually be encouraged by this report. Why? Well, if they have been to any of my presentations they have heard me say that study after study conducted in the past 5 years found over 50% of IT projects are failing. In fact I tell folks I think the 50% figure is generous and I would put the failure rate at 60%.

Yes, the Standish Group looks at all projects, but the 24% figure should cause everyone to question the claims of all of these other IT project failure reports. If indeed the failure rate for all projects is 24%, then don't you think the IT project failure must be lower than 50%? Given these figures I find it hard to believe the IT project failure rate is SO much higher than non-IT projects.

But let's take another look at the Standish Report. Remember those 3 categories? They were Succeeded, Challenged and Failed. I think it is the Challenged category that provides the appropriate insight into true project failure rates.

Let's now revisit the podcast I did with Tim Jennings of the Butler Group last summer. That study found that 50% of IT projects were failing. The first question I asked Tim was how the Butler Group defined project failure. There were two reasons I started with this question. First, I would need to understand their definition to have any appreciation of their study's findings. Second, I wanted to compare their definition of project failure to my definition. Frankly, many folks with whom I have worked in the past thought I was being too hard on projects. Here is why:

I contend if a project takes longer than we scheduled, it is a failure. If a project costs more than we said it was going to cost, it is a failure. If a project does not deliver the value we said it was going to deliver, then it is a failure. Keep in mind, I am allowing for the variance thresholds agreed upon at the onset of the project. If a project is not completed within those thresholds, it is a failure. I was delighted to hear that the Butler Group applied the same criteria.

Now let's apply this definition of project failure to the Standish Report. If we do, we need to include the "Challenged" project in the failed category - which was 44% of all projects. The Butler Group definition of project failure would also include the Standish "Failed" category - which was 24% of all projects. Given this interpretation, the newest Standish CHAOS Report shows that 68% of all projects are failing.

2 out of 3 projects are failing! If ever there was a call-to-arms, this is it!

So I am curious about the project failure rates in your organization, though you may be quite hesitant to share the data. How about if you just let me if you are tracking project failure, and if so, how do you define it? Even better, if you are experiencing lower failure rates, please share your recipe for success. I am sure readers of this blog would greatly appreciate your insights.

In the meantime, this latest CHAOS report gives me even more incentive to continue my quest to help organizations reverse this intolerable if not inexcusable trend.

Steve Romero

Published: April 28 2009, 10:48 AM | 1 Comment(s)
by Steve Romero

My colleague Gail Meadus just notified me of that the Standish Group's just-released its latest Chaos report, "CHAOS Summary 2009" http://www.standishgroup.com/ . The news is not good.

I am looking into obtaining a copy. In the meantime, here are some high-level points from the summary on their website.

This year's results show a marked decrease in project success rates,

• "32% of all projects succeeding which are delivered on time, on budget, with required features and functions" says Jim Johnson, chairman of The Standish Group,
• 44% were late, over budget, and/or with less than the required features and functions
• 24% failed - cancelled prior to completion or delivered and never used
• This year's results represent the highest failure rate in over a decade

I am sure I will have more to share after I read the full report.

Steven Romero, IT Governance Evanagelist

Published: April 24 2009, 07:55 AM | no comments
by Steve Romero

Are you realizing value from your investment in technology?

In my experience, most organizations have difficulty answering this question. I have also found I need to take care when asking the question.

In my last post I noted how IT should create value and I received some savvy comments from Bill Monroe, Chief Collaboration Officer. Bill noted that IT in and of itself does not "create value. He noted that IT is a tool that enables value. Semantics aside, I think we were in violent agreement.

Upon reflection, what I really want to ensure is that I am realizing business value from IT. I talk about this lofty goal constantly as it is a major principle of IT Governance. A recent ISACA survey of 255 non-IT Executives found that "value creation" was the #1 reason enterprises are dipping their toes in the IT Governance waters (having thankfully relegated "Managing Risk" to the #2 reason).

And realizing this value from IT is all the more complicated by the fact that study after study shows that at least 50% of our IT projects are failing (and here's another plug for Michael Krigsman's "IT Project Failures" http://blogs.zdnet.com/projectfailures/ ). I responded to a recent blog post from Toni Bowers http://blogs.techrepublic.com.com/career/?p=733  (who also plugged Michael's blog) agreeing that the failure of these projects is rarely due to problems with the technology. I noted, "In my experience the greatest challenge is understanding, changing and managing the related business processes and human behavior."

My answer to this intolerable quandary is IT Governance. I am a major subscriber to the teachings of the IT Governance Institute and I am a major proponent of their ValIT Framework. This past July they published their second version and in its quest to realize enterprise value, the framework sagely notes, "Realizing business value is not about acquiring technology, but about using IT in conjunction with associated changes in the nature of the business, business processes, individuals' work and competencies, and organizational structures."

I embraced the first version published in 2006 and a recent tweet by @kcaretta, editor of SearchCIO-Midmarket.com motivated me to finally read Version 2 in its entirety. Kristen was asking if anyone was using ValIT which resulted in our scheduling some time on the phone to discuss my views on the topic.

We had a great conversation and I now have to temper the almost limitless resulting inspiration and blog fodder and choose one thing to share with you in this post. I settled on a tidbit I think gets squarely to the subject of the inordinate number of IT project failures and our associated inability to deliver appropriate value to the business.

The newest version of the ValIT Framework includes an excerpt from John Ward's article in the Forum, the Monthly Newsletter of the Information Systems Research Center at the Cranfield School of Management - August 2006, ‘Delivering Value From Information Systems and Technology Investments: Learning From Success'. Their study identified a number of characteristics typical among initiatives that meet success in delivering value:

• Programs are selected based not just on their desirability but also on the organization's ability to deliver them.
• Having methodologies in place is less important than whether business managers and specialists use them.
• Robust and realistic business cases are used and, if possible, include benefits for all stakeholders.
• Benefits are managed over the entire investment life cycle through consistently applied practices and processes.
• Integrated planning addresses benefit delivery as well as organizational, process and technology changes.
• Business ownership and accountability are assigned for all benefits and changes targeted.
• Investments and their results-in terms of whether benefits are realized-are systematically monitored and reviewed.
• Lessons learned are consistently gleaned from both successful and unsuccessful programs -and used to improve the planning and management of new ones.

Though aspiring to these characteristics may be quite daunting, I hope you find this list as inspiring as I did. Send me a comment if your enterprise has achieved any of these characteristics or if you are challenged in your quest to accomplish them. If so, I am sure I have much to learn from your experience.

Steven Romero, IT Governance Evangelist

Published: April 21 2009, 12:24 PM | 5 Comment(s)
by Steve Romero

I struggled with the title of this blog. I first called it, "PMO as a Partner in Success" which I then changed to, "Getting More Value from Your PMO." Though I firmly believe in each of these propositions neither of these labels worked for me.

So I spent some time reflecting on the inspiration for this post. It was a recent exchange I had with Demian Entrekin of IT Toolbox fame http://it.toolbox.com/people/dentrekin/ . Demian wrote a post titled, "In English please..." In his post he wrote, "Statements like ‘Transforming IT' may sound pretty but don't always provide a whole lot of meaning." Demian then went on to provide his interpretation of transforming IT which prompted me to share some of my ideas on the subject. In one of his responses to my responses Demian wrote:

"Steve, I just had a great conversation with the CIO of Forbes, and his view is that the PMO can (and should) act as a change agent. In other words, rather than simply running the PMO as the project police, the folks in the PMO actively look for ways to create more value for the organization as a whole, using IT as a leverage point. This certainly supports your point."

Ahhhh, this was music to my ears. And not simply because my point was being supported (though it is nice when that occasionally occurs). First, the statement supported my long standing assertion that technology should be leveraged for strategic advantage as opposed to being a cost that is managed. Second, I loved hearing about the role of the PMO at Forbes - the role of value creator.

I say loved because that was truly the feeling I had. I love IT Governance and the power and promise it provides. I love IT Governance processes that lead to reasoned and rationale decisions in the use of technology. And I love PMOs that enable aspects of the discipline, though I find they rarely do.

Almost every PMO I have ever encountered acts as project process enforcers and paper-pushers. Their role is simple, establish project management methodology and then report on the use of that methodology - ergo, the unenviable position of Project Police. Though just about everyone agrees (especially me) that sound project management practices are a good idea, these PMOs almost always degrade into something that Executive Management views as overhead, and PMs and project staff view as something that should be avoided.

Couple the doomed "Project Police" model with the fact that few PMOs are backed with sound enterprise-led PPM (Project and Portfolio Management) and it is no wonder so many projects fail. (Michal Krigsman has a blog dedicated to "IT Project Failure" that I highly recommend. http://blogs.zdnet.com/projectfailures/ ) Effective PPM is essential because it ensures the PMO is given a reasoned and rational portfolio of investments upon which to deliver.

If PMOs are to have any hope of aspiring to the vision and purpose of the PMO at Forbes they must be backed by good governance, good PPM processes and they must be chartered in the role of "value creator." In this circumstance PMOs will help to make work possible and practical. The will help to make people successful and they will be loved.

I travel the world on a quest to help enterprises aspire to this audacious goal. I have 5 presentations I deliver with great regularity and they all play a role:

• Understanding and Achieving Sustainable IT Governance
• Meeting Enterprise Goals Through Project and Portfolio Management
• Critical Components of Effective PMOs
• Enabling Stellar Performance with Process Management
• Meaningful Metrics

I love delivering these presentations and I do so in CA Field Marketing Events, at professional association conferences such as PMI, ISACA and itSMF, and at individual companies. And now CA is offering them in a series of webcasts. I delivered the IT Governance presentation this past Tuesday and if you missed it a recording is available at https://myclarity.webex.com/myclarity/lsr.php?AT=pb&SP=EC&rID=50767772&rKey=C0CA819947BD5CBF.

I will be webcasting the other four presentations every other Tuesday at 8:00 AM PST for the next two months. I invite you to join me by registering at:

Session 2 PPM:  https://myclarity.webex.com/myclarity/onstage/g.php?t=a&d=599166558

Session 3 PMO:  https://myclarity.webex.com/myclarity/onstage/g.php?t=a&d=591596258

Session 4 Process:  https://myclarity.webex.com/myclarity/onstage/g.php?t=a&d=596021503

Session 5 Metrics:  https://myclarity.webex.com/myclarity/onstage/g.php?t=a&d=591676154

I just finished delivering my PMO presentation to a Clarity User Group in North Carolina. I asked them if people "loved their PMOs." They all laughed. Though it was a nice lighthearted moment, I would have liked a different response. Together, I believe we can turn the answer to this question to "yes."

Steven Romero, IT Governance Evangelist

Published: April 13 2009, 08:46 AM | 2 Comment(s)
by Steve Romero

 This point was raised when I recently delivered my IT Governance presentation to a Master's class at San Francisco State University. I had completed the first half of the presentation that covers the principles and decision areas of IT Governance and launched into what I consider to be the major IT Governance processes.

The first process I discuss is "Integrated Business and IT Planning." I provided a high-level overview of strategic, tactical and operational planning and one of the students asked, "Technology changes so fast and frequently, what do you do when technology changes in the middle of your plans?"

I liked answering this question because it gets to the spirit of one of the main concerns I hear when it comes to advocating, fostering and establishing IT Governance, "Things are moving too fast and we don't have time." This question went beyond the time it takes to do the planning, it addressed the time it takes to "do the plan!" In many cases, technology changes before you have the time to complete your best laid plans.

My answer was simple, if not witty, "Plan on it." If you work in an environment faced with frequent and fast-paced changes in technology, then your IT Governance processes should accommodate and address this phenomenon.  How about a strategic planning process that includes technology checkpoints at regular intervals, with the anticipation that new technologies will be reviewed, evaluated and possibly adopted? All subsequent technology adoptions would then be incorporated into the strategic plan - with timely and appropriate decision-making.

And it just so happened that "Technology Evaluation and Adoption" is one of the IT Governance processes I advocate. The question helped illustrate the relationships and interdependencies between IT Governance processes and how these connections must be recognized and managed.

This question also underscored something in which I firmly believe. Good governance processes and mechanisms are not only unaffected by technology change, they ensure enterprises can deal with that change, if not exploit it. Technologies will come and go, but the need for rational and reasoned decision-making in the use of technology is here to stay.

Steve Romero, IT Governance Evangelist

Published: April 06 2009, 09:20 PM | no comments
by Steve Romero