Whenever I see a hat or item of clothing that has to go over my head labelled “One Size” I know it will not fit me, because I have a big head. I also know there is rarely a perfect fit for project management (PM) methods unless they are tailor-made. But, just as with clothing, few companies have the budget for the tailor-made PM option. This just means we have to learn how to choose our PM processes carefully.

Many projects are not well-suited to a traditional Waterfall approach because the end-product cannot be fully specified and documented at the outset. These projects are not necessarily suited to an entirely Agile approach either, where it may not be desirable, or even possible, to deliver “bite-sized” chunks at regular intervals in order to refine what the end product will be. Even certain large, complex IT projects are ill-suited to an Agile approach because they require a measure of discipline and control.

As PM and the Agile approach matures, it’s becoming clearer that some projects require traditional PM combined with flexible PM and often something else thrown into the mix; this might be internal processes developed for a specific organisation, or a project manager’s experience in knowing what methods deliver successful outcomes.

For many projects, the answer to the question “Which PM method is the best fit?” is not always clear. This is especially true for projects that are breaking new ground or using cutting-edge technology in a fast-paced environment.

But just how easy is it to combine traditional and Agile methodologies? First, it is important to select a core method from which processes can be removed or added as necessary. Without a core method, there is a risk that the project could descend into chaos and that those involved would not understand what is expected of them.

The case for a core Agile approach

The fact that Agile project management is based on iterations should immediately indicate whether it is suitable as the core approach for a particular project. Clearly, you cannot build a bridge or a railway using an iterative approach, but a less tangible product such as a new business process or a software system (which can be subject to user testing and refining) is well-suited to an iterative approach. Each iteration is likely to be over a relatively short, finite period of no more than several weeks (although this depends on individual projects) and deliver a completed package that can be tested standalone.

Bear in mind that this isn’t as easy to implement in complex scenarios where inter-dependencies come into play. Even in projects classically suited to Agile methods, it has its disadvantages and may need to be adapted to work effectively. Another major disadvantage with an Agile approach is not being able to estimate costs upfront; if you cannot describe exactly what will be produced and when, then it is difficult to provide an accurate cost estimate. Agile proponents would argue that costs for a traditionally managed project rarely come in on budget anyway.

The case for a core Waterfall methodology

Waterfall is the traditional, and more formal, PM approach and has a series of defined phases to be followed in chronological order, so it imposes discipline on the various project tasks. The Waterfall method assumes that the final product can be fully specified and designed in the early stages of the project and is well suited to major engineering and building projects or projects that require strict regulatory control.

Its advantages include being able to: document what will be delivered in advance, assign adequate resources, and provide a detailed schedule of tasks. It also ensures that costs can be estimated upfront, which is essential for commercial projects for external clients.

Using a Waterfall method means that everyone involved in the project understands where and how it is going and what will be delivered and when. Risks and changes are all documented, controlled, and communicated so they can be well-managed, which is essential on large, complex projects, particularly when they involve disparate teams.

The case for combining Agile and Waterfall

Many internal PM frameworks combine methods without specifically recognising them to be from another method. Major organisations I have worked with have used an “iterative Waterfall” approach to software development without acknowledging any debt to Agile. Similarly, some Agile projects introduce communication plans or document tracking processes where detailed documentation is a necessary part of delivering a completed product.

In many of today’s complex business environments, projects require control and flexibility, which is why a combination of PM methods that offers both can work well. In essence, it is irrelevant how you describe which method is being used — what is important is that you understand the elements that are necessary to complete the project and when each task will be completed. You will either have to settle for a less-than-perfect fit with a standard methodology, adapt the most relevant methodology, or combine traditional and Agile approaches.

The evolution of PM

PM continues to evolve as more is learnt about why projects fail and succeed, and this evolution will lead to further changes. These changes may happen slowly, but I like to think that a more intelligent way to manage the complex projects our business worlds present to us will surely evolve.