In my previous blog I discussed the Project Manager Octagon. Simply put: the project management Control Triangle (Cost, Time, Scope) is by itself subject to external factors that are grouped in the Influencer Pentagon (Customer, Stakeholders, Risks, Quality, Resources).

Controlling the Influencer Pentagon is done by a balanced use of the Control Triangle. Tasks are added to the project, a budget for executing these tasks must be approved, and tasks are planned in time.  So far, the project manager seems to have the project pretty well under control, isn’t it?

But is this really the case? Well, only in part, I regret. It is my experience that one of the three legs of the Control Triangle is typically lagging. And this depends on how you run your project.

Two popular ways of running projects are, obviously, Waterfall and Agile. The observation is that mixing the two seems not possible. I will discuss the reason why in another blog, but I can already give one reason why the two are different. Waterfall and Agile project management are acting strong in two areas of the Control Triangle and are lagging behind on the third.

  • Waterfall project management usually starts with a description of the project targets. This typically includes hard target dates for delivery. I bet there would have been some frowning if Kennedy had put forward a proposal for “landing a man on the Moon and returning him safely to the Earth”, and then had added “but, no rush, take your time.”Waterfall project management therefore acts strong on the scope and time level. Once targets and milestones are communicated, a project manager will typically create a first work breakdown structure in the Waterfall project. Project resources are identified, and a high level planning put forward.

    Only after these tasks are completed, a first project budget is put together. Indeed, the cost calculation is made subordinate to the work to be performed. Typically, the cost is lagging with respect to scope and time in Waterfall projects.

  • Agile project management starts from high level Product descriptions, called User Epics. An Agile Scrum Team analyzes the User Epics and Team Members agree on how many weeks a sprint should take.
    Agile project management acts strong on costs and timings. Once the Scrum Team is established, the cost for the team is known. Most Scrum Teams will also be able to provide good initial cost estimates for tools and materials used. The use of sprints allows good control of the timelines and readiness of Product Increments in the next sprints.The uncertainty lies in what will be delivered in these next sprints. User Epics still need to be broken down in User Stories. Even though the Product Owner can prioritize User Stories, it is the Scrum Team who will tell how many User Stories can be completed in the next time-boxed sprint. This leaves a level of scope uncertainty.

    Moreover, the Product Owner can decide to stop further development at any time in the project. The Minimum Viable Product may have been reached, or the Product Owner can decide to not spend more on improving the Product.Consequently, the Product scope is made subordinate to time and budget absorbed in the project.

The question then is: who would be the third kid on the block? Which project management methodology would act strong on scope and cost, but less on timing? The truth is that it is not really a new methodology. Every seasoned project manager knows it as ‘project babysitting’. It is Change Project Management.

  • Change Project Management is executed as a series of changes that need to be closely followed up, but can be executed independently. An example would be the roll-out of a new software version over a large number of end-user machines. Each installation can be executed independent on a machine and requires a stand-alone change request.
    Change Project Management is based on individual changes using well known procedures. It only needs a project manager to follow up on the right grouping of the tasks; e.g. per department, or test machines first and production machines last.Change driven projects act strong on the budget and scope level. The operational people involved are typically identified early in the project, and so are the costs. The volume and scope of the work to be done, is well defined. The individual changes are part of standard Operational (or DevOps) work, and covered in known procedures.

    The challenge in the project then lies with proper planning of the Change Requests. The DevOps or Operational Teams involved have other things to do apart from project work. Project related changes will impact other projects or day by day work. There is a high risk that changes are asked to be delayed. The biggest challenge in Change Project Management is the timely completion of all project tasks.

This analysis already indicates that the three different project management methodologies have different strengths and weaknesses when changing a Product. Dependent on how you want to change or create a Product, you may want to choose a different Project Management Methodology! This is dictated by the Product, and should not be a personal preference of the PM or the PMO.

A PMO that only allows Waterfall Projects will soon discover that other companies are more successful in delivering Products with a vague a scope. Some PMOs have made the full switch and will only allow Agile Projects. They will find their project management methodology challenged for large, fixed scope and expensive infrastructure project with a single go-live.

Going through the paperwork for setting up a new Agile or Waterfall project takes its time. For many Product changes this level of red tape is not needed. Moreover, Agile focused organizations will discover that over time many User Stories are related to general maintenance. Follow-up on the work is still needed, but the costs for setting up projects would not be needed per se. I.e. both Agile and Waterfall driven organizations can limit project related costs by allowing Change Control driven project management. That is, if the risk on project timelines is accepted.

I have gone through this discussion with many managers running different types of projects. You may e.g. object that your organization is very successful in running Agile-only projects. It is an indication that you probably are in the software writing business, and your statement is 95% correct. Then again, will you also use Agile for building your data center? Will you build a small data center and ask your customer if it is a good one? If your customer says no, will you tear down the data center and build a new one? I don’t think so. The requirements for the data center must be clear upfront. A design will be proposed and approved and the data center built. I.e. even Agile driven organizations do need Waterfall.

In another discussion I met a project manager that would only do Waterfall projects. His organization did large construction work projects for the government. Indeed, in 95% of their projects the requirements were strictly defined in specification notes. Timelines were enforced, with penalties for milestones not met. Even then, the manager had to admit that their internal IT initiatives would go a lot smoother and with less risk for failure when run in an Agile track.

These two examples show the outer boundaries of the spectrum. Most companies will have projects that are somewhere in between those two extremes. In other words: most companies will profit of a mixture of Waterfall, Agile and Change Control project management.

The question is then: how to decide which is the best track to follow? Ask yourself the following question. Do you allow your customer to change the project requirements at any time? Will your customer happily agree with changes in costs and timelines when you decide to change the Product design? If the answer to these questions is no, an Agile project track may not be the best choice, and you may want to go for a Waterfall project.

Another complexity lies with the integration of deliverables coming from different (type of) projects into a single Product. This is part of the Chagwa project methodology, and I will discuss this more in the coming blogs.

The ideas in this blog are part of the Chagwa Project Management methodology,

Read more about the Chagwa Project Management theory: