From PMBOK 5 to 6: Introduction

A few years back (already !), I compiled a very minimal digest of the PMBOK Guilde 5th edition. Since then, PMBOK 6 has been published, turning this work obsolete. Wanting to create a new version of my publication, i started digging into what changed between the two versions of the PMBOK.

This first post is the result of the beginning of this effort – it is, literally, work in progress.

First, obvious, difference, is the growing influence of Agile. The PMBOK is now created in collaboration with the Agile Alliance. A few elements of agile were already present in PMBOK 5 but they were rather marginal.

Despite this collaboration, the PMBOK 6 appears to be more an evolution than a revolution, building additional content on the previous version. Knowledge areas and process groups are unchanged, and the process themselves are mostly the same. On the other hand, the new version appears to be significantly larger, with an additional 150 pages plus an Agile guide of almost 170 pages.

But that’s just a first glance. Let’s dig into more details

Good news, the fundamental definition of a project has not changed:

A project is a temporary endeavor undertaken to create a unique product, service, or result.

The base definition of project management is also unchanged:

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements

Exit the corporate strategy, enter driving change and business value

In the first chapter introducing project management, PMBOK 5 briefly gave a definition of project management before describing the relationship between project, program and portfolio management. The same chapter in version 6 has been considerably extended, adding two very agile concepts: change and delivering business value.

Change.

“Projects drive change in organizations. From a business perspective, a project is aimed at moving an organization from one state to another state in order to achieve a specific objective” (p. 6)

Delivering Business value.

In PMBOK 5 world, projects are driven by the organization’s strategy. For example, section 1.5.2.3 states “If the goals of a project are in conflict with an established organizational strategy, it is incumbent upon the project manager to document and identify such conflicts” (p. 15) and “As project management is a critical strategic discipline, the project manager becomes the link between the strategy and the team” (p. 17)

Business value was already present in version 5 in section 1.6, but the link between business value and projects was through business strategy. In version 6, projects directly deliver value “Business value in projects refers to the benefit that the results of a specific project provide to its stakeholders” (p. 7)

 

(to be continued)

 

How did it succeed ?

This project was doomed to failure.

• Client involvement was minimal. There was no clear requirements definition, the client only appointed a business unit manager as single point of contact. But this manager had many other things to do, more important to her than “taking care of the system”. There was no infrastructure to support the system in production.
• Requirements were complex: the system to build was a customized ERP incorporating the client’s business processes and rules – which were very different from what commonly exists. This ERP should manage contracting and offering, clients and prospects relationships, invoicing and payments, stock and inventory, bar sales, accounting statements and much more. And it had to be used in a multi-tenant model, various geographically distributed business units using it independently.
• There was no room for late or low quality delivery. Not without reason (see above) a previous attempt to build the same system went wrong and the client had already lost patience.

Despite of this, the project was a great success. It has been developed on budget and now runs smoothly 24×7.

And probably the most interesting: it has been developed by a single developer. Working half-time.

I could write about the details of the process used, but processes should be implemented for a reason. And there is two fundamental rationales less frequently mentioned.

• Manage your client’s expectations. Or, in other words: client confidence through contractor accountability. We repeatedly delivered what we promised thanks to an incremental development approach based on the agile principles. And we were very, very careful with requirements and change management. Be prepared: you will someday have to gently prove to the client that he is the responsible for some problems or delays.
• Manage your software architecture. We were really intransigent about architecture coherence and code quality. This is a sine qua non condition for the development to continue at a constant pace. The system was too big to live with a technical debt. One key there is probably: maintain the design clean enough to allow for constant refactoring.

Note that I have not mentioned any technology here. Actually, the technology used, as long as it is a good fit for the system under development, is irrelevant. JavaScript, Java, Scala, C#, LAMP… whatever.

Of course, there would be a lot more to say. Do not hesitate to leave questions or comments