How does CAMMP™ compare to global resources, frameworks, or methods? How does CAMMP™ compare to the PMBOK® Guide, ISO 21500, or PRINCE2? Continue reading
How does CAMMP™, The Customizable and Adaptable Methodology for Managing Projects™, compares to global guides like ISO 21500 and PMBOK Guide?
The following table summarizes the differences Continue reading
This blog post is extracted from Chapter 6 of our upcoming book, Project Management beyond Waterfall and Agile.
Summary of Previous Chapters
To summarize the relevant information from the earlier chapters, the current practice is:
- PMI and ISO are clear that they are not offering the community a method or methodology. They are providing a set of processes, project management process groups, and subject/knowledge areas. ISO 21500 mentions the need for product and support processes but does not address them.
- IPMA is also clear that it does not offer “how-to’s”; rather, it advocates the competence elements for managing projects. Here again, there is no method.
- GPM offers a method, but although its dependence on the process groups as a project life cycle is a weakness, its sustainability elements are of great value,
- It is important to state that PRINCE2® is a method, which is good; but for some reason, it is mostly known in the UK and other countries with organizations that have a UK influence. Th e author does not offer a dedicated chapter to PRINCE2, because CAMMP™ is an alternate solution that is more flexible and wider in scope.
Transition, Understanding the Challenges
The hypothesis of this book is that, despite the high value each professional association offers, there are still gaps in project management practice. Practitioners still struggle to apply what they learn in the real world, on real projects, and on different types and classes of projects.
In the world of projects and project management, certain fixed concepts apply regardless of industry or domain. Many variables are highly unique to the context of a given project.
Yes, organizations can use the IPMA’s ICB® and develop their methods using the competence elements.
Yes, organizations can use the process groups and subject groups from PMI/ISO to develop an internal methodological approach.
Some are doing so, but not enough!
In large organizations with abundant resources, their staff could explore the world of project management and choose what is best for their organizations from the available “menu” of options. Even in such organizations, one can find that they stick to one menu item, or one resource, for one reason or another.
While large organizations may limit their choices, small and medium organizations may not even have the luxury of selection. Consequently, they constrain their project management system—assuming they have one—and depend on the common sense of their accidental project managers. These organizations manage projects, or, more accurately, “execute” projects through accidental project managers, then wonder why the failure rate is so high. It is also possible
that these organizations think that they are delivering the project successfully; this might be so, but are they using clear criteria for measuring project success?
These practice gaps exist because organizations tend to box themselves into limited options. The gaps present us with opportunities to provide workable solutions. The fundamental principle of the offered solution revolves around integrating the best of what exists and offering it in a practical approach that can work for small or mega projects, regardless of domain, type, or class of project. Th is is a modest attempt to save organizations much research and development work.
What do you think?
At times, our clients ask us how do we compare the SUKAD CAMMP Model with other methods or guides. The quick answer is in this image. Continue reading
Project Management certification is highly popular among individuals and organizations.
Although the PMP® might not be the best for enhancing organizational performance, it is the preferred certification by those who want to make their CV looks better for potential employers; especially if they are looking for a new job. Continue reading
It is quite common for professionals in project management to use ‘method’ and ‘methodology’ interchangeably. Is this correct?
If not what are the differences?
The following is part of one chapter in our upcoming book on The Customizable and Adaptable Methodology for Managing Projects™ (CAMMP™). Continue reading
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
- Secondly, it has never been really tenable.
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)
 See the SUKAD 4 D’s
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