PM Quote of the Day — Albert Einstein

Make everything as simple as possible, but not simpler.

Surviving PMO Success — The Process Maturity Trap

One of the unexpected challenges in our PMO journey has been that success can make an enterprise-level PMO appear less relevant.  A PMO must transform its approach to stakeholders or it won’t take full advantage of the improvements it fostered.  One manifestation of the problem unfolds thusly:

  1. An enterprise PMO composed of PM thought leaders executes a PM improvement program that delivers methodology, training, tools, and change management initiatives to its stakeholders (e.g., regional, local, unit PMOs).
  2. Those stakeholders [largely] adopt those initiatives and transform their project operations in significant and measurable ways.
  3. This transformation creates a new set of PM thought leaders, who often surpass the knowledge and hands-on experience of the original enterprise PMO.

The business problem has reversed; the enterprise PMO now becomes the organization that needs to change to reflect the new reality.  Deliverables that were relevant in moving from low maturity processes no longer work with a more sophisticated audience.  This issue is compounded by the difficulty in recognizing the changed environment.  Who wants to admit that he/she is no longer automatically at the vanguard of knowledge? 

In other words, the challenge for a successful enterprise PMO is: “Who will change the change agents?”

PM Quote of the Day — Albert Einstein

Any intelligent fool can make things bigger and more complex… It takes a touch of genius — and a lot of courage — to move in the opposite direction.

Methodology Scaling/Selection Outline

Or maybe I should say “Methodology Scaling/Selection Graphic”… Glen Alleman’s recent post on PM and Agile (here) reminded me to post this picture (click to enlarge) of a slide we use when discussing which methodologies to use for which project.  Note that we do not directly oppose “Agile” vs. “Waterfall” in our continuum.  Sure, SAPScrum is pretty pure agile, but that doesn’t mean that ASAP doesn’t contain agile concepts (e.g., emphasis on iteration short cycles during the Realization phase). 

methodologyscaling

Also, we’re emphasizing that initiative leaders must be comfortable combining philosophies when implementing solutions, which is why we’re driving program management knowledge out to our general PM community (as implied in the bottom box).

PMI CEO’s perspective on the stimulus package

I forgot to link to this Greg Balestrero post (here) on the US stimulus package (then still in debate).  He asks a lot of great questions about whether Congress and the Obama administration have thought through how to make this portfolio most effective.

I’ll focus my comments on Greg’s first two PM-oriented suggestions for the plan (#3 is to accelerate the spending):

First, get the people who know how to manage complex change initiatives — these are not career politicians but are experienced project professionals — who can manage change portfolios… that can get results.

Agreed, but one of the challenges with current legislative practice is that large swaths of the portfolio are fixed by the legislation itself, at least at the Federal level. Some of the more interesting work is happening at the state level. In a recent radio interview, the RI Director of Transportation sounded like he had his portfolio ready to go. In fact, he was ready to pounce on funds that other states would forfeit because their transportation portfolio process wasn’t as smooth.

Second, emphasize the competency of project management, like they have begun to do in many of the governments around the world. But they should not allow “pockets” of excellence to prevail. On the contrary, the governments should leverage the pockets of excellence to develop an enterprise discipline in project execution.

While enterprise-wide initiatives are great, I always wonder how deep they really can go. My experience is that in any organization of substantial complexity, it is hard to cover any but the most generic PM needs at the enterprise level. The differences in line of business, agency, etc. drive variation that’s hard to reconcile effectively.

Glen Alleman’s Mission to the Agilests

Dont I look like I should be the patron of desperate situations?

Don't I look like I should be the patron of desperate situations?

I don’t know why I think of Glen’s efforts to reconcile agilests and PMs in religious terms. Maybe it’s because many in both camps see topics as either/or — either you’re with us or against us. Or maybe I worry that it’s a hopeless cause (which is why St. Jude graces this post).

There’s not much I can add to Glen’s latest: If I’m Doing Project Management Right am I Agile?  To me, this question is not either/or, it’s both. The worst misconceptions are around planning (especially the schedule), per Glen’s comments on the Agile Manifesto tenet”Responding to change over following the plan”:

The notion that plans (schedules actually) are developed and then fixed is nonsense on any practical project. There are no doubt projects where this is the case. But it’s still nonsense. Anyone suggesting this is good project management practice is either selling you a bridge or seriously misinformed about how projects are managed.

Plans – the strategy for the successful completion of the project, and the schedule – the sequence of work needed to fulfill the strategy are subject to change for every imaginable reason.

Building an SAP PMO — Webcast

Keith Johnson — the VP of SAP’s North America PMO — hosts a webcast on Achieving Operational Excellence Through a Project Management Office.  The webcast is free, though you’ll have to register in advance (registration form here).  Registrants will receive a complimentary copy of the SAP Consulting Solution Brief: Program and Project Management Services.  Here’s a little more on the webcast:

[Y]ou’ll discover how a well-structured PMO can help ensure the success of your next project – whether it’s a new implementation, an upgrade, or a rollout of new functionality. For example, you’ll discover:

  • How to leverage a PMO to achieve operational excellence
  • How to establish the critical link between the steering committee’s goals and the project team’s activities

In addition, Keith will be joined by an SAP customer — Johns Manville — which will discuss how it has leveraged its PMO to reduce costs, lower risks, and focus on proven methodologies.

Still looking down in checklists?

Just saw this article of the power of checklists in medicine (here) which reminded me that I had forgotten to include a link in an earlier post (here).  Atul Gawande wrote a long piece in the New Yorker a little more than a year ago simply entitled “The Checklist“.  It is far too rich to summarize effectively — please read the whole article — but below are a few snippets

[I]t’s far from obvious that something as simple as a checklist could be of much help in medical care. Sick people are phenomenally more various than airplanes… Mapping out the proper steps for each is not possible, and physicians have been skeptical that a piece of paper with a bunch of little boxes would improve matters much.

In 2001, though, a critical-care specialist at Johns Hopkins Hospital named Peter Pronovost decided to give it a try. He didn’t attempt to make the checklist cover everything; he designed it to tackle just one problem, the one that nearly killed Anthony DeFilippo: line infections…. These steps are no-brainers; they have been known and taught for years. So it seemed silly to make a checklist just for them. Still… [i]n more than a third of patients, [doctors] skipped at least one. 

The results were so dramatic that they weren’t sure whether to believe them: the ten-day line-infection rate went from eleven per cent to zero. So they followed patients for fifteen more months. Only two line infections occurred during the entire period. They calculated that, in this one hospital, the checklist had prevented forty-three infections and eight deaths, and saved two million dollars in costs.

Still think your project is too complicated to benefit from a checklist or two?

PM Standards are not Holy Writ

Andrew Meyer at Inquiries into Alignment provides a useful corrective to the faith that we project management types put in our industry standards and frameworks (post here).   He hits on a lot of topics that are only alluded to in our project management “bibles”:

[P]rojects often pull people from different departments together to work on a project. While that is what the project requires to be successful, what does that mean for the people pulled from the different departments? Is the project of primary importance to them or is what’s happening in their department of primary importance?

Now, I believe Andrew that has set up a bit of a straw man here.  I’m not sure that it is the responsibility of the PMBOK Guide or PRINCE2 to elaborate some of these topics fully (I’ll leave Agile aside for the moment).  At least in the case of the PMBOK Guide, it is only a guide to the project management body of knowledge.  While a guide should reference the need to ensure business alignment, only so much content “meat” can be expected from such a guide.

My take is that firms should not count on generic standards to cover some of these topics —  one’s firm-specific methodology should elaborate the questions Andrew suggests (and more):

What is the business environment your company is working in?
How is that environment changing?
What is happening inside the business?
What is the state of the project?
Where does it need to go?
What needs to happen to get it there?  

Accountability for “soft stuff” deliverables

Per an earlier post (here), I have a bee in my bonnet about “supporting” deliverables and how to measure their success.  The excellent comments from Glen and Stephen (here) pointed to the answer.  From Glen:

We are looking for cost savings, efficiencies, and other process improvements. This is the typical work flow process improvement approach. Extend that to the human processes – monetized – and you can define MOP’s and MOE’s [measures of performance and effectiveness respectively].

In retrospect, it should be obvious that training deliverables — and their measures and incentives — should make such deliverables accountable for the relevant process/solution/project/program success measures.   In other words, CRM call center training should be judged by the how well the call center solution delivers the intended capabilities.

This approach is not so obvious to many training professionals, largely because many have never been held to the same standard as process owners.   My experience — from observing a particularly savvy SAP customer — is that a few pointed questions do concentrate the trainers’ minds:

  • Are you worried that the training does not support the actual execution of the processes?
  • What do we need to change in our training approach so that it delivers value to the project?
  • Why am I spending money on training if it can’t be held accountable for project/process succeess?
  • Do you still wonder why trainers aren’t better paid?
%d bloggers like this: