The New PMBOK® 4th Edition & Software Applications Development

Last weekend I attended a presentation on the differences between the new PMBOK® 4^th Edition and the previous 3^rd Edition. This presentation was given by Kim Caruthers at Nova Southeastern University in association with the South Florida Chapter of PMI. I had already purchased the new edition in the hopes of keeping current with best practices (an old dog needs constant training to do new tricks). I had read 2 sections, Collect Requirements & Identify Stakeholders, both in conjunction with previous posts to this blog, or for assignments to measure the effectiveness of our current processes in doing these specific things. My last post raved about the Requirements Section, & I was pleased to see that some of the techniques I had discussed in an earlier post on Software Development Stakeholders were now firmly part of the new PMBOK®.

The presentation lasted 4 hours & it was way too short. It could easily have been 8 hours. It became apparent that in 4 hours, we would not be learning the new edition; we would mostly be discussing the format changes. There were a few new acronyms & a ton of retired acronyms. BTW, the processes now all follow the verb noun format. There were new items in the glossary, no new concepts, just new glossary items. I’m going to borrow terms & phrases from both the PMBOK® & from Kim’s 283 page PMBOK® Guide Differences presentation. As an aside, the class had twice the anticipated audience, about half were there because they now had to take the PM Certification test with the new edition, another 40% were there for PDUs, and the rest of us were there for personal education only. The presentation was geared for test takers (even I had to take a pre & post test, results not admissible in a court of law). Good luck to the PM Certificate test takers, I’m sure you’ll do fine.

There is a greatly increased emphasis on interpersonal skills & the realization that PM’s accomplish work through the team & stakeholders. There’s an entire appendix ( Appendix G) covering these topics that speak directly to the qualities a good PM needs to be successful. I follow several blogs dedicated to Project Management or Software Development & this has become a bigger & bigger part of the landscape. I especially recommend Project Shrink to those interested in the people part of Software Project Management. The explicit inclusion of interpersonal skills in the new edition is extremely gratifying. Agile Software Development demands more interpersonal skills & we had better all become more agile & more people oriented.

Collect Requirements is a new process to the book, certainly not a new process to Software Developers (or any other project management field). Failures in this area are one of the major contributors to failed, overdue &/or over budget Software Development projects. Develop Preliminary Project Scope Statement has been removed; evidently either the Project Charter or the results of the Collect Requirements process will suffice. In the course of this the Scope Planning Process has been removed for the same reason. BTW, the book now suggests that the PM have an active role in developing the Project Charter. This is something we have all been doing, but it has now been acknowledged. There’s a new process called Report Performance. We’ve always done that as part of Monitor & Control, but now it’s its own process under Communications. Collect Requirements also references well known facilitated workshop techniques (JAD, QFD, VOC & HOQ). Mind mapping is also explicitly discussed. There are many Mind Mapping software offerings available, some free, some at a varying costs. Some can interface with other PM software ( MS Project for instance). I use Free Mind.

There is an expanded discussion of the relationship between Projects, Programs & Portfolios which bears reading both for organizations which have PMOs & PPMOs & for those who don’t. Those of us who don’t have either offices end up having to do both anyway in order to comply with our ethical responsibilities, & we have to do it without the resources & access to do it properly.

The Business case has become recognized as in input to the development of the Charter. I have always felt that the Business Case was extremely important & that lack of it leads resources being applied to the wrong projects. I’ve been recently soliciting help & feedback on Business Value & have gotten some extremely helpful responses, but that’s another discussion. It all comes back to the keystone of Agile Development, delivering value. This concept now has been translated to Project Management on many levels.

There has been an acknowledgement of the place that both processes & documents (artifacts) have. Processes usually produce Documents, which serve as Inputs to other processes. Some of these documents have been identified & discussed in detail. The Stakeholder Register is one of these. PERT & other risk documents & techniques are also discussed. One of these days, I’ll post an article on PERT in risk management which will change the common view of PERT as a scheduling or cost tool.

All in all, the new PMBOK® is an advance in techniques & concept. It’s more reflective of the Agile Development world & of the importance of people skills. It’s worth the time & effort to get familiar with it.