Bridging the gap between PMP, PMBOK, PRINCE, CMM, Waterfall and agile is the in thing now, so let me share my two cents on this. The basic question I am asking is whether we should build the gap or bridge the gap. Just because Agile is redefining the I.T project management landscape and all those proponents of standards based heavy weight models are on a catch up mode with Agile and are busy building bridges. My professional view is to burn those bridges to maintain the uniqueness of these models, so that they can exist and continue to serve humanity for the purposes for which they are created.
Word of caution
In English, the original meaning of the idiom ”burning own bridges” means a point of no return. Here what I mean by the ‘bridge’ is the attempt by organizations and individuals to merge the gaps between different models. So the basic point of argument is ‘should we find a common ground among these models’ or allow them to exist and flourish in their own forms, providing amble choices for the project teams to choose from, based on their project’s needs.
After spending a quarter of a century in practicing waterfall, agile, pmp, pmbok, adhoc, cmm…in project companies, product companies, you name it, it is quite possible that I have a had a tryst with it, either successful or unsuccessful. By qualification I am a PMP, PRINCE2, CSM,CSP apart from Bachelors in electrical engineering and Masters in quality management. I have trained around 3000+ project managers or would be project managers on PMBOK or Agile (SCRUM). Have worked with twenty five teams in implementing SCRUM, took part in the development of a scrum tool as the product owner. So let me believe that I have the credential and the required experience to comment on this.
First of all, a comparison between PMP and Agile is useless because PMP is a certification given by PMI, USA for project managers, and Agile represents a family of light weight project management / execution models. So no point in comparing between a certification and a model. So this comparison is futile. A comparison between PMBOK (the project management body of knowledge) and any one of the agile models is slightly better, but not perfect, because PMBOK is just a collection of project management best practices. It does not advocate any specific way of compartmentalization of the project activities. For example, PMBOK advocates the uniqueness of every project, and the need for developing an appropriate project strategy that will suit the needs of the project at hand. The same PMBOK talks about rolling wave planning, which is the backbone of the agile family. The concept of ‘progressive elaboration’ of a project is more suited to agility, than rigidity. So, PMP is a certification, and PMBOK is very neutral when it comes to defining the project strategy, and is built on the ‘progressive elaboration nature’ of projects. This is the perspective I get when I look at things from a PMBOK,PMP perspective.
Now, let us take a look from the Agilist perspective. Going by the model defined by Ken Schwaber (SCRUM), It just talks about a product backlog which is allowed to grow indefinitely, planning meeting, sprint backlog, tracking board, burn down charts, daily scrums, demos and retrospectives. It is not talking much about the project level planning (road map), project level budgeting, contracts, risks, human resource management, quality management, communications management, procurement management, time management, scope management, cost management and integration management. In order to manage a project effectively the knowledge about these aspects are very critical. Agile models are not against imbibing any knowledge / best practice that will improve the deliverables. Agile models, especially SCRUM is a wrapper, which can wrap any relevant best practice that will make the project’s deliverables more valuable to the customer.
A gap do exist between PMP, PMBOK and agile models, and they are complementary. Here the basic question to be asked is whether we should bridge the gaps or build (maintain) the gaps to protect the uniqueness of these models, so that they can cater to specific types of projects. We must conclude on this question first, before proceeding further. Personally, I would support building the gaps than bridging the gaps, so that predictive models like PMBOK, PRINCE2 can cater to a specific type of projects where the requirements are very clear and the engineering discipline do not permit changes (civil, electrical, mechanical) where as the adaptive models (agile) like SCRUM, XP, Crystal, TDD, RUP etc can cater to a different type of projects where requirements are highly evolutionary and technology is very new.
So if, our discussion need to be fruitful, it has to be confined to a specific type of project. Let us anchor our discussions around I.T projects, and accept the fact that for civil, mechanical, electrical projects, barring the design phase, agile will not work, because of the rigidity of the engineering discipline.
With due regards to the founders of the heavy weight models let me say this, most of the implementations are flawed. On this, whenever I tried to prove myself wrong, by asking several engineers (programmers), for the low level design document, which they are supposed to follow for coding, they stared at me as if I am asking for some strange things. Most of the implementations of the heavy weight models are rule based, rather than value based, and are insensitive to the customer’s business needs. The founders did not intend it to be like this, but unfortunately the implementers made them like this. Most of my living come from working with level-5 companies to implement level-2 KPAs of project planning, tracking and oversight. Majority of them have bought M.S project licenses and are using them as glorified word processors. If you want to validate my argument, please ask these questions to the project managers from these types of organizations;
- What is the current schedule performance index?
- What is the current cost performance index?
- What is the TCPI (to complete performance index)?
- Can I see the critical path of the project?
These are the basic project management ratios, one has to have, if they are following classical, conventional project management. Most often you will not get the answer, instead you will hear things like;
- They are changing the requirements very often, so we are unable to draw a plan
- The customer does not care for it
Then how do they really manage?. Using excel sheets, post its, project wikki, status update meetings…..most of these are very familiar terms in the agile world. Here the root cause is, we have chosen a project management method, which is not in alignment to the project strategy. The other side of the story is even more interesting.
During the initial days of the consulting assignments for implementing Agile (SCRUM), in organizations which has already embarked on to the journey, we hear things like ”We are following SCRUM, but a tailored version of it”. What is the underlying meaning?. We are following all the SCRUM ceremonies like planning meetings, daily stand ups, demos, retrospectives etc…but we follow work allocation, velocity calculations are not available, the daily stand ups lasts for 40 minutes because the project manager converts it into a issue resolution meeting, within a sprint we have requirements, design,coding,testing phases……the list is not complete. This is SCRUM falling. A combination of SCRUM and waterfall. You adopt the SCRUM structure, and within that create waterfalls. Many of these terminologies are a hangover from the waterfalling. So building bridges knowingly or unknowingly will be like mixing coffee with tea. Good coffee by itself is great, and there is nothing to beat good Tea…once you mix it…it is gone.
The organizational need
Unless it is a start up, organizations will have some existing project management practices in place. Very large organizations are likely to have the baggage of heavy weight, rigid practices evolved over the years. The unwritten rule is, ”any thing new must co-exist with the existing”. If we look at organizations from India and China, considered as the main outsourcing destinations of the world, very often they are not empowered to choose the project management methodology, and it is imposed to them by their customers both internal and external. The best strategy for these organizations is to have capabilities in every other model available, in it’s purest form, without trying to merge them.
The key benefits
- Ability to recommend the appropriate project management method to the customer, very early in the project life cycle, preferably during the negotiation stage itself.
- Ability to ask the right questions, at the right time, with confidence.
- An open enterprise project management systems architecture, which can improve the current practices, imbibe new practices from the industry without diluting the practices.
- Project centric outlook. The project is the organization. Everything else is a support system to the project.