The New "Software Extension to the PMBOK Guide"

I was in Los Angeles a couple of weeks ago for the kick-off meeting for the “Software Extension to the PMBOK Guide”. This initiative sponsored by the PMI and IEEE is developing additional guidance for project managers on software projects.

The PMBOK Guide is generic, intended for all kinds of projects. When it comes to Execution guidance, it effectively says “go do the stuff in the project plan, based on your industry good practices” and this is the only all-purpose advice to safely give. It would be foolish to mandate construction projects be undertaken the same way as biotech projects, or software, or aerospace R&D projects. This is why there is already a “Construction Extension to the PMBOK Guide” for all the unique things about construction.

PMI Demographics have changed over the last 10 years and now 65% of PMI members are engaged in IT related projects. IT encompasses more than just software, but the time is due (probably past due) for software project guidance for project managers. There are many unique characteristics of software projects that present challenges for project managers. These include:

Specification problems – software projects are hard to define because they are intangible and hard to reference.

Evaluation Problems – We really need to see and use software to say if it is suitable for us, reading a spec is a poor method for validating functionality. IWKIWISI – I Will Know It When I See It applies.

Knowledge Worker domain – we are using subject matter experts to collaborate and share information rather than industrial works to repeat a defined process.

Speed of business change – system requirements change frequently as businesses evolve and change. Change rates are higher than in many other project domains.

Building with bits a not atoms – we are manipulating information and models not concrete and steel so our processes and controls need to be different.

Non-Linear progression – progress is often non-linear. Some things go quickly some things take a long time. Approaches that assume a linear progression to completion are more problematic to apply on software projects.

Uncertainty – We have more technology uncertainty and requirements uncertainty than many other industries and so need more tools to checkpoint and adjust if necessary.

Extreme modifibility – unlike physical construction where is difficult to move a bridge upstream when it is 75% complete, there are some changes that can be done late in software projects that have few parallels in other domains.

These and other unique characteristics mean that some of the effective software oriented practices for managing projects cannot be included in the PMBOK Guide, because they may not necessarily apply to other industries with different characteristics. This is why the new PMBOK v5 Guide will reference agile and agile practices, but will not fully embrace them, they are just not suitable for some industries that have project characteristics very different to the knowledge worker, software space.

However, fear not, because the “Software Extension to the PMBOK Guide” is exactly the place where these software specific guidance should reside and if 65% of PMI members are in IT then lots of project managers should be referring to it.

We have some great people working on the guide already and as the extension takes shape we will be looking for more reviewers. Dick Fairley – author of Managing and Leading Software Projects is chairing the work and for the past couple of weeks I have been pairing with Rich Turner, co-author of the “Balancing Agility and Discipline: A Guide for the Perplexed”. (When I got the chance I asked Rich about that title since it implied agile is not disciplined and many agile practices like TDD are very disciplined. He said it was the editors suggestion to make it snappy and provocative).

Anyway, we are currently just working on chapter introductions and figuring out how to distinguish plan-driven, iterative, and agile approaches to software projects. Since all are valid and the extension needs to allow for them all; despite studies suggesting agile being the dominant method.

So, have a think about the current PMBOK Guide and let me know your thoughts. Not governed to all projects, instead focusing on only software projects, what would you change? We can delete chunks, change things, and add new guidance, so what should it say to be really useful to software project managers?

Comments

[NHel Kissme2]

Hey, since you are still on the "process" of finalizing thing you might want to consider some other project management tools…this helps in “sorting things out”---what should be done first and what should be considered last. I know you’re already probably using one, but like what we always say—two heads is better than one. Also, as you mentioned “Speed of business change” I would suggest for you to be a bit of aggressive in making/creating the best project management tools online. :)

[Mike Griffiths]

Hi NHel,

I agree a big part of a software project managers role is Sense-Making and embracing the initial ambiguity. Tools or techniques that help build consensus, brainstorm and generally allow us to better find our way are very valuable.

Best regards
Mike

[Daniel]

Thanks for the info. Could you tell us when is it planned to be delivered? Is it independent of agile Project management certification just started? My email is info@danielecheverria.com

[Mike Griffiths]

Hi Daniel,

We don't have a firm publication date yet, but I am hoping to see a version for review comments next year. This is totally independant from the PMI certification at this stage.

Best regards
Mike