High performing project management orgs are more agile — PMI

The Project Management Institute’s latest “Pulse of the Profession” report just came out, and it’s full of provoking findings. It clarifies the benefits of high-performing project management, and it highlights what the top organizations do differently. By the way, the “PMI Pulse” is a nice complement to the McKinsey report on building capabilities I wrote on last week.

So what does it mean to your organization if it’s a project management top performer? It means that you deliver more value and waste fewer resources:

…these organizations meet original goals and business intent two-and-a-half times more often than those in low performing organizations (90 percent vs. 36 percent). High-performing organizations also waste about 13 times less money than low performers. — PMI Pulse, page 6

Did you know that these top performers used agile techniques more often than other organizations? This use of agile, iterative, and incremental methods drove better organizational agility. In turn, this better agility allows for faster and more effective responses to competitive, technological, regulatory, or other external challenges. PMI found that the most agile delivered against business, cost, and schedule goals between 20 to 50 percent better than the least agile. Agile also means better top and bottom lines: the PMI Pulse report references a MIT study that found agile firms grew revenue 37 percent faster than non-agile firms, while generating 30 percent better profitability.

To that end, PM College has greatly expanded it’s agile curriculum, from the basics, to an Agile Bootcamp, to negotiating Agile vs. Waterfall, to PMI Agile and ScrumMaster certification prep.

Agile principles have a been a lifesaver on a number of my projects and programs. If nothing else, an agile education gets you and your organization thinking and working the agile way…even before you implement any methodology at all.

Advertisements

Story points and the meaning of done

Dan Ackerson at Boost Agile (@boostagile, HT  Craig Brown @brown_note)) posted on what he calls “cross-dysfunctional” development teams.  He focuses on an all-too-common case: developers want to keep working on to new features, but support and QA types want the bugs cleaned up.  IMO, Dan’s team is falling victim to a false choice here:

[Support and QA] don’t care about new user features – they want the bugs fixed. Because the project team only gives points to new features, the support colleagues feel left out and forgotten. Their job is seemingly made harder by our “overlooking” bug fixing. 

The choice isn’t between new features and bugfixes; IMO, the choice is between accepting a new feature only when it’s clean or doing constant rework when a bug-ridden story is called “done”.  How can a development team get “credit” for new feature story points when/if a feature doesn’t perform as designed?  

My take: this is another demonstration of why agile development has to be more disciplined than waterfall, not less.   Dan is on the right track when he suggests that “writing more tests” will get his team on a faster track.   His team should also take one step back and ensure they know what done looks like before writing!

Waterfall, Agile, now “Sim”?

Dan Woods in Forbes (here) highlights one of the emerging trends in development: user-interface simulation.  This takes agile development a step further, because…

[b]y creating a simulation of the user experience, instead of a full-working version, a team can avoid a large amount of work but still get a full test that can confirm requirements. Simulation accelerates the agile cycle by lowering the cost of each iteration and improving the quality of the feedback. At the end of several simulation iterations, designers have a rock-solid sense of what is needed.

Simulation also provides a better way to test the quality of business processes because it improves on the typical flow diagrams that only sophisticated users can understand.

iRise is the vendor that Woods mentions and that I’ve heard of (here).  They have a SAP-oriented solution (here), but I can’t vouch for it yet.

Also, because this piece is in Forbes, I’ll bet that smart c-level folks will soon be asking their PMOs about whether they are incorporating this approach into their methodologies.  Time to crack the “sim” books!

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).

Squaring up the PMBOK Guide and Agile

Glen Alleman shoots down some of the common misconceptions about the relationship between the PMBOK Guide and agile principles (here).  As regular readers know, I’m sympathetic to agile approaches, I’ve found them very powerful in the right project context, and I push to incorporate agile principles further into our own content. 

Of course, if I commented on Glen’s post itself, I’d be writing “ditto” or “I agree” a lot, so I’m just going to add on a bit:

  • While many agile advocates over-read the PMBOK Guide, the guide did imply a waterfall approach, especially in earlier editions (Chapter 2).  I can understand the confusion or over-reading.
  • The pending 4th edition does have a more sophisticated treatment of project life cycles and explicitly addresses iterative relationships among project phases.  It is hardly sufficient, but it is heading the right direction.
  • PMI itself is quite eager to engage agile advocates for future editions (or extensions) of the PMBOK Guide.  Several Global Corporate Council members were approached about how and whom to engage in the agile (or agile-savvy) community.
  • My take is that creating an Agile extension to the PMBOK Guide would be the best initial approach.  If nothing else, integrating agile-oriented PMs into the standard-setting process should be easier in an extension project.

PM Quote of the Day — Tacitus

All enterprises that are entered into with indiscreet zeal may be pursued with great vigor at first, but are sure to collapse in the end.

Keep this quote in mind when trying agile or iterative development for the first time. There’s a great temptation to be all “gung-ho” during the first sprints of one’s first projects. But agile puts more of a premium on consistent, repeatable execution than one might first imagine.

Because the idea is to go through repeated iterations, agile approaches can burn out teams if a team starts with and tries to sustain a “heroic” pace. Select and work your sprint backlog judiciously!

Planning and flexibility aren’t mutually exclusive

Excellent post by Craig (here) which gets to the way we need to be thinking about our projects and programs these days.  Our methodological ideologies can get in the way of using the appropriate approach for what we’re building, implementing, or upgrading. 

What is presented as an either/or choice, isn’t.  The answer is “both”.  A plan is not “that which is carved in stone just after the project is chartered” (and shall not be deviated from save for acts of one God as one understands God).  And agile isn’t “doing whatever the heck we think should be done as quickly as possible” (and the product owner be damned). 

The post comes with some great comments as well. 

Finally, nice graph.  I would go with “rigid” vs. “stubborn”.

%d bloggers like this: