When I’m running Project Management training these days, with a diverse range of clients, I find myself increasingly challenging people to think about what type of project they are trying to manage. Often, they are aware of Waterfall and Agile as two potential approaches (possibly at opposite ends of the spectrum). Given that starting point, it’s a quick leap for them select a particular methodology or philosophy! My view is, they need to think a bit more deeply before making that choice.
Back in 1993 Turner and Cochrane published their “Goals and Methods Matrix” in the International Journal of Project Management. They suggested that projects can be judged against two parameters: how well defined are the goals, and how well defined are the methods of achieving them. This leads to four types of projects.
Dombkins expanded on this in 1997 with his discussion of complex projects where he suggested a test to identify whether a project is complex, is to ask:
- Are WHAT the objectives of the project unclear?
- Are HOW those objectives are to be achieved unclear?
If the answer to at least one of these is ‘yes’, then the project is complex. The consequence is that the use of “standard” project management tools and processes is inappropriate and complex projects need their own tools and processes if they are to succeed. Dombkins referred to the two dimensions of uncertainty as the WHOW Matrix. WHAT refers to the degree of uncertainty about the objectives of the project and HOW refers to the degree of uncertainty about how to achieve the objectives.
Eddie Obeng’s take on the WHOW Matrix was to give each of the quadrants a memorable descriptive name:
- Painting by numbers (Clear What and How) [Dombkins Type A, Turner & Cochrane Type 1]
- Quest (Clear What, but unclear How) [Type B, Type 2]
- Movie-making (Clear How, but unclear What) [Type C, Type 3]
- Fog (both What and How are unclear) [Type D, Type 4]
Type 1 Projects:
Type 1 projects (Painting by numbers) are clearly defined and well-understood; for example many repetitive construction and engineering projects such as building or refurbishing houses, offices or roads. Techniques to manage these are well-developed and the Project Manager’s job is speed them through a largely linear lifecycle of Initiation, Planning, Implementation and Close-out.
There is lots of documented “Best Practice” to draw on and lessons learnt from previous projects. Most risks and issues are predictable and can be readily resolved. Most decisions about plans and resources can be made early in the project lifecycle. Plans can be detailed and prescriptive: Waterfall fits well.
Type 2 Projects:
Type 2 projects (Quest) have clear objectives, but there is uncertainty over how these can be achieved. Many organisational improvement projects fit into this type; for example cost reduction, cycle-time improvement and customer service improvement. Product and policy development projects are also often like this.
The initiation stage is short, but planning typically requires a rolling wave approach as it is not possible to specify the implementation approach at the start. Options and more information will emerge during the project and there may be decision gates to select the most viable option, at which point the next wave of planning can be started.
For improvement projects, the DMAIC process can be adopted, with phase one being iterations in Define-Measure-Analyse and phase two being Implement-Control.
The Project Manager’s role is to coach the team and stakeholders through the complexities of decision-making and option-evaluation, which will be time-consuming and resource intensive. Agile methods such as Scrum may be appropriate here, particularly in the option development phase, together with a focus on milestone planning. The implementation phase may become a Type 1 project, amenable to more prescriptive planning.
Type 3 Projects:
Type 3 projects (Movie-making) have clear processes, but unclear outcomes and often success can only be judged at the end of the project, once the outputs have been adopted by customers and users. Making movies, TV and radio programmes have well-developed processes, but whether the end result will be a blockbuster or a flop, is uncertain at the start. Many market research projects will also be like this; they have defined processes, but there is no way of knowing what answers the research will come up with. IT and systems development projects are often also of this type.
In these projects, a method has usually been decided, or is obvious, but what the project will deliver is subject to negotiation and may be heavily influenced by the creativity of the people involved. These projects need more time and effort in the initiation stage where the focus will be on defining the objectives.
Agile methods may be appropriate, for example in identifying, prioritising and agreeing customer requirements, and subsequently in delivering working solutions that the customer can sign-off (e.g. pilots, tasters, proofs of concept). Once the concept has been signed-off, it may be appropriate to adopt more linear planning approaches (rather than iterative), in which case the project then looks more like Type 1. A Kanban approach with Work in Progress limits (WIP) to managing tasks through the known stages may be more applicable than Scrum, here.
The Project Manager’s role is to help the team craft a viable solution, whilst encouraging innovation and retaining a degree of flexibility within agreed milestones.
Type 4 Projects:
Type 4 projects (Fog) are the most complex projects because neither the What nor the How are understood at the start. We may know “something needs to be done”, but can’t be specific enough to work out how to run the project.
Many pure Research and Development (R&D) projects as well as Organisational Redesign and Change programmes fit into this type. They cannot be planned to any level of detail since they require both innovation and flexibility.
The most obvious strategy for a Type 4 project is to try to get clarity over the What and turn it into a Type 2 project. This requires a great deal of stakeholder involvement in working through possibilities so that a “best” answer emerges and is owned. There is unlikely to be a “right” answer because of conflicting stakeholder requirements and there may be a variety of options for implementation (How). Problem and solution structuring tools such as Affinity Diagrams may be more useful than conventional “planning” tools. In some cases, it may be appropriate to run with, and test, multiple options and learn from what works, until a final preferred solution emerges.
So, in summary, not all projects are the same, so please consider what type of project you’ve got before you decide how to approach it. One size does not fit all!
Download the full article as a pdf.