16 July 2008

Building the IT Process Framework – Part 1 - PMO Pitfalls

Neal Leininger

Neal Leininger
Project Management Consultant
Veris Associates, Inc.

PrintListen Now


As a technology consultant working in and around technology for over a decade, I’ve seen my share of false starts and good intentions being driven to the end of long dark alleys to be put out of their misery. Due to confusion, redirections and busyness of daily life, valid ideas are driven into oblivion.

The concept of a successful Project Management Office (PMO) rings near and dear to my heart. However, many of today’s process frameworks have interdependencies woven so tightly I find it indistinguishable when departing from one methodology and into another. Which one or two . . . or three or more should the PMO use?

This article is the first in a series to clarify the limits, purposes and blending of four frameworks as they relate to the PMO:

  • ITIL
  • CobiT
  • SixSigma
  • SDLC
Q: So what makes the perfect PMO?

A: Boy, talk about a loaded question. Process implementations are a lot like beauty, much belies the eye of the beholder.

For those who have worked in the software industry for any amount of time, we recognize the old adage “Fail Early, Fail Fast, Fail Often.” I think that summarizes the best approach for a PMO and process improvement in general. (One hint: learn from the failure, don’t repeat it.)

Perfect is a four letter word in most production engineering departments, meaning: Perfect never ships. At the end of the day, we all are very imperfect animals, trying to build very perfect processes. The quickest distance between two points is failure. Only by failing do we learn the true weaknesses and stress points identified. It’s about keeping ourselves accountable to the process, no matter how gruesome the image is in the mirror.

Q: What About Overzealous Advocates?
A common approach for most PMO implementations is to “reign in” the factions causing chaos within IT and putting policies in place that are not conducive to the typical business environment.

A: Walk a mile in their shoes: Make it everyone’s PMO. A true PMO is guided by the principle that made all great teams work together - “what’s in it for me.” Regardless of how unpleasant those factions may be, use the friction to weld them together. Heat makes two pieces of metal one, cleanses the surface and prepares it for another wave of improvements whether it is a complete refinish or some touch-up on the glazing.

Q: What About Overloading the Process?

Even a good process fails under over-utilization. Even though it seems like a good idea at the time, ramping up too quickly slows you down. It starts to feel like you’re fighting a counter-insurgency battle as the plights and wailings of overburdened process users fire emails at you at an alarming rate. These resistance emails seek exceptions and various special accommodations because, after all, their application, project or process is “special.”

A: Start simple and stay accountable. The measure of a process isn’t how fast or big it is. The process’ efficiencies, effectiveness and compliance to the framework win in the end. The visible success of the process encourages others and moves the organization to the next level of process implementation. As the adage says, “Nothing breeds success like success.”

Q: “Kill Switch”-ophobia

One of the telling metrics for a PMO is its kill rate: the rate at which projects are rejected or “killed.” It’s often too easy for a technology department to say “YES” every time there is a request made. The measure of the alignment between the business and a technology department is evident as you examine the kill rate and the justifications behind it.

A: Start simple and kill things. This isn’t an advertisement for the NRA. By failing early, fast and often, you learn a lot by understanding the issues that caused you to stumble. Even if it means creating a PMO request that you know will be killed, go through the exercise and understand the process: engage the business and understand their true alignments. Set criteria and provide evidence for projects to survive or die. Set a metric on the kill rate.

By walking through the process with a very simple, controllable example, you build the template for those un-imaginably complex projects that need to be killed. Remember, not all projects get killed at the request stage. Prepare for killing those “woefully poor initiatives that just aren’t going according to plan.”

Understand several facts:
  • Killing projects sooner than later saves tremendous money and effort.
  • Any project can be killed at any stage.
  • Unsuccessful or never-ending projects impact morale, other projects, budgets and your credibility – your most important asset.
  • Before recommending a project cancellation, do your due-diligence, have all evidence organized, readily accessible and in front of you. While Superman could stop a speeding bullet with his teeth, only your hard, cold facts stop the one fired at you.
  • A high kill-rate is good. Some companies are aiming for 66%! A low kill-rate can mean two different things: you’re letting too many projects through or your not keeping up with the changing business with improvements.
Warning: Beware of the landmines – those special pet projects of someone who has major, impacting power on your career. These types of projects must be handled with special detail. Before suggesting a pet project be cancelled, conduct a full study with extra detail and evidence as to why it should die. We should never back away from killing such a project, but our reasoning must be mine-proof, otherwise, you will blow-up instead of the project.

Conclusion
It has been said, "Buy into a business that's doing so well an idiot could run it because sooner or later, one will." I think that rings very true to the embodiment of a successful PMO. If it’s not easily understood or articulated, then the PMO “Governance” will be jeopardized and those who truly believe in the concept will struggle explaining it to their customers, and subsequently, stop speaking at all.

Recap:
  • Keep it simple, make it easy enough for an idiot to understand because, well you finish the sentence.
  • Kill it, in order for us to say “YES” we must be willing to say “NO”; and mean it.
  • Start small and simple, which is how we learn best. After we’re comfortable with simple arithmetic, we can throw some extra zeros on the end and start talking about calculus.
  • Seek friction and make the best of it. Nothing beats free heat.
  • Don’t cripple the business, they need to keep the lights on too. Engage them in the policy framework so they buy-in in from the beginning.
  • It won’t be perfect the first time. . .or the tenth time. It’s a living process and the better we get at failing, the faster we can close that gap with perfection.

In our next article, we cover how IT framework methodologies are blended to minimize organizational confusion and optimize operational efficiency.

Veris Associates, Inc. offers training in Project Management and IT Service Management methodologies. See our calendar of events for specific times and places.

Copyright (c) Veris Associates, Inc. Unauthorized use is strictly prohibited. Comments contents are the opinions of the person posting the comment (commenter) and not necessarily those or endorsed by Veris Associates, Inc. Veris Associates, Inc. reserves the right to remove any and all comments it wishes without any recourse of the commenter. Decision of Veris Associates, Inc. is final.