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

Software Project Charter

Most (software) project management processes recognize the need for an initial high-level definition of what is expected from the project. PMI’s “PMBOK Guide” for example defines a “Project Charter“. On its turn the UP has a “Vision Document” which is very similar.

Very similar but with two important differences:

• Project Charter is business-agnostic, supposed to be usable in any project kind from building construction to off-shore exploration. Hence its Project Charter does not know anything about software development specificity or terminology.
• Vision Document is actually a requirements document (it is not included in the project management artifacts) and thus lacks some important information at this respect.

I long felt the need for an “unification” of both documents, including what is recommended by the PMBOK and what is needed in the context of software development.

The result can be downloaded here: Software Project Chater Template

Restarting

Restarting my blog. Once more. It seems that I just can’t stop blogging. Probably because I like to share thoughts and knowledge. My previous blog has been wiped out when I left Brazil… new life, new blog.

Anyway. As a first post I would like to share two previous works.

Software Architecture Document Template

The first one is about software architecture documentation. Project after project I try to enhance the structure of the “Software Architecture Document”s I write. I like the agile approach: write only the minimum information that is needed and useful. Or, in less empirical terms, write the documentation whose cost equals the cost of not writing it (an equilibrium that minimizes the cost of documentation). But I’m digressing. Digging in there could disinter a whole thesis. Revenons à nos moutons.

I also like to work toward a well defined and repeatable process integrating best practices, to avoid having to reinvent, redesign, rebuild, retest and redeploy wheels at each project.

Long story made short, I ended creating a SAD template containing both document structure, rationale and instructions. It can be downloaded here in OpenOffice format: SAD Template.

PMBOK Pocket Summary

Another aspect of my indefatigable, unceasing search for the perfect project organization, I got the PMP (Project Management Professional) certification from the international project management organization PMI. The PMI publishes regularly a guide to the project management best practices (PMBOK Guide). A very generic catalog of best practices that can be used in project management. A complete reference that is thicker than a bible and far less poetic.

Preparing for the certification I ended creating a “pocket guide” that i published on Leanpub. 88 pages of the PMBOK essentials. This book can be found here: PMBOK 5 Pocket Summary.