Published: September 24 2009, 08:25 AM | 1 Comment(s)
by Steve Romero

This post was inspired by one of my favorite Project Governance cohorts on Twitter, Woody Williams @threew. He recently tweeted, "Canceling a project is often a highly "successful" outcome. "

Successful outcome?!? When was the last time your organization celebrated a project being canceled? The answer is likely never.

OK, how about this question: When was the last time your organization canceled a project - at all?

If you have canceled a project, do you recall the reason why? It was likely due to a funding cut. Either the money ran out for the specific effort or a department-level budget was reduced and the project was one of the "unlucky." These reasons fall much more in the "We had no choice" category as opposed to the focus of this post - Killing projects as a specific outcome of sound Project and Portfolio Management (PPM).

That's right - killing projects. I prefer the term "kill" over "cancel" because it connotes the act of a predator over that of prey. "Killing a project" sounds deliberate. "Canceling a project" sounds apologetic.

Semantic preferences aside, this topic is a critical imperative for every Enterprise. Many of my blog posts have been devoted to the subject of project failure rates - which have never been less than 50% in any study I have ever seen. Given the high rate of failure, the advantages of killing projects are obvious. I much prefer a $1M mistake over a $5M mistake. And rather than throwing good money after bad I could redirect my precious resources to an effort that yields promise.

As I mentioned earlier, killing/canceling projects is a function of PPM. Sound PPM continues beyond the project investment decision, it provides more than just go/no-go. Approved investments should be managed actively by Leadership on a continuing basis and not only considered when approval is sought. This involves continued analysis of the portfolio, monitoring each investment for its relative contribution to enterprise goals versus other portfolio investments. This oversight continually asks and answers the fundamental questions:

• Is the project performing below expectations? (schedule or cost overruns, benefit erosion)
• Is the project still aligned to business objectives? (which constantly change)

With the timely fact-based project/portfolio data only good PPM can provide, Management must decide:

• To make the necessary project/portfolio adjustments to improve performance
• To make the necessary project/portfolio adjustments to maintain alignment
• To kill projects to eliminate further investment and redirect resources towards other projects that better fulfill enterprise strategy and business objectives

So the idea of killing projects is one I whole-heartedly advocate. Which is why I so enjoyed Woody's tweet I referenced at the beginning of this post: "Canceling a project is often a highly ‘successful' outcome. " I like his statement because it sounded celebratory and unapologetic. To me, it implied a level of awareness born of the realization that investment decisions are sometimes wrong. This realization enables and fosters successful PPM by including the constructs and mechanisms for the "successful" cancelation of projects.

This positive-spin on project cancelation brings me to a related subject, the 2009 Standish Chaos Report. Their report (which I highly recommend - at the very least, the Summary) showed a recent decrease in project success rates, with 32% of all projects succeeding (delivered on time, on budget, with required features and functions); 44% were challenged (late, over budget, and/or with less than the required features and functions); and 24% failed (cancelled prior to completion or delivered and never used).

Notice they have 3 categories as opposed to my 2 categories (success and failure). The studies to which I earlier referred placing project failure rates at 50% also do so with a 2-category system. In fact, each of those studies considers the Standish "challenged" category of projects to be failures. In doing so, the 2009 Standish Chaos Report could be interpreted as exposing a 68% project failure rate (by combining the challenged and failed categories).

Not so fast. Before we simply combine the two categories, let's first consider the Standish Chaos definition of failed projects - "cancelled prior to completion or delivered and never used." "Canceled prior to completion"...a killed project. Given I obviously agree with @threew that a canceled project can be considered a successful outcome, I don't necessarily agree with the Standish Group that it is a "failed project." I suggest it may be or may not.

I can think of a number of reasons why a reasoned and rational investment decision (a good decision) may eventually turn into a bad decision. Unforeseen economic, business, or customer circumstances could alter an investment's value proposition, especially when compared to competing alternatives. And I fully expect Enterprises accepting a reasonable amount of investment risk will occasionally be wrong.

Sure, even with good PPM we will eventually reflect on a go/no-go decision that was wrong for the wrong reasons, and it is fair to call this a "failure."  But good PPM increases the potential this will be the exception as opposed to the norm. Most killed projects will be the result of the effective oversight required to spot the variances and anomalies. This will then trigger the reasoned and rational decision-making born of the essential investment governance only PPM can provide. In these cases, I find it difficult to call this project failure. It means we're watching. It means we know what's going on. It means we have the courage and humility to ask the question, "Is the investment decision still valid?"

So if Martha Steward was a PMO Director I am sure she would say, "Excel at canceling projects. It's a good thing."

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share

Published: September 08 2009, 09:29 AM | 1 Comment(s)
by Steve Romero

How do you measure the success of your Project Management Office (PMO)? What metrics do you use?

I recently read a great post on PMOs called "7 Marks of a Great Project Management Office" http://is.gd/2Kjoi by @alecsatin. These "marks", as Alec Satin refers to them, actually struck me as great fodder for a potential list of metrics for a successful PMO. I made that point in a comment to his blog posting and re-Tweeted the link. Even after returning to other activities, Alec's post really stuck with me.

As I continued my day I coincidently found myself working on my Metrics presentation. I was simply adding the PMI Metrolina North Carolina chapter logo in preparation to speak at their conference in October. My continued reflection of Alec's blog post prompted me to review, and subsequently update my list of recommended PMO metrics. That update became the inspiration for this post.

Under goal-oriented sub-headings, here is my list of recommended PMO Metrics:

Facilitating and Enabling Project and Portfolio Management (PPM)

• % of investment decisions influenced by PMO-provided data
• % of projects aligned with organizational goals
• % of projects reviewed during execution by Executive Management
• Executive satisfaction with PMO - survey based

Influencing Project Success

• Project success rate (upward trend)
• % of projects delivered ahead of schedule
• % of healthy Projects

Establishing a Partnership with Project Managers

• Project management competence (upward trend)
• Number of mentoring relationships
• Number of training days delivered
• Project Manager satisfaction with PMO  - survey based

Fostering Processes that Enable Success

• Project standards, processes, tools and templates are designed and implemented
• Project processes are owned and managed (process management lifecycle)
• % of projects complying with project management standards & methods
• Value of PMO is measured and understood

I admit it will be a challenge to establish the systematic approach to instituting these metrics and determining their measures. I believe it is well worth the effort to do so.

What metrics do you use? What do you think of these? It would be great to hear your comments.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share

Published: September 01 2009, 08:31 AM | 1 Comment(s)
by Steve Romero

Do you have processes in your organization? I have encountered countless folks who say, "We aren't a process shop. We don't have processes." Insert your most annoying incorrect-answer-sound-effect here. They are wrong. Everyone has process.

One of the five presentations I deliver with regularity is my favorite, "How to Ensure Process Success." For those of you who have read my blog, you know I love processes and I love process management. And this is coming from an IT-guy, an IT-guy to the bone. It has always made me an anachronism in every organization in which I have worked, where process was always a four-letter-word.

My process presentation is 90-minutes when I deliver the full version. This may seem a bit long, but it hardly does the subject justice. In addition to the business case for processes, I cover the 3 domains of Process Management: Process design, Process implementation, and Managing Processes. I try to give folks sufficient appreciation for each of these areas to inspire them to spend the appropriate time and effort immersing themselves in the discipline - to the extent necessary for them to apply these process conventions to their organizations.

The subject of this post is based on the very first slide of my Process Presentation. The sub-heading of that slide is "Everyone has Process." I start with this slide because I want to immediately dispel the misconception or myth that any organization can do anything without processes.  They may not have "formal" processes and instead have processes with some if not all of the following attributes:

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

I tell audiences the next time somebody in their organization claims they don't have processes, they can respond, "Yes, we do. We have process with these characteristics." They aren't formal, they aren't documented, they aren't consistent or repeatable, you can't measure them, but they are still processes.

After an organization admits it does indeed have ad hoc or informal processes, but processes nonetheless, the next question should be, "Is this OK?" This is critical to any potential process design or process improvement effort. As bad as the above list inherently appears, it doesn't necessarily mean they should change the situation. I actually defend processes with the above attributes, when:

• Products and Services are awesome
• Customers are delighted and opening their checkbooks
• Employees are productive, content and loyal
• Competitors are being crushed

If this is the case, then by all means, they should not change a thing. They should keep their processes just the way they are.

But if their products and services aren't performing as desired, if their customers aren't delighted, if their employees aren't whistling while they work, if their competitors are eating their lunch, then they should take a look at their processes. They already have them. They just aren't what they need to be.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share