Through this blog post we share a presentation on project management certifications, what are they, who issue them, what values do they offer the individuals or hiring managers, and what are their limitations.
In this article we address a major gap in the practice of project management today! Our hypothesis is that this GAP is one of the leading factors contributing to project challenges and failures. This is a controversial topic since it touches on what project management professionals practice – based on their understanding of global standards, such as the PMBOK Guide or other know-how. Continue reading →
It is a common belief that project outcomes contain a degree of uniqueness. They may be highly unique, such as in space exploration projects, or only very slightly unique, such as in the construction of a number of identical buildings in an office park, where uniqueness may reside simply in a set of user requirements or geotechnical properties of the site.
By contrast, it is also widely accepted that project management processes are repetitive. In other words, the management effort follows the same path, whether we are managing a feasibility study phase or a construction phase in the project life cycle.
Early editions of PMI®’s Project Management Body of Knowledge or PMBoK® simply stated that the project management process groups of Initiating, Planning, Executing, Monitoring and Controlling, and Closing, repeated themselves in each project phase. Process groups mind you, and not necessarily every individual process. For instance, if a phase or a whole project for that matter is performed in-house we may not need to perform any procurement processes.
The principle underlying this concept is that of progressive elaboration: the constantly increasing level of understanding and definition of the product of the project requires the repetition of the management processes through the various phases.
Reasonable as it may have seemed at the time, this concept is probably responsible for most of PMBoK®’s woes:
Firstly it has led to huge and unabated confusion, and
Later PMBoK® editions, and particularly PMBoK® 5, have tried to soften the rigidity of the concept by discussing different project approaches and life cycle concepts, but nonetheless they admit that the idea of iterative processes is still there.
The consequences of these woes are hard to underestimate: A few years ago, SUKAD did a survey amongst PMP®, asking them to name the life cycle phases of projects that they were working on. More than 50% listed the process groups, with some people leaving out the M&C group. If half of the certified PMP®’s out there are unsure, what about the less initiated?
Factors that contribute to this confusion may include:
Unfamiliarity of project managers with industry lifecycle models. It is a fact that people who have been exposed to those have no problem separating phases from processes.
Terminology, where process group names may be very similar – if not exactly the same – as some of the phase names.
Inconsistent naming of processes in PMBoK®: ‘Develop Project Charter’ and ‘Develop Project Management Plan’ hint at a once-off nature, while ‘Close Project or Phase’ is more in line with the repetition concept.
The ambiguity of the term ‘Develop’ in itself: In the very first phase of a project it would probably mean ‘create’, while in subsequent phases it would have to mean ‘expand’ as the original version of the Charter/Project Management Plan already exists.
If the above is the case, are there no phase initiating documents or phase management plans?
Fortunately many mature companies have a trademark in-house method, and most of those enforce the use of it for their projects. Those methods are easily compatible with PMBoK®, as PMBoK® is a universal framework, and not a prescriptive method.
But in companies without a method, project professionals and executives are often referred to PMBoK® as their only guideline, and therein lays a problem, for the above reason. With a major focus on processes it is easy to overlook the design of a lifespan for the project at hand, and without this the project is already at a disadvantage, as it will be extremely difficult to yield a successful outcome.
There also seems to be a widespread failure to distinguish between project planning and product definition. While they can overlap in time, the former is performed by the PM team, while the latter is performed by the technical staff of the project team. Yet the terms ‘planning’, definition’ and ‘design’ are often used interchangeably.
So it seems the overwhelming success of PMBoK® is also its downfall: it is so generic that it applies everywhere (well, to ‘most projects most of the time’) and it has its place, but it falls horribly short as a method.
If we compare for example with a method like PRINCE2®, we notice that PRINCE2® has 7 processes, comprising 40 Activities, similar to the 5 process groups and 47 processes of PMBoK®, and 7 themes, similar to the 10 knowledge areas of PMBoK®. In PRINCE2® the project lifecycle is designed as part of the tailoring effort and is done during the Initiating a Project Process.
However, only 3 of the 7 processes are then repeated in each delivery stage. These are:
Controlling a Stage
Managing Product Delivery
Managing a Stage Boundary
The remaining processes are:
Starting up a project
Directing a project
Initiating a project
Closing a project
These are only performed once on a project. There is little room for misinterpretation.
So, while the idea of progressive elaboration of a project is a noble one, its direct link with the concept of repeating process groups has become nothing more but a romantic notion, and in our opinion, very much out of place, except in a very generic theory of project management.
Isn’t it time PMI® re-think the positioning of its core product?
 Sadly, PMI extrapolated this PMBoK concept to Program Management. We believe in PgMBoK 2nd Ed. the absurdity of this concept reached its climax, and PMI was forced to revert to their PgMBoK 1 approach for the 3rd Edition. This has reverberated into PMBoK 5.
 Maturity is here taken as project management maturity defined by e.g. SEI’s CMMI model.
 “Methodologies and procedures take over where bodies of knowledge, such as the PMBOK Guide, leave off. Whereas knowledge guides … provide overview concepts … a project management methodology is custom-fit to the organizational context …” (T. Cooke-Davies/P. Dinsmore)
This is fifth of six project management challenges that are impacting the practice of project management and as a domain.
The last challenge that we discussed, dealt with the need for specialized project management, rather than generic practice across all types of projects and domains. Building on this last challenge, this one is probably the most difficult challenge to write about and the most controversial yet we believe it is quite essential to discuss. We have already written a few articles on certifications, particularly the Project Management Professional (PMP), but we address here from a different angle – the impact of certification on the domain and practices of project management. Continue reading →
“Certification nice but does not add significant value!”
“Eliminate the accidental project manager – certify them”
“Certification is required”
There are too many arguments and positions on the value of certifications so what is reality, if there is one? The reality is limited to one fact: there is no agreement on the value of certification; at least in the domain of project management. Continue reading →