Q: How do you write a new version of the PMBOK Guide? A: Very carefully
Development of the PMBOK v5 Guide is underway and I was on the content creation group for Chapter 12 Procurement as explained previously. However, I was transferred onto the group for Chapter 6 Time Management. Apparently, I am a last minute swap to bring an agile perspective to Time Management. All I know is I am very grateful to be there and will likely learn a lot.
I am bound by NDAs to not reveal any content, but Chapter 6 is interesting since the current PMBOK v4 edition contains the processes of:
6.1 Define Activities
6.2 Sequence Activities
6.3 Estimate Activity resources
6.4 Estimate Activity Durations
6.5 Develop Schedule
6.6 Control Schedule
From an agile perspective, the way these processes are currently outlined seems to assume a certainty of final scope from the outset that is at odds with some of the evolutionary concepts of agile. So it will be interesting to see how development of these concepts progress.
Predictably the Time Management group seems a deadline focused bunch and we have had a couple of long conference calls already. Before suggesting new content for the 5th edition we are first reviewing the suggested changes that were made against the 4th edition, but for whatever reason (timing, complexity, knock-on impacts, etc) did not make it into the 4th edition.
Reading the PMBOK text, reading the suggested change, and then discussing as a group the merits of the change is necessarily slow, but really illuminating for me. Our facilitator has a great knowledge of previous editions and can describe the changes from version 2 to 3, version 3 to 4, and can explain why the previous changes were made and some of the likely impacts of the suggested changes we are discussing.
Some interesting considerations focus on clarity. Because the guide is translated into so many languages and that the English version is read by people whose first language may not be English, there is a strong emphasis on being clear. Also, terms that may be common place in IT like “technical dependency” are apparently not common place in other project management disciplines and so not used.
So, it is a journey, with collaborators from all over the world which makes it more fun. Who knows how much agile content and ideas I will be able to introduce, but I will be trying.

