WHOW matrix

‘WHOW’ is a combination of what and how. The term was coined by Professor David Dombkins in 19971 to describe a 2 x 2 matrix that helps understand project complexity and how this affects project life cycles.

The matrix builds on work previously published by Turner and Cochrane in the International Journal of Project Management in 19932 and further developed by Obeng in 19953.

Turner and Cochrane’s original ‘Goals and methods matrix’ suggested two parameters for the classification of projects:

  • How well are the goals defined?
  • How well are the methods of achieving them defined?


Turner and Cochrane's goals and methods matrix


This resulted in four types of project which Turner subsequently labelled Earth, Water, Fire and Air in his book ‘The Handbook of Project Based Management’4.

Obeng further developed this idea, giving the four types of project names that have since gained much more traction: Painting by numbers; Going on a Quest; Making a movie and Lost in the Fog (note: if you are trying to compare the two, bear in mind that Obeng, in contrast to Turner, put the how/method on the horizontal axis and the what/goals on the vertical axis).


Obeng's project matrix


This article focuses on the version of the model developed by Dombkins to understand how these classifications affect the project life cycle.

Dombkins arranged the matrix in a different way to both Turner and Obeng; reverted to simple titles (A to D) and introduced the key word: ‘uncertainty’. A table showing how all three versions of the classification relate is at the end of this article.


Dombkins's WHOW model project matrix


He then went on to explain how the project life cycle should be adapted in each case. Dombkins life cycle comprises four phases: Concept, Design, Implementation and Close. (Broadly equivalent to Identification, Definition, Delivery and Closure in the Praxis life cycle). For each type of project, he drew the life cycle as a series of circles/ellipses that illustrate both the relative effort and the serial/parallel relationship of the phases.

All projects and programmes seek certainty of both ‘what’ and ‘how’. Hence all the life cycles progress towards the top right corner of the matrix over time.


Type A projects

In type A projects both the objectives (what) and the method of achieving them (how) are certain, therefore the concept phase is relatively small. Emphasis can be placed on resolving predictable issues before implementation begins and then coordinating implementation through standardisation and detailed planning.

There is little need for recursiveness and the phases are broadly linear.


WHOW model type A project life cycle


Effort during the concept and design phases is focused on detailed design and coordination using well established tools and techniques, rather than innovation.

Tools such as work breakdown structures, critical path analysis and risk analysis are well suited to type A projects. The detailed specifications of these projects make them suitable for competitive tender under fixed price contracts. This is why Obeng refers to them as ‘Painting by numbers’ and Turner identified them as being typical of the Engineering industry.


Type B projects

Type B projects are more certain what the objectives are. The uncertainty is around how those objectives are to be achieved. This means that, like type A projects, the concept phase can be relatively short and simple.


WHOW model type B project life cycle


Dombkins uses the example of a tunnelling project where the overall objective is very clear but the design may have to respond to different ground conditions as they are encountered. The design and implementation phases therefore need to be recursive. The emphasis needs to be on responsiveness and innovation with a cyclic relationship between innovative and detailed design. (see also Concurrent Engineering)

Because they cannot be fully detailed before implementation, planning for type B projects is much more complex than for type A projects. If a type B project is being put to competitive tender it needs to be based on a performance-based contract where the ‘what’ is a specified outcome and the ‘how’ is left to the tenderer to design and implement.

The arrangement of the phases in the diagram illustrates how the project moves from high uncertainty to low uncertainty as the design and implementation progress.

Organisational cultural change projects would also typically be of type B. Obeng refers to these as ‘Going on a Quest’ projects.


Type C projects

Type C projects are clear in how the work will be done but unclear on what is required. Dombkins gives the example of an organisation that has a training capability with well established skills and processes that are waiting to be used on a project once the objectives are known.


WHOW model type C project life cycle


The key phase in type C projects is the concept phase. Once the objectives are defined, the well-established processes for the how can move into action. Once again, the diagram shows how the project moves towards low uncertainty in both what and how as the life cycle progresses.

The focus of the concept phase needs to be on innovation and flexibility but after that, the design and implementation phases resemble a type A project. Dombkins relates this to Mintzberg’s ‘adhocracy’ type of organisation where two different organisational designs are interconnected but interdependent.

This is exemplified by the split of planning into two stages:

  • Planning the concept phase is treated as a complex project with allowance for recursive and non-linear activities (similar to a type D project). Discovery planning deals with uncertainty here.

  • The design and implementation can be planned with an approach similar to type A projects.

An example of a type C project might be a hotel or office building where the outline business case is clear and the construction processes are very clear but research is needed to determine the best configuration to optimise the business case.

Type C would also apply to agile software development where skills and techniques (e.g. scrum, kanban, development environment etc.) are well established but the objectives are unclear.


Type D projects

Type D projects are the most complex. Neither the objectives nor the means of achieving those objectives are clear.


WHOW model type D project life cycle


The diagram for type D project shows equal emphasis on the concept, design and implementation phases; the considerable overlap and their recursive nature. Innovation and flexibility is required at all stages.

Many would argue that this is the ideal environment for Agile methods.

At Praxis Framework we advocate that the flexibility needed requires an understanding of all approaches, Agile and otherwise, so that a project manager can decide how different elements of the project will be managed.

It is no accident that the life cycle of a type D project spans all four quadrants and will probably have components from all four quadrants at some point. It is unlikely that one single approach will meet the needs of every element of a type D project.

Dombkins proposes two strategies to deal with type D projects:

  • Use discovery planning to transform type D projects into type B projects by resolving the projects objectives

  • Adopt a systems approach to resolve what and how simultaneously using an integrated team of functional design and operational specialists (similar to scrum teams or concurrent engineering).

In type D projects, even concept and implementation are integrated. Use of pilot projects and prototypes will be common. The response to complexity advocated by the Cynefin Framework is useful here – ‘Probe, Sense, Respond’.

In type D projects there will be a lot of negotiation throughout the process between sponsors, stakeholders, technical and operational specialists (product owners).


Like any other model, the WHOW matrix is not definitive or perfect. It is one of many models that a competent project manager will understand to help make sense of whatever type of project they encounter.




A quick cross-reference of the three versions of the basic model is shown below:





  1. Dombkins, D. H. (2007). Complex Project Management: Seminal Essays. North Charleston, South Carolina: Book Surge Publishing

  2. Goals-and-methods matrix: coping with projects with ill-defined goals and/or methods of achieving them, J.R.Turner, R.A. Cochrane, International Journal of Project Management, Volume 11, Issue 2, May 1993, Elsevier

  3. All Change! The Project Leader's Secret Handbook (1995) Financial Times Pearson Publishing

  4. Turner, J.R. (1999), The handbook of project-based management, 2nd edition, MacGraw-Hill, Maidenhead Berkshire, ISBN 0-07-709161-2


Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Back to top