Dombkins WHOW Model

Section 2: WHOW Matrix and Wave Planning
389
The Varying Nature of Projects
Not all projects are the same. For example, projects such as Research and
Development are very complex, while others such as office fitout are very simple.
Therefore, it is critically important to understand the nature (underlying inherent
characteristics) of a project before commencing on a project / program. Complex
projects are very different from simple projects in their nature and the way they
need to be managed.
r------------------,
Terminology
The following words will be lIsed interchangeably
CERTAIN
.- ...
CLEAR
UNCERTAIN
.- ...
UNCLEAR
Nature of Simple Projects
Simple projects resemble the machine model of organisations - experts design
the systems and processes, and standardise the work process. In simple
projects, as with bureaucracies, innovation and flexibility are not only not
required, they are actively stopped (Jay, 1967). Simple projects are also linear (a,
b,c,d,e, ... ) and the life cycle phases of traditional project management follow
sequentially.
The following questions allow us to determine whether a project is simple:
are WHAT the objectives of the project clear?
is HOW those objectives are to be achieved clear?
If the answer to both of these questions is 'yes', then the project is a simple one.
Being simple or complex has nothing to do with the size of the project. Many very
large projects are simple in their nature, while some very small projects are
complex in their nature.
Because the definition of what is to be achieved is clear, and how the objectives
are to be achieved is also clear, detailed decisions relating to all phases of the
project life cycle are able to be made in the concept and design /planning
phases. Based on this fine grain planning, the overall process is able to be
standardised, planning is linear, and project management processes used
resemble the bureaucratic model of organisations.
Nature of Complex Projects
As discussed in Section One, chaos has similar characteristics to complex
projects - it is non-linear and recursive. The pattern in complex projects is more
Dombkins, D. (1997) PROJAM: The Management of Complex
Projects and Programs
likely to be c, a, d, a, e, c, b, ........ , instead of the linear, a, b, c, ....
In contrast to the bureaucratic focus of simple projects, complex projects are
closer to the organic model, where innovation and flexibility are vital.
A test to identify whether a project is complex is to ask the following questions:
are WHAT the objectives of the project unclear?
is HOW those objectives are to be achieved unclear?
If the answer to either or both of these questions is 'yes', then the project is
complex.
Because either the definition of what the objectives are, and / or how the
objectives are to be achieved are either or both unclear, detailed planning over
the project life cycle is not possible. For complex projects the planning processes
need to build in flexibility and innovation through incorporating recursiveness and
non-linear learning circles.
Project Management Systems
Both the management of simple and complex projects use standard tools and
processes, but these standard tools and processes differ between simple and
complex projects. A general rule for projects is that without the use of standard
project management tools and processes, all projects (simple and complex) head
towards chaos (Stringer, 1982a; Stringer, 1982b; Stringer, 1982c). Complex
projects need their own tools, processes, and configuration if they are to be
successful.
The limitations of the tools and processes of traditional project management is
highlighted by its approach to risk management which is expanded upon in
Appendix I. The following extract from PMBOK defines its approach to what it
sees as risk.
"In the context of project management, project risk may be defined as the chance
of certain occurrences adversely affecting project objectives. It is the degree of
exposure to negative events, and their probable consequences..... Risk
management may therefore be defined as follows: Risk Management, in the
project context, is the art and science of identifying, analysing and responding to
risk factors throughout the life of the project and in the best interest of its
objectives." (PMBOK, 1987)
Figure No. 2.1 puts the traditional project management approach to risk into
perspective. Risk management only deals with issues where probability and
scenario planning type approaches apply - risk management only deals with a
sub-set of the uncertainty continuum.
390
RISK MANAGEMENT - A SUBSET OF UNCERTAINTY
Risk
Management
Simple Projects
New Tools and Processes
Complex Projects
..... I----..... ~ I ..... 1-----------1...
Low
Uncertainty
FIGURE No. 2.1
High
Uncertainty
Uncertainty
The level of uncertainty that organisations have to deal with is continuing to
increase. With this increase in uncertainty organisational configurations that were
established to operate in stable environments, can fail. This applies to both
bureaucracies and project management.
Many organisations with a bureacrtic driven strategy are failing to generate
competitive performance. To deal with this lack of performance, many of these
organisations have engaged in restructuring, downsizing, and outsourcing.
Unfortunately the same mindset (focused on stability) has carried over into their
approaches to managing change and outsourcing.
Traditional project management is well suited to projects where the project has
clarity in scope definition (they are fully designed and specified). Traditional
project management tools such as the Work Breakdown Structure, Critical Path
Planning and Resource Leveling are based on the premise that a project's design
can be fully detailed before the project is implemented - this means that a fully
developed decision tree can be developed prior to implementation.
Where there is a high level of uncertainty, decision trees cannot be developed,
yet alone resolved prior to implementation. In these undertakings, traditional
project management tools are of no use. As mentioned previously, IT, Change,
and Defence undertakings have all provided multiple examples where reliance on
traditional project management has led to failure.
A similar phenomena has been seen in strategy. The Design School (Porter,
1980) has strategy fully designed up front by experts, whereas the Emergent
School (Mintzberg, 1990) proposes that it is not possible to design a strategy up
front, and that strategies emerge over time. Research into success in
implementation of strategy suggests the design school approach is not working.
(Marx, 1991 and Pasmore, 1994). The emergent school in its pure form as
described by Mintzberg is deterministic and leaves little opportunity for managers
to have any impact on determining their future.
Strategy is suffering from the same problem as project management. The reality
391
is that strategy exists in a highly uncertain environment where it is impossible to
identify all the questions up front, let alone resolve all these questions prior to
strategy implementation. Using existing project management and strategic
planning tools and processes this leads to Mintzberg's deterministic view of
organisations.
This exegesis, proposes voluntarism, rather than determinism - it proposes that
organisations can influence their own destiny through using Projam management
to manage complexity.
The underlying assumption is that organisations, projects, and programs need to
fit with the level of uncertainty in which they exist. A new definition for uncertainty
is needed for Projam management that expands the scope of uncertainty beyond
risk management.
Uncertainty has three dimensions:
uncertainty in WHAT the objectives are
uncertainty in HOW the objectives can be implemented
maturity - uncertainty is not an absolute quantity for a particular project or
environment. What is highly uncertain to one individual/organisation, may
not be uncertain to another individual/organisation.
The first two of these dimensions of uncertainty (What and How) are brought
together in the WHOW Matrix as shown in Figure No. 2.2. This matrix reverses
the usual arrangement of low and high uncertainty to provide a linear flow pattern
for traditional project management's four life cycle phases. The third dimension,
maturity, is dealt with in Section Three.
Low
Uncertainty
WHAT
Concept ~ IlIlpleownt"tion
~ Design 0 Fin"lis"tion
High ~ ~
Uncertainty 1-- --'"'- ---'
High HOW
Uncertainty
Low
Uncertainty
GURE No. 2.2
FI
392
The WHOW MATRIX
The WHOW Matrix is a key tool in understanding, planning and implementing
organisational change. The project management literature has developed tools
for simple projects (Type A), but has failed to provide a framework within which to
view complex projects and has failed to develop tools to manage high
uncertainty. The WHOW Matrix provides a contingency framework for projects
and programs.
The WHOW Matrix is broken into four Types - (Type A, Type B, Type C, and
Type D). Each of the Types is described as a pure Type that varies in respect of
the uncertainty of WHAT and HOW.
WHAT- refers to the degree of uncertainty about the objectives of the project. In
organisational change projects Mission and Vision are examples of WHAT. The
strategic intent is the desired outcome of the change project.
HOW - refers to the degree of uncertainty about how to achieve the project
objectives. In organisational change projects, implementation of strategy is an
example of HOW.
Most projects are not of a pure Type, but show stronger similarities to one of the
pure Types, than to the other Types. Equally, a project can combine a
combination of Types as it progresses, while other projects remain within a single
Type classification.
In organisations, the Mission and Vision define WHAT the objectives are, and the
implementation process defines HOW the Mission and Vision are going to be
achieved.
Positioning Projects on WHOW
Depending on the degree of uncertainty of WHAT and HOW, a project can
commence at any point on the WHOW Matrix and can follow a linear or a
recursive behaviour, or a mixture of both.
393
CLEAR WHAT, UNCLEAR HOW FLOW PROCESS:
Low
Uncertainty
WHAT
High
Uncertainty
High
Uncertainty
HOW
Low
Uncertainty
Concept 0 Implementation
o Design 0 Finalisation
FIGURE No. 2.3
Figure No. 2.3 shows the flow process in a project where there was relative
certainty in What the objectives were, but a lack of certainty in How those
objectives were to be implemented. In this project a two stage pilot process was
used, with redesign after each pilot, to resolve How before the overall
implementation was attempted. This project shows a linear progression along the
life cycle phases, but has recursive loops between design and implementation. A
tunneling project has a similar pathway - as new conditions are discovered
during excavation, the design is revised, and so on.
The positioning of a project on the WHOW matrix tells us a lot about the project.
It gives guidance on what phase of the project life cycle is going to be the most
important, on how to procure the project, on how to plan and manage the project,
and to what degree stakeholders must be involved. The degree of uncertainty
affects the degree of emphasis on different project phases.
The following are examples of projects positioned onto the WHOW matrix.
394
Factories, schools and project housing are good examples of Type A
projects.
The Sydney Harbour tunnel project was a complex project. There was clarity
in WHAT the objectives were, but high levels of uncertainty in HOW it was to
be achieved. The Sydney Harbour Tunnel project falls in Type B on the
WHOW matrix.
Techniques to design and build office buildings are well developed. Most
major construction companies can complete a thirty-storey office building
faster than the time it takes to construct an architect designed house. In office
building projects there is relative certainty about HOW the objectives are to
be achieved. On the other hand WHAT type of office building should be built
is the more difficult issue to be resolved. Office building projects are
moderately complex and fall in Type C of the WHOW matrix.
Another good example of a Type C project is a feature film. The techniques
for making a film are well known, however, WHAT film to make is the key
question to be resolved.
Very few construction projects are highly complex as in most cases either the
WHAT or the HOW are relatively clear. The best example of highly complex
projects are Research and Development Projects. In R&D projects there is
often little clarity in either WHAT the objectives are or HOW those objectives
are to be achieved. R&D projects are highly complex and fall in Type D of the
WHOW matrix.
A review of eight major programs using the WHOW Matrix, with each of the
programs broken down into its sub-projects is shown in Figure No. 2.4
Analysis of Programs
Unclear HOW Clear
Clear
WHAT
Unclear

3 b
1b
4a

8e 1r
3 a 3
43 e 3 e
8e7a
1d 2 b
7e
4b2
1
8h 1
1f
8a
!fb
2e
1a8b6
5b 7
I. Organisational Change Program in
a multinational organisation
In Corporate image
J b HRM development
Ie Media guidelines
Id Corporate business strategy
Ie Best tender practice
If Marketing development plan
19 Media publication review
2. Raillnfraslruclure -- $50001
2a Tunnel illld track project
2b Stations
2c Interfnce to rail network
2d Contract negotiation
1 Hospital redevelopment
program -- $250111
3n Acute care services building
3b Childrcns hospital
3c WOOlens hospital
3d Services centre
3e Infrastructure
4. Tallroad $500m
4a Bridge, road & tunnel
4b Toll collection system
5. Office Building $20rn
5a Office building project
5b Office fitout
6. Airport Terminal extension - $160m
7. CSD Office Development - $500m
7a Car park
7b Podium
7c Hotel
7d Apartments I holel
8. Urban Redevelopmenl-$2XOm
Xa Concept development project
Xb Stakeholder partnering process
8c Marine works
8d Roadworks
8e Demolition
Sf Parks and communal facilities
8g Residential Buildings
811 InfrastrUC\llre
FIGURE No. 2.4
These four Types of projects are discussed below:
395
Type A Projects
Type A projects are clear in both WHAT the objectives are and HOW those
objectives are to be achieved. Project homes fall clearly as Type A projects on
the WHOW matrix.
Unclear
SIMPLE PROJECTS
HOW
Clear
A
Clear
WHAT
t-----......-F------I
Unclear
FIGURE No. 2.5
In Type A projects (refer Figure No. 2.5) the concept phase is simple because
WHAT is clear. In the design / planning phase, since the WHAT is clear, the
emphasis is placed on resolving predictable issues before implementation begins
and on coordinating the implementation process through standardisation and
detailed planning. Type A projects have little recursiveness or non-linearity in the
concept and design / planning phases. The concept and design skills are not
focused on innovation, but rather on detailed design and coordination. Because
design can predict the implementation process relatively accurately, the design
process can operate independently of the implementation process.
Type A projects use Holistic planning - when both WHAT and HOW are clear, it
is feasible to resolve most decisions during the concept and design /planning
phases. Planning is, therefore, highly detailed and prescriptive - tools such as
critical path analysis, work breakdown structures, and risk analysis are well
suited to simple projects (refer section 3).
Because highly detailed specifications and planning can be completed in the
concept and design phases, Type A projects can be easily put to competitive
tender for firm lump sum bids. Tenderers are able to prepare competitive bids
based on a clearly specified design. Stakeholder involvement is limited as most
decisions regarding planning / design are made prior to the implementation
phase.
396
Typical Type A projects are:
a technical skills audit of a department
project housing
most construction projects
Type 8 Projects
Type B projects (refer Figure No. 2.6) are clear in WHAT the project objectives
are.
Unclear
B
COMPLEX PROJECTS
HOW
Clear
Imple
WHAT
Concept
Unclear
FIGURE No. 2.6
Clear
397
Therefore as with Type A projects, the concept phase is short and simple.
However, unlike Type A projects, Type B projects are unclear in HOW the
objectives are going to be achieved.
Tunnelling projects provide good examples of this. As tunnelling progresses,
differing ground conditions will be encountered that require different design
solutions - this creates an ongoing recursiveness between design and
implementation. The Pareto model of decision making (refer section 3) is used on
projects where there is uncertainty in WHAT or HOW or both - decisions are
made progressively over time.
In Type B projects the design emphasis is on responsiveness, innovation and
flexibility. There is an ongoing cyclic process between innovative and detailed
design, and between design and implementation changes, as it is not possible to
predict the overall implementation process. The recursiveness dictates a high
level of reciprocal interdependence between design and implementation.
Planning of Type B projects is much more complex than for Type A projects.
Because it is not possible to resolve all decisions in the concept and design
phases on Type B projects, it is not possible to prepare highly detailed
prescriptive plans. The high recursiveness between design and implementation
needs to be planned differently to Type A projects. Research has shown that the
planning of complex projects consumes twice as much resources as that
required for Type A projects, and that allowance for variances needs to
quadruple on complex projects compared to Type A projects (Laufer, 1991).
Because it is not possible to fully detail Type B projects, it is not possible to call
competitive tenders based on a clearly specified design. Type B projects are
better tendered using a performance based contract where the WHAT is used as
the specified outcome and the HOW is left to the tenderer to design and
implement. Stakeholder involvement (Management by Stakeholder) becomes
critical because of the recursiveness between design / planning and
implementation.
Typical Type B change projects are:
Organisation cultural change and IT development / implementation
Tunnelling projects
Type C Projects
Type C projects (refer Figure No.2. 7) are clear in HOW to achieve outcomes, but
unclear about WHAT are the desired outcomes.
Unclear
c
COMPLEX PROJECTS
HOW
Clear
1m
WHAT
Concept
Unclear
FIGURE No. 2.7
Clear
In Type C projects there are well developed skills and / or processes available to
implement projects. For example, a training capability in an organisation is an
example of a skill waiting for a place to be used.
398
The key phase in Type C projects is the concept phase. Once the project
objectives are defined, the WHAT is established, then Type C projects can follow
a life cycle similar to Type A projects - Type C projects resemble Type A
projects in the design and implementation phases. The management of the
concept phase requires a focus on innovation and flexibility, which is significantly
different to the bureaucratic processes of Type A projects. Type C projects can
be compared to Mintzberg's adhocracy in which an organisation has two quite
different organisational designs that are interconnected but interdependent
(Mintzberg, 1983).
The planning of Type C projects needs to be split into two stages:
1. The planning of the concept phase needs to be treated as a complex project
with allowance made for recursive and non-linear activities similar to those of
a Type D project. A process (Discovery Planning) to deal with uncertainty in
WHAT is detailed in Section 4 of this exegesis.
2. The planning of the design and implementation phases needs to be treated
similarly to Type A projects, with linear programming.
As with planning, procurement and stakeholder involvement are best split into
two stages: The concept phase as the first stage; and the design, implementation
and finalisation phases as a second stage. Stakeholder management and the
use of review milestones are key project management processes to manage the
complexity of the concept phase. The second stage is best treated as a Type A
project.
Typical Type C projects are:
HR staff are skilled in TOM training. What to do with them?
Multiskilling training is seen as the key to behavioural change. Where to use
it?
Hotel and Office building development - What to build?
Type 0 Projects
Type D projects (refer Figure No. 2.8) are the most complex of all projects. There
is a lack of clarity about WHAT the objectives are and HOW the objectives are to
be achieved. (The shading in of phases has been removed from Figure No. 2.8
to assist readability).
399
Unclear
COMPLEX PROJECTS
HOW
Clear
D
Clear
WHAT
Unclear
---I
FIGURE No. 2.8
Type D projects bring together the complexity of Type B and Type C projects.
There is a need for innovation and flexibility in the concept phase and high
recursiveness between the design and the implementation phases. Linear
programming based on holistic decision making has little use in complex
projects. A Pareto decision making process is required with learning and
environmental scanning loops built in to reflect the recursiveness of the process.
There are two strategies to deal with Type D projects.
Use the Discovery Planning process to transform Type D projects into Type B
projects through resolving What.
Adopt a systems approach to resolve What and How simultaneously using an
integrated team made up of the both functional design and operational
specialists. In this approach the integrated team looks at multiple approaches
simultaneously. As the integrated team learns more about the systemic
effects of the various alternatives, some are dropped, others postponed for
future generations, and others are refined and kept for further study.
In both strategy and product development, implementation is always the major
obstacle. To deal with implementation, a spiral learning process is used to
integrate concept and operational implementation, along with the use of pilot
projects. There is a lot of negotiation throughout the process between
alternatives' sponsors, and concept and operational specialists - there's a lot of
give and take. (Iansiti, 1993)
Procurement of complex projects is best achieved through management by
stakeholders.
400
Typical Type D change projects are:
R&D
Strategic decision making
Perceived poor group performance
Complex Programs
An important point needs to be made about complexity. In most cases lack of
clarity in both WHAT and HOW indicates that you are dealing with a program, not
a single project.
A complex program is usually made up of a mixture of Type A, B, C, & D
projects. It is good practice at the beginning of a program to analyse the projects
making up a program by Type. This analysis gives guidance on how to staff,
plan, manage and control the individual projects.
Project I Program Failure
There is no precise definition or milestone point that demarcates between project
failure or success. In this exegesis a project is deemed to fail when it does not
deliver the outcomes envisaged at its inception. In projects where at project
inception there is clarity of what the objectives are and how those objectives are
to be achieved, project failure will be defined in terms of the project's
achievement in delivering the prescribed outcomes on time, at the predetermined
quality and in accordance with the initial project schedule and milestones.
For complex projects where it is not possible to clearly define what the project
objectives are, and I or how those objects are to be implemented, project failure
is defined in terms of process management, rather than the achievement of
predetermined outcomes.
In complex projects there are two common causes of project / program failure:
1. Poor definition of WHAT
2. Expert / top team imposing HOW onto project stakeholders
1. A poor definition of WHAT the objectives are usually results from an
inadequate determination of client needs. Failure to appropriately classify a
project as Type C or D can result in project failure.
Hospital projects are good examples of Type C projects where the lack of
definition of WHAT can lead to project failure. The HOW is clear - the
construction techniques to build a hospital are well known. However, the WHAT
is unclear. Because of the rapid rate of change in medical technology, most
hospitals like to delay making decisions on technology choice until as late as
possible. This means that flexibility is required in the process of construction to
leave technically related design choices until as late as possible. This demand for
401
flexibility requires a totally different approach to the management of hospital
projects than on school projects where, by contrast, both the WHAT and HOW
are usually clear from the beginning of the project (CII, 1994; CII, 1995).
2. Complex projects can also fail because stakeholders have not been
involved in developing HOW the objectives are going to be achieved.
Stakeholders need to feel ownership of the process. In projects there are many
ways (HOW) to achieve an objective (WHAT). This ability to have multiple correct
solutions of HOW to achieve a specified WHAT is termed equifinality. It is more
important that the stakeholders in a project feel ownership of the HOW, than in
having an expert's optimal solution to HOW.
When Type A projects, which are the cheapest and fastest to complete, are
compared with the other Types of projects, there is a temptation to classify most
projects as a Type A - this incorrect classification of more complex projects as
Type A pushes the project towards failure from the beginning. In any project /
program it is critical to understand where a project / program sits in the WHOW
matrix:
so that appropriate emphasis can be placed on the key phases of the project
/ program life cycle
to assume that the appropriate control and planning processes are used and
that the project / procurement process suits the project
so that there is appropriate stakeholder involvement
A Contingency Approach To Planning
Planning is a process of establishing relationships among activities and then
putting time estimates on those activities. The relationship between activities may
vary from sequential to cyclic and recursive. Planning is not a 'one spanner fits
all' process as the type of planning needs to match the nature of the project.
Before looking at differences in planning between Type A, B, C, & 0 projects, an
understanding of the nature of the design process is required. As shown in
Figure No. 2.9, the design process is best viewed as a cyclic shaped funnel
(Rowe, 1994).
The design process goes vertically from concept to detail, that is from very broad
issues such as design philosophy in the concept phase, down to fine definition of
details in the design phase. In moving from concept to detailed design, the
design process follows a cyclic process, cycling between divergent abstract
ideas, then through convergent concrete realisation, back through abstract ideas,
and so on. The duration of the concept and design phases and the overlap with
the implementation phase varies with where a project sits on the WHOW matrix.
402
FUNNELLED / CYCLIC DESIGN / PLANNING PROCESS
Concept
......- ,.---.......
ABSTRACT
IDEAS
CONCRETE
IMPLEMENTATION
Detail
Milestone Review Points
FIGURE No. 2.9
The human mind's creative process is one where we build models in our brain by
assembling pieces of past understanding (Simon, 1987).
Parnes stated "It can connect and reconnect like a kaleidoscope forming pattern
after pattern" (Solomon, 1990). It is through connecting this divergent creative
process through milestones to the convergent operational focus that real
progress is achieved.
Milestone review points facilitate this divergent and convergent thinking process
- the first way of thinking allows the mind to make as many connections as it
can, and the second way allows the rational mind to review the ideas to see
what's practical. Milestone review points in the convergent / divergent learning
cycle are shown in Figure No. 2.9.
These milestone review points are crucial in managing the design process when
there are multiple parties involved in the design process. The individual
designers are re-benchmarked at each milestone review point, so that all the
designers then proceed to the next part of the design from the same position.
After the milestone point, the individual designers will again diverge, but will be
re-benchmarked again at the next milestone point.
The nature of the design / planning process also varies with where a project is
located on the WHOW matrix. Design / planning processes for each of the
generic project Types A, B, C, & D are shown in Figure Nos. 2.11, 2.12, 2.13,
403
2.14 and 2.15. In these five figures, the wider the funnel shape, the greater the
emphasis on concept, and the narrower the funnel, the greater the emphasis is
on detailed design / planning (refer Figure No. 2.10).
DESIGN EMPHASIS
C
.... -.,
./ ",:
"._-..........:::.,
y ..,../
I :,..- .......
' ~ ~ ..J
,
\ , ~ ?
,' ......
~ /
Broad funnel means the Narrow fnnnel means the
focus is on concept design focus is on detailed design
FIGURE No. 2.10
Pascale refers to convergence and divergence in the change process in a similar
way, In organisational design, individual units / functional groups will have a bias
towards convergence. Divergence on the other hand, is driven by having creative
tension between multiple groups (Pascale, 1990). If managed, Pascale proposes
it is this interplay that is the engine that drives innovation. This distinction in the
use of the terms convergence and divergence will be needed to understand
Section 5.
Planning of Type A projects
In projects that are clear in both WHAT and HOW detailed plans can be
developed at a single point in time using holistic decision making (refer Figure
No. 2.11).
Concept
A
Narrow
Funneled
Shape-
focus on
detailed
design then
bnplementation
404
Type A projects Jlrogress quickly fl"Om concept design to detailed
design where the majodty of decisions for implementation al'e
resolved and cool'dinated
FIGURE No. 2.11
Since all design is completed in the concept and design phases, planning for
Type A projects can be highly detailed, linear, and make limited allowances for
variance in activity durations or mistakes in coordination. The funnel shape is
narrow as there is little concept work required. The focus is on up front detailed
design.
Planning of Type B projects
In projects that are unclear in HOW there is recursiveness between the design
and implementation phases (refer Figure No. 2.12).
Concept
B
Detail
Multiple
Narrow
Funneled
Shape-
cycling between
detailed design
and
implementation
Type B projects fluctuate between concept and detailed design, as
the project jumps between implementation and design
FIGURE No. 2.12
Recursiveness means having multiple iterations through the design process, so
as with Type A projects, the funnel shape is relatively narrow. Once new
conditions are found in the implementation phase, the design process quickly
moves through concept to detailed design.
In planning Type B projects, sufficient time must be allowed for the multiple
iterations (learning loops) through the design and implementation processes.
Planning of Type C projects
In projects that are unclear in WHAT the focus is on the concept phase (refer
Figure No. 2.13). Once the objectives (WHAT) are defined, Type C projects are
similar to Type A projects in that most decisions regarding implementation can be
made during the design phase.
The step shape in the funnel reflects the initial heavy focus on concept design,
and then the change to detailed design, once the objectives are defined.
405
- __J
_____ r::.='-
0::::--::>
...
C Stepped Funneled
I
y
.; Shape -focus
.:{] changes from
i.\
Detail concept to detail
Type C projects spend a long time in the concept phase.
Once the concept design is completed, the design phase resembles
that Ofll type A
FIGURE No. 2.13
In planning Type C projects, sufficient time needs to be allowed for the concept
design to be clearly defined. One of the two main reasons why Type C projects
fail, is inappropriate or poorly defined objectives. Stakeholder involvement in the
planning process using Connective Planning can improve the reliability and
validity of objectives setting. (refer to Section 3 - 'Stakeholders' for details on
connective planning)
Planning of Type D projects
In projects that are unclear in both WHAT and HOW it is difficult to define many
of the questions, let alone make decisions on How to implement. In planning
Type D projects there are two strategic approaches to planning:
1. Treat them as a Type B project, but made up of multiple Type Band / or C
projects, rather than multiple Type A projects. Type D projects resemble
multiple level adhocracies.
Strategy
No.1
D
Multiple
Stepped
Funneled
Shape
Type D projects are constllntly recursive between concept lind
detail design. The bllSic design decisions lire pel"iodically reviewed
Figure No. 2.14
406
The concept phase being one project, and the implementation phase being made
up of multiple projects both longitudinally over time, and vertically within a single
time zone. Where possible the uncertainty in WHAT is resolved before
attempting to resolve HOW through using Discovery Planning to transform the
Type D project into a Type B project. In this strategic approach (refer figure No.
2.14) the design programming of Type D projects is best depicted as a
combination of Types B & C projects. The process starts with a heavy focus on
concept design, the funnel narrows to detailed design, but then steps back out
broadly to concept design and so on.
2. Integrate the resolution of both WHAT and HOW into a single process. This
requires that the project team has competencies in both creativity and
technology, and operational implementation. In this approach multiple options
are tested (refer Figure No. 2.15), with the more favourable options being
developed, until a final integrated solution is developed.
Concepl
Strategy
No 2.
D
Resolution of both What and How simultaneously.
Multiple solutions are tested before a final solution is selected.
FIGURE No. 2.15
Planning Programs and Very Large Projects
Managing large projects, programs or projects high in uncertainty is so complex
that it is impossible to comprehend all the actions that have to be undertaken to
successfully plan and execute the project. The project needs to be broken down
(split) into small pieces in order for human cognition to understand the
uncertainty of the individual parts and how the pieces relate to each other.
Human cognition is limited to dealing with a limited number of variables (four to
five) simultaneously (Simon, 1987). Through breaking projects down into smaller
pieces, humans are able to understand the overall picture and see how their
actions can impact the overall. This splitting of the large project into small
projects allows each of the pieces to be viewed as a project in its own right
(Reger et ai, 1994).
A similar process has been proposed in the planning and implementation of
change in organisations where:
407
pilot projects are proposed at the fringe of the organisation. At the fringe of
the organisation the dominant culture is less strong and there is a better
chance of change, and
the scale of change is broken down into manageable sized pieces
(Beer et ai, 1990, Pellegrinelli and Bowman, 1994, Reger et ai, 1994)
Wave Planning
One of the characteristics of Types Band D is the recursiveness that is inherent.
As shown in Figure No. 2.16, in Type A projects each of the project phases is
independent of each other.
Unclear
RECURSIVENESS OF PHASES
HOW
Clear
Clear
WHAT
Unclear
Concept
Design
a Implementation
..
o Finalisation
FIGURE No. 2.16
However, Types Band D have a significant overlap between the phases and
there is recursiveness between phases. Traditional project management planning
tools suited to Type A projects and to bureaucratic configurations cannot deal
with the recursive nature of Type B, C and D projects.
As shown in Figure No. 2.17, Wave Planning allows for recursiveness to be
incorporated into the planning process, while maintaining what appears to be a
linear relationship. The term Wave Planning is derived from the wave like pattern
that is made when the activities in Kaizen (Imai, 1986) of the Plan Do Check Act
408
(PDCA) cycle are plotted longitudinally onto the three axes of Gathering
Information, Design and Implementation. This is important if traditional project
managers are to feel comfortable with using the Wave planning tool.
WAVE PLAN
Gather
Information
Implementation
Activity
( Flow""h
FIGURE No. 2.17
Through having the three primary activities (Design, Gathering Information, and
Implementation) as horizontal zones, a recursiveness process can be planned
horizontally in what appears to be a linear process. As shown in Figure No. 2.18,
by introducing Milestones in Wave Planning, both recursiveness, and
convergence / divergence can be incorporated into a planning process.
MILESTONES IN WAVE PLANS
Implementation
Gather ------,__---t--"""7'"l__---__---__+_
Information
~
~ Milestone
FIGURE No. 2.18
Applying WAVE Planning to Projects
Type B projects provide good examples of Wave Planning. In Type B projects
there is relative certainty in What the objectives are, but uncertainty in How those
objectives can be implemented. As shown in Figure Nos. 2.19, 2.20, and 2.21,
uncertainty in How can be resolved in three ways. In Figure 2.19, the uncertainty
in How is reduced by going through the design spiral multiple times prior to
implementation. Connective planning is such as method - it brings stakeholders
together using a workshop and a card system to bring out deeper functional
issues, and then using the cards, integrates and aligns to develop an overall
409
project brief / objective (Verger and Kadalan, 1994). Once the uncertainty in How
is reduced, the project can be implemented using a Type A approach.
UNCERTAINTY IN HOW RESOLVED THROUGH GATHERING
INFORMATION
Time
Design
Gather
Information
Implementation
Project changes
(rom a type B project
to a Type A project
FIGURE No. 2.19
Another way of reducing uncertainty in How is to use pilot projects (refer Figure
No. 2.20) to resolve uncertainties as part of the design process. Feedback from
the pilot project (s) is used by the designers to remove uncertainty. Again, once
the uncertainty in How is removed, the project can be implemented as a Type A
project.
UNCERTAINTY IN HOW RESOLVED THROUGH GATHERING INFORMATION
AND PILOT PROJECTS
Time
Design
Gather
Information
Implementation
Project changes
from a (vpe B project
FIGURE No. 2.20
As shown in Figure No. 2.21, in some projects, even with the use of processes
such as connective planning and pilot projects, it is not possible to remove
uncertainty in How. In these projects, the project always remains complex and
never becomes a Type A project.
UNCERTAINTY IN HOW CANNOT BE RESOLVED THROUGH GATHERING
INFORMATION OR PILOT PROJECTS
410
Time
Design
Gather
Information
Implementation
FIGURE No. 2.21
Another example of Wave planning for Projam management was followed in the
Royal Australian Air Force (RAAF) / Qantas maintenance contract - a Type C
program. In this program Qantas maintain military aircraft for the RAAF.
When the program started a significant number of planes were unable to fly
because of a lack of spare parts. An initial partnering workshop was held which
established action plans to deal with the lack of spare parts and measurement
processes to track performance. A follow up workshop was then held three
months later, to review the outcomes of the initial action plans and the
performance measurement.
The result of this second workshop was that parts were no longer the main cause
of grounding aircraft. The problem was now a lack of engines. The lack of parts
had provided sufficient noise in the system to hide the fact that there was a lack
of spare engines.
Action plans were set up to deal with the lack of engines and performance
measurement processes modified to track what was now considered to be the
critical issues.
A third partnering workshop was held approximately six months after the second
workshop, the performance of the action plans was reviewed, and the
performance measurement results reviewed. The outcome was that it was not a
lack of engines, but a lack of key components in engines that was the main
problem causing aircraft to be grounded. Again action plans were established to
deal with the lack of key components and a revised performance measurement
process established.
As shown in Figure No 2.22, Wave planning for this program allowed Projam
planning of the overall program, and its projects, individually and collectively.
411
WAVE Planning TYPE W
WI-lOW
I,e 4,C 7,C
00
00
000000
clear I
DESIGN
*
*
2, J,
*
2
5,6,8,
9
GATIiEll [N] * [
0 0 00 00
3
* *
WHAT

' 1,4,
&7
INFORMATION 0 00
unclear 5
6, A 9,A
5 4 3 2 I
*
00
*
00 0 00

HOW
1i\IPLEMENT 2, A 5,A 8, A
Milestone

8B0
Type
WHAI HOW
No Activitv Description
clear :Iear unclem
I 2 J 4 5 I 2 J 4 5
I
P',r',,,',,,,,, Hi <,1" ('
2 At'l ion Plans (Parts)

A
-
.
3 M,o< '"r"m"'" A
.

(' .
5
A 'Iin" PI"" IF""i"",) A
6
'A,o< .
"""",
A
.

7
Partncring WorkshoD ('
.
8 Action Plan ICOll1noncnts) A .
9
Mcasurcmcnt A
.
FIGURE No. 2.22
The instructions to use the Wave Planning pro-forma are:
1, List activities numerically - 1,2, 3,,,,,,,,.n
2. Allocate each activity by Type - Design, Gather Information, Implement, or
Milestone.
3. Rate each activity in terms of its clarity of What and How using the scales
provided (1, 2, 3, 4, 5). Where 1 =clear and 5 =unclear
4. Plot the activities sequentially while sorting each activity for Design,
Gathering Information or Implementing. Where there is a milestone, ignore it
in the first run through. Put the activity number beside each point as it is
plotted.
5. Once all the activities have been plotted (Design, Gathering and
Implementation) using a line connect the activities sequentially.
6. Plot the milestone activities. Put the milestone activity number beside each
milestone point.
7. The line depicts the Wave Plan for the project. It links each of
the activities sequentially. The Wave Plan shows the recursiveness of the
process between Design, Gathering Information and Implementation, and
milestone points.
8. Plot each activity onto the WHOW matrix in the top right hand corner of the
page. Put the activity number beside each point.
9. Beside each activity description write in the WHOW Type each activity fell
into. Where an activity falls on the boarder between Types, allocate the
activity to the higher alphabetic letter that it borders with, ie. A goes to either
B or C, etc.
412
10. Write the activity WHOW Type beside each activity on the Wave plan.
11. Review the Wave pattern and the composition of activity Types A, B, C, 0 to
determine the overall project / program WHOW Type. Write the overall
project / program Type into the box on the top of the page:
if there is no recursiveness then it is Type A
if the process is recursive, but then settles into implementation
with Type A activities, then it is a Type C project
if there is ongoing recursiveness then it is a Type B, C or 0
program. In these cases refer to the rating (1-5) of activity What
and How. Look for clarity of What and or How. In the example
shown there is a reasonable clarity of HOW, but a poorer clarity of
WHAT. The Program therefore resembles more a Type C, than a
Type A program.
12. Having analysed the overall project / program, each of the individual activities
need to be checked. Heuristics for analysing activities are:
Type A activities are usually simple activities
Type B, C and 0 activities are usually programs made up of
multiple other activities
a Wave Plan should be developed for each Type B, C and 0
activity
The WHOW Matrix and Wave Planning are two Projam management tools for
programs and projects that are characterised by uncertainty, rather than stability.
413

Dombkins WHOW Model

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dombkins WHOW Model

Uploaded by

Copyright:

Available Formats

Section 2: WHOW Matrix and Wave Planning

2 At'l ion Plans (Parts)

You might also like