I found the following subject line on a mail in my inbox yesterday:
PMBOK Breaks Project Management
The PMBOK is the grandiosely titled Project Management Book of Knowledge from the Project Management Institute (of which I’m a member).
Wow, I thought, someone else thinks formulaic, by-the-book-only project management can be as much a problem as a solution. The mail was from an electronic newsletter called IT Business Edge. It struck me as odd that an IT publication would be railing against the PMBOK.
Of course, what happened is that my inbox shows only the first 30 characters or so of a subject line. The entire subject is “PMBOK Breaks Project Management into Five Lifecycle Phases.” (It links to this slideshow — and it’s not a slow Flash thingy, so kudos to IT Business Edge for that!)
I’m not sure why this is headline-worthy news; did someone in IT just discover project management?
But now that I think about it… five phases? They’ve got it down as Initiate, Plan, Executing, Controlling, and Closing. Aside from the grammatical issue — it’s either “…Plan, Execute…” or “Planning, Executing…” — there must be at least one and perhaps three additional, explicitly called out phases in an IT project.
The unforgivable omission is Rollout. Without a specific Rollout cycle, there is a tendency — I’ve seen it over and over again — to “dump” the new solution on the users, point them to a (functionally useless) training website, and disperse the team after Closing — but long before the solution is embedded in user processes. Sure, you can technically put Rollout in one of the other phases, but it’s really a post-Execution activity, involving a handoff from the execution team to an operations team… and much more.
There also need to be User “Readiness” and Shakeout phases. These can be subsumed into other phases — e.g., part of Rollout. However, because the activities and players are significantly different, I prefer to call out explicitly at least Shakeout. In addition, if you’re using stage-gates (go/no-go decision points), these phases represent transition points where the sponsors and stakeholders need to get together on a go/no-go decision. (What, you think you can’t say “stop” after the project is rolled out to users? Wrong. If it isn’t working for them, you may well need to perform a rollback, and you’d better have all the stakeholder ducks in a row when that happens!)
As for the names of these last two stages — there aren’t universally accepted terms. I don’t like “Readiness” — it means everything and nothing — but it can serve as a catch-all for user documentation and training, adoption planning, helpdesk/support preparation, and so on. Shakeout represents the first few weeks to a month of actual use on live data, where numerous bugs and configuration errors will crop up, and where the original development/project team should remain in place to address them. One reason I prefer to see this particular phase visible at the highest level is that there is great pressure at this point to move the team on to other projects… especially if the project is late… and since we’re talking about software, the likelihood that it will be late is, oh, 100%. If the executive sponsor and the CIO are aware that there is a full project phase that is just getting started, there is less pressure to move the team, and more weapons with which to fight the pressure.
So maybe leaving off these phases from an IT project justifies the headline after all, with a slight emendation:
Misapplied PMBOK Breaks Project Management
