Dombkins WHOW Model

Section 2: WHOW Matrix and Wave Planning

389

The Varying Nature of ProjectsNot all projects are the same. For example, projects such as Research andDevelopment are very complex, while others such as office fitout are very simple.Therefore, it is critically important to understand the nature (underlying inherentcharacteristics) of a project before commencing on a project / program. Complexprojects are very different from simple projects in their nature and the way theyneed to be managed.

r------------------,Terminology

The following words will be lIsed interchangeably

CERTAIN .- ... CLEAR

UNCERTAIN .- ... UNCLEAR

Nature of Simple ProjectsSimple projects resemble the machine model of organisations - experts designthe systems and processes, and standardise the work process. In simpleprojects, as with bureaucracies, innovation and flexibility are not only notrequired, 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 followsequentially.

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 verylarge projects are simple in their nature, while some very small projects arecomplex in their nature.

Because the definition of what is to be achieved is clear, and how the objectivesare to be achieved is also clear, detailed decisions relating to all phases of theproject life cycle are able to be made in the concept and design /planningphases. Based on this fine grain planning, the overall process is able to bestandardised, planning is linear, and project management processes usedresemble the bureaucratic model of organisations.

Nature of Complex ProjectsAs discussed in Section One, chaos has similar characteristics to complexprojects - it is non-linear and recursive. The pattern in complex projects is more

Dombkins, D. (1997) PROJAM: The Management of ComplexProjects 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 arecloser 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 iscomplex.

Because either the definition of what the objectives are, and / or how theobjectives are to be achieved are either or both unclear, detailed planning overthe project life cycle is not possible. For complex projects the planning processesneed to build in flexibility and innovation through incorporating recursiveness andnon-linear learning circles.

Project Management SystemsBoth the management of simple and complex projects use standard tools andprocesses, but these standard tools and processes differ between simple andcomplex projects. A general rule for projects is that without the use of standardproject management tools and processes, all projects (simple and complex) headtowards chaos (Stringer, 1982a; Stringer, 1982b; Stringer, 1982c). Complexprojects need their own tools, processes, and configuration if they are to besuccessful.

The limitations of the tools and processes of traditional project management ishighlighted by its approach to risk management which is expanded upon inAppendix I. The following extract from PMBOK defines its approach to what itsees as risk.

"In the context of project management, project risk may be defined as the chanceof certain occurrences adversely affecting project objectives. It is the degree ofexposure to negative events, and their probable consequences..... Riskmanagement may therefore be defined as follows: Risk Management, in theproject context, is the art and science of identifying, analysing and responding torisk factors throughout the life of the project and in the best interest of itsobjectives." (PMBOK, 1987)

Figure No. 2.1 puts the traditional project management approach to risk intoperspective. Risk management only deals with issues where probability andscenario planning type approaches apply - risk management only deals with asub-set of the uncertainty continuum.

390Dombkins, D. (1997) PROJAM: The Management of Complex

Projects and Programs

RISK MANAGEMENT - A SUBSET OF UNCERTAINTYRiskManagement

Simple Projects

New Tools and Processes

Complex Projects

.....I----.....~I .....1-----------1...

LowUncertainty

FIGURE No. 2.1

HighUncertainty

UncertaintyThe level of uncertainty that organisations have to deal with is continuing toincrease. With this increase in uncertainty organisational configurations that wereestablished to operate in stable environments, can fail. This applies to bothbureaucracies and project management.

Many organisations with a bureacrtic driven strategy are failing to generatecompetitive performance. To deal with this lack of performance, many of theseorganisations have engaged in restructuring, downsizing, and outsourcing.Unfortunately the same mindset (focused on stability) has carried over into theirapproaches to managing change and outsourcing.

Traditional project management is well suited to projects where the project hasclarity in scope definition (they are fully designed and specified). Traditionalproject management tools such as the Work Breakdown Structure, Critical PathPlanning and Resource Leveling are based on the premise that a project's designcan be fully detailed before the project is implemented - this means that a fullydeveloped 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, traditionalproject management tools are of no use. As mentioned previously, IT, Change,and Defence undertakings have all provided multiple examples where reliance ontraditional 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 EmergentSchool (Mintzberg, 1990) proposes that it is not possible to design a strategy upfront, and that strategies emerge over time. Research into success inimplementation of strategy suggests the design school approach is not working.(Marx, 1991 and Pasmore, 1994). The emergent school in its pure form asdescribed by Mintzberg is deterministic and leaves little opportunity for managersto have any impact on determining their future.

Strategy is suffering from the same problem as project management. The reality



is that strategy exists in a highly uncertain environment where it is impossible toidentify all the questions up front, let alone resolve all these questions prior tostrategy implementation. Using existing project management and strategicplanning tools and processes this leads to Mintzberg's deterministic view oforganisations.

This exegesis, proposes voluntarism, rather than determinism - it proposes thatorganisations can influence their own destiny through using Projam managementto manage complexity.

The underlying assumption is that organisations, projects, and programs need tofit with the level of uncertainty in which they exist. A new definition for uncertaintyis needed for Projam management that expands the scope of uncertainty beyondrisk 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, maynot be uncertain to another individual/organisation.

The first two of these dimensions of uncertainty (What and How) are broughttogether in the WHOW Matrix as shown in Figure No. 2.2. This matrix reversesthe usual arrangement of low and high uncertainty to provide a linear flow patternfor traditional project management's four life cycle phases. The third dimension,maturity, is dealt with in Section Three.

LowUncertainty

WHAT

• Concept ~ IlIlpleownt"tion

~ Design 0 Fin"lis"tion

High ~ ~Uncertainty 1-- --'"'- ---'

High HOWUncertainty

LowUncertainty

GURE No. 2.2FI



The WHOW MATRIXThe WHOW Matrix is a key tool in understanding, planning and implementingorganisational change. The project management literature has developed toolsfor simple projects (Type A), but has failed to provide a framework within which toview complex projects and has failed to develop tools to manage highuncertainty. The WHOW Matrix provides a contingency framework for projectsand programs.

The WHOW Matrix is broken into four Types - (Type A, Type B, Type C, andType D). Each of the Types is described as a pure Type that varies in respect ofthe uncertainty of WHAT and HOW.

WHAT- refers to the degree of uncertainty about the objectives of the project. Inorganisational change projects Mission and Vision are examples of WHAT. Thestrategic intent is the desired outcome of the change project.

HOW - refers to the degree of uncertainty about how to achieve the projectobjectives. In organisational change projects, implementation of strategy is anexample of HOW.

Most projects are not of a pure Type, but show stronger similarities to one of thepure Types, than to the other Types. Equally, a project can combine acombination of Types as it progresses, while other projects remain within a singleType classification.

In organisations, the Mission and Vision define WHAT the objectives are, and theimplementation process defines HOW the Mission and Vision are going to beachieved.

Positioning Projects on WHOWDepending on the degree of uncertainty of WHAT and HOW, a project cancommence at any point on the WHOW Matrix and can follow a linear or arecursive behaviour, or a mixture of both.



CLEAR WHAT, UNCLEAR HOW FLOW PROCESS:LowUncertainty

WHAT

HighUncertainty

HighUncertainty

HOW LowUncertainty

• 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 relativecertainty in What the objectives were, but a lack of certainty in How thoseobjectives were to be implemented. In this project a two stage pilot process wasused, with redesign after each pilot, to resolve How before the overallimplementation was attempted. This project shows a linear progression along thelife cycle phases, but has recursive loops between design and implementation. Atunneling project has a similar pathway - as new conditions are discoveredduring 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 mostimportant, 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 uncertaintyaffects 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 Aprojects.The Sydney Harbour tunnel project was a complex project. There was clarityin WHAT the objectives were, but high levels of uncertainty in HOW it was tobe achieved. The Sydney Harbour Tunnel project falls in Type B on theWHOW matrix.Techniques to design and build office buildings are well developed. Mostmajor construction companies can complete a thirty-storey office buildingfaster than the time it takes to construct an architect designed house. In officebuilding projects there is relative certainty about HOW the objectives are tobe achieved. On the other hand WHAT type of office building should be built


is the more difficult issue to be resolved. Office building projects aremoderately complex and fall in Type C of the WHOW matrix.

• Another good example of a Type C project is a feature film. The techniquesfor making a film are well known, however, WHAT film to make is the keyquestion to be resolved.

• Very few construction projects are highly complex as in most cases either theWHAT or the HOW are relatively clear. The best example of highly complexprojects are Research and Development Projects. In R&D projects there isoften little clarity in either WHAT the objectives are or HOW those objectivesare to be achieved. R&D projects are highly complex and fall in Type D of theWHOW matrix.

A review of eight major programs using the WHOW Matrix, with each of theprograms broken down into its sub-projects is shown in Figure No. 2.4

Analysis of Programs

Unclear HOW ClearClear

WHAT

Unclear

l~3 b1b 4a

5~f8g1e8e 1r3 a 343 e 3 e 8e7a

1d 2 b 7e4b2 1 8h 11f8a 2~d !fb2e 1a8b6

5b 7

I. Organisational Change Program ina multinational organisation

In Corporate imageJ b HRM developmentIe Media guidelinesId Corporate business strategyIe Best tender practiceIf Marketing development plan19 Media publication review

2. Raillnfraslruclure -- $500012a Tunnel illld track project2b Stations2c Interfnce to rail network2d Contract negotiation

1 Hospital redevelopmentprogram -- $2501113n Acute care services building3b Childrcns hospital3c WOOlens hospital3d Services centre3e Infrastructure

4. Tallroad $500m4a Bridge, road & tunnel4b Toll collection system

5. Office Building~ $20rn5a Office building project5b Office fitout

6. Airport Terminal extension - $160m

7. CSD Office Development - $500m7a Car park7b Podium7c Hotel7d Apartments I holel

8. Urban Redevelopmenl-$2XOmXa Concept development projectXb Stakeholder partnering process8c Marine works8d Roadworks8e DemolitionSf Parks and communal facilities8g Residential Buildings811 InfrastrUC\llre

FIGURE No. 2.4

These four Types of projects are discussed below:



Type A ProjectsType A projects are clear in both WHAT the objectives are and HOW thoseobjectives are to be achieved. Project homes fall clearly as Type A projects onthe 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 becauseWHAT is clear. In the design / planning phase, since the WHAT is clear, theemphasis is placed on resolving predictable issues before implementation beginsand on coordinating the implementation process through standardisation anddetailed planning. Type A projects have little recursiveness or non-linearity in theconcept and design / planning phases. The concept and design skills are notfocused on innovation, but rather on detailed design and coordination. Becausedesign can predict the implementation process relatively accurately, the designprocess can operate independently of the implementation process.

Type A projects use Holistic planning - when both WHAT and HOW are clear, itis feasible to resolve most decisions during the concept and design /planningphases. Planning is, therefore, highly detailed and prescriptive - tools such ascritical path analysis, work breakdown structures, and risk analysis are wellsuited to simple projects (refer section 3).

Because highly detailed specifications and planning can be completed in theconcept and design phases, Type A projects can be easily put to competitivetender for firm lump sum bids. Tenderers are able to prepare competitive bidsbased on a clearly specified design. Stakeholder involvement is limited as mostdecisions regarding planning / design are made prior to the implementationphase.



Typical Type A projects are:

• a technical skills audit of a department• project housing• most construction projects

Type 8 ProjectsType B projects (refer Figure No. 2.6) are clear in WHAT the project objectivesare.

Unclear

B

COMPLEX PROJECTS

HOWClear

Imple

WHATConcept

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 theobjectives are going to be achieved.

Tunnelling projects provide good examples of this. As tunnelling progresses,differing ground conditions will be encountered that require different designsolutions - this creates an ongoing recursiveness between design andimplementation. The Pareto model of decision making (refer section 3) is used onprojects where there is uncertainty in WHAT or HOW or both - decisions aremade progressively over time.

In Type B projects the design emphasis is on responsiveness, innovation andflexibility. There is an ongoing cyclic process between innovative and detaileddesign, and between design and implementation changes, as it is not possible topredict the overall implementation process. The recursiveness dictates a highlevel 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 designphases on Type B projects, it is not possible to prepare highly detailedprescriptive plans. The high recursiveness between design and implementationneeds to be planned differently to Type A projects. Research has shown that theplanning of complex projects consumes twice as much resources as thatrequired for Type A projects, and that allowance for variances needs toquadruple 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 callcompetitive tenders based on a clearly specified design. Type B projects arebetter tendered using a performance based contract where the WHAT is used asthe specified outcome and the HOW is left to the tenderer to design andimplement. Stakeholder involvement (Management by Stakeholder) becomescritical because of the recursiveness between design / planning andimplementation.

Typical Type B change projects are:

• Organisation cultural change and IT development / implementation• Tunnelling projects

Type C ProjectsType C projects (refer Figure No.2. 7) are clear in HOW to achieve outcomes, butunclear about WHAT are the desired outcomes.

Unclear

c

COMPLEX PROJECTS

HOWClear

1m

WHAT

Concept

Unclear

FIGURE No. 2.7

Clear

In Type C projects there are well developed skills and / or processes available toimplement projects. For example, a training capability in an organisation is anexample of a skill waiting for a place to be used.



The key phase in Type C projects is the concept phase. Once the projectobjectives are defined, the WHAT is established, then Type C projects can followa life cycle similar to Type A projects - Type C projects resemble Type Aprojects in the design and implementation phases. The management of theconcept phase requires a focus on innovation and flexibility, which is significantlydifferent to the bureaucratic processes of Type A projects. Type C projects canbe compared to Mintzberg's adhocracy in which an organisation has two quitedifferent 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 projectwith allowance made for recursive and non-linear activities similar to those ofa Type D project. A process (Discovery Planning) to deal with uncertainty inWHAT is detailed in Section 4 of this exegesis.

2. The planning of the design and implementation phases needs to be treatedsimilarly to Type A projects, with linear programming.

As with planning, procurement and stakeholder involvement are best split intotwo stages: The concept phase as the first stage; and the design, implementationand finalisation phases as a second stage. Stakeholder management and theuse of review milestones are key project management processes to manage thecomplexity of the concept phase. The second stage is best treated as a Type Aproject.

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 ProjectsType D projects (refer Figure No. 2.8) are the most complex of all projects. Thereis a lack of clarity about WHAT the objectives are and HOW the objectives are tobe achieved. (The shading in of phases has been removed from Figure No. 2.8to assist readability).



Unclear

COMPLEX PROJECTS

HOW Clear

D

Clear

WHAT

Unclear t.-_':::::=:::::"~ ---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 highrecursiveness between the design and the implementation phases. Linearprogramming based on holistic decision making has little use in complexprojects. A Pareto decision making process is required with learning andenvironmental 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 Bprojects through resolving What.

• Adopt a systems approach to resolve What and How simultaneously using anintegrated team made up of the both functional design and operationalspecialists. In this approach the integrated team looks at multiple approachessimultaneously. As the integrated team learns more about the systemiceffects of the various alternatives, some are dropped, others postponed forfuture generations, and others are refined and kept for further study.

In both strategy and product development, implementation is always the majorobstacle. To deal with implementation, a spiral learning process is used tointegrate concept and operational implementation, along with the use of pilotprojects. There is a lot of negotiation throughout the process betweenalternatives' sponsors, and concept and operational specialists - there's a lot ofgive and take. (Iansiti, 1993)

Procurement of complex projects is best achieved through management bystakeholders.



Typical Type D change projects are:

• R&D• Strategic decision making• Perceived poor group performance

Complex ProgramsAn important point needs to be made about complexity. In most cases lack ofclarity in both WHAT and HOW indicates that you are dealing with a program, nota single project.

A complex program is usually made up of a mixture of Type A, B, C, & Dprojects. It is good practice at the beginning of a program to analyse the projectsmaking up a program by Type. This analysis gives guidance on how to staff,plan, manage and control the individual projects.

Project I Program FailureThere is no precise definition or milestone point that demarcates between projectfailure or success. In this exegesis a project is deemed to fail when it does notdeliver the outcomes envisaged at its inception. In projects where at projectinception there is clarity of what the objectives are and how those objectives areto be achieved, project failure will be defined in terms of the project'sachievement in delivering the prescribed outcomes on time, at the predeterminedquality and in accordance with the initial project schedule and milestones.

For complex projects where it is not possible to clearly define what the projectobjectives are, and I or how those objects are to be implemented, project failureis defined in terms of process management, rather than the achievement ofpredetermined outcomes.

In complex projects there are two common causes of project / program failure:

1. Poor definition of WHAT2. Expert / top team imposing HOW onto project stakeholders

1. A poor definition of WHAT the objectives are usually results from aninadequate determination of client needs. Failure to appropriately classify aproject as Type C or D can result in project failure.

Hospital projects are good examples of Type C projects where the lack ofdefinition of WHAT can lead to project failure. The HOW is clear - theconstruction techniques to build a hospital are well known. However, the WHATis unclear. Because of the rapid rate of change in medical technology, mosthospitals like to delay making decisions on technology choice until as late aspossible. This means that flexibility is required in the process of construction toleave technically related design choices until as late as possible. This demand for



flexibility requires a totally different approach to the management of hospitalprojects than on school projects where, by contrast, both the WHAT and HOWare usually clear from the beginning of the project (CII, 1994; CII, 1995).

2. Complex projects can also fail because stakeholders have not beeninvolved in developing HOW the objectives are going to be achieved.Stakeholders need to feel ownership of the process. In projects there are manyways (HOW) to achieve an objective (WHAT). This ability to have multiple correctsolutions of HOW to achieve a specified WHAT is termed equifinality. It is moreimportant that the stakeholders in a project feel ownership of the HOW, than inhaving an expert's optimal solution to HOW.

When Type A projects, which are the cheapest and fastest to complete, arecompared with the other Types of projects, there is a temptation to classify mostprojects as a Type A - this incorrect classification of more complex projects asType 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 WHOWmatrix:

• 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 andthat the project / procurement process suits the project

• so that there is appropriate stakeholder involvement

A Contingency Approach To PlanningPlanning is a process of establishing relationships among activities and thenputting time estimates on those activities. The relationship between activities mayvary from sequential to cyclic and recursive. Planning is not a 'one spanner fitsall' 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, anunderstanding of the nature of the design process is required. As shown inFigure 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 broadissues such as design philosophy in the concept phase, down to fine definition ofdetails in the design phase. In moving from concept to detailed design, thedesign process follows a cyclic process, cycling between divergent abstractideas, then through convergent concrete realisation, back through abstract ideas,and so on. The duration of the concept and design phases and the overlap withthe implementation phase varies with where a project sits on the WHOW matrix.



FUNNELLED / CYCLIC DESIGN / PLANNING PROCESSConcept......- ,.---.......

ABSTRACTIDEAS

CONCRETEIMPLEMENTATION

Detail

• Milestone Review Points

FIGURE No. 2.9

The human mind's creative process is one where we build models in our brain byassembling pieces of past understanding (Simon, 1987).

Parnes stated "It can connect and reconnect like a kaleidoscope forming patternafter pattern" (Solomon, 1990). It is through connecting this divergent creativeprocess through milestones to the convergent operational focus that realprogress 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 itcan, and the second way allows the rational mind to review the ideas to seewhat's practical. Milestone review points in the convergent / divergent learningcycle are shown in Figure No. 2.9.

These milestone review points are crucial in managing the design process whenthere are multiple parties involved in the design process. The individualdesigners are re-benchmarked at each milestone review point, so that all thedesigners 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 bere-benchmarked again at the next milestone point.

The nature of the design / planning process also varies with where a project islocated on the WHOW matrix. Design / planning processes for each of thegeneric project Types A, B, C, & D are shown in Figure Nos. 2.11, 2.12, 2.13,



2.14 and 2.15. In these five figures, the wider the funnel shape, the greater theemphasis on concept, and the narrower the funnel, the greater the emphasis ison detailed design / planning (refer Figure No. 2.10).

DESIGN EMPHASIS

C·....-.,./ ",:

"._-..........:::.,y ..,../

I :,..- .......

'~~ ..J,\,~?,' ......~/

Broad funnel means the Narrow fnnnel means thefocus 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 similarway, In organisational design, individual units / functional groups will have a biastowards convergence. Divergence on the other hand, is driven by having creativetension between multiple groups (Pascale, 1990). If managed, Pascale proposesit is this interplay that is the engine that drives innovation. This distinction in theuse of the terms convergence and divergence will be needed to understandSection 5.

Planning of Type A projectsIn projects that are clear in both WHAT and HOW detailed plans can bedeveloped at a single point in time using holistic decision making (refer FigureNo. 2.11).

Concept

ANarrowFunneledShape-focus ondetaileddesign thenbnplementation

404

Type A projects Jlrogress quickly fl"Om concept design to detaileddesign where the majodty of decisions for implementation al'eresolved and cool'dinated

FIGURE No. 2.11

Since all design is completed in the concept and design phases, planning forType A projects can be highly detailed, linear, and make limited allowances for


variance in activity durations or mistakes in coordination. The funnel shape isnarrow as there is little concept work required. The focus is on up front detaileddesign.

Planning of Type B projectsIn projects that are unclear in HOW there is recursiveness between the designand implementation phases (refer Figure No. 2.12).

Concept

BDetail

MultipleNarrowFunneledShapecycling betweendetailed designandimplementation

Type B projects fluctuate between concept and detailed design, asthe project jumps between implementation and design

FIGURE No. 2.12

Recursiveness means having multiple iterations through the design process, soas with Type A projects, the funnel shape is relatively narrow. Once newconditions are found in the implementation phase, the design process quicklymoves through concept to detailed design.

In planning Type B projects, sufficient time must be allowed for the multipleiterations (learning loops) through the design and implementation processes.

Planning of Type C projectsIn projects that are unclear in WHAT the focus is on the concept phase (referFigure No. 2.13). Once the objectives (WHAT) are defined, Type C projects aresimilar to Type A projects in that most decisions regarding implementation can bemade 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.



~~:~~o.::-:e£~ ---~-~~__J_____ r::.='-~

0::::--::>~ ... _~-

C \~-fl Stepped FunneledIy.; Shape -focus.:{] changes fromi.\

Detail concept to detail

Type C projects spend a long time in the concept phase.

Once the concept design is completed, the design phase resemblesthat Ofll type A

FIGURE No. 2.13

In planning Type C projects, sufficient time needs to be allowed for the conceptdesign to be clearly defined. One of the two main reasons why Type C projectsfail, is inappropriate or poorly defined objectives. Stakeholder involvement in theplanning process using Connective Planning can improve the reliability andvalidity of objectives setting. (refer to Section 3 - 'Stakeholders' for details onconnective planning)

Planning of Type D projectsIn projects that are unclear in both WHAT and HOW it is difficult to define manyof the questions, let alone make decisions on How to implement. In planningType 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 Cprojects, rather than multiple Type A projects. Type D projects resemblemultiple level adhocracies.

StrategyNo.1

DMultipleSteppedFunneledShape

Type D projects are constllntly recursive between concept linddetail design. The bllSic design decisions lire pel"iodically reviewed

Figure No. 2.14



The concept phase being one project, and the implementation phase being madeup of multiple projects both longitudinally over time, and vertically within a singletime zone. Where possible the uncertainty in WHAT is resolved beforeattempting to resolve HOW through using Discovery Planning to transform theType 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 acombination of Types B & C projects. The process starts with a heavy focus onconcept design, the funnel narrows to detailed design, but then steps back outbroadly to concept design and so on.

2. Integrate the resolution of both WHAT and HOW into a single process. Thisrequires that the project team has competencies in both creativity andtechnology, and operational implementation. In this approach multiple optionsare tested (refer Figure No. 2.15), with the more favourable options beingdeveloped, until a final integrated solution is developed.

Concepl

StrategyNo 2.

DResolution 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 ProjectsManaging large projects, programs or projects high in uncertainty is so complexthat it is impossible to comprehend all the actions that have to be undertaken tosuccessfully plan and execute the project. The project needs to be broken down(split) into small pieces in order for human cognition to understand theuncertainty 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 tofive) simultaneously (Simon, 1987). Through breaking projects down into smallerpieces, humans are able to understand the overall picture and see how theiractions can impact the overall. This splitting of the large project into smallprojects 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 ofchange 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 betterchance 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 PlanningOne 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 isindependent of each other.

Unclear

RECURSIVENESS OF PHASES

HOW ClearClear

WHAT

Unclear

• Concept

Design

a Implementation..o Finalisation

FIGURE No. 2.16

However, Types Band D have a significant overlap between the phases andthere is recursiveness between phases. Traditional project management planningtools suited to Type A projects and to bureaucratic configurations cannot dealwith the recursive nature of Type B, C and D projects.

As shown in Figure No. 2.17, Wave Planning allows for recursiveness to beincorporated into the planning process, while maintaining what appears to be alinear relationship. The term Wave Planning is derived from the wave like patternthat is made when the activities in Kaizen (Imai, 1986) of the Plan Do Check Act



(PDCA) cycle are plotted longitudinally onto the three axes of GatheringInformation, Design and Implementation. This is important if traditional projectmanagers are to feel comfortable with using the Wave planning tool.

WAVE PLAN

GatherInformation

Implementation

• Activity( Flow""h

FIGURE No. 2.17

Through having the three primary activities (Design, Gathering Information, andImplementation) as horizontal zones, a recursiveness process can be plannedhorizontally in what appears to be a linear process. As shown in Figure No. 2.18,by introducing Milestones in Wave Planning, both recursiveness, andconvergence / 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 ProjectsType B projects provide good examples of Wave Planning. In Type B projectsthere is relative certainty in What the objectives are, but uncertainty in How thoseobjectives 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 uncertaintyin How is reduced by going through the design spiral multiple times prior toimplementation. Connective planning is such as method - it brings stakeholderstogether using a workshop and a card system to bring out deeper functionalissues, and then using the cards, integrates and aligns to develop an overall



project brief / objective (Verger and Kadalan, 1994). Once the uncertainty in Howis reduced, the project can be implemented using a Type A approach.

UNCERTAINTY IN HOW RESOLVED THROUGH GATHERINGINFORMATION

Time

Design

GatherInformation

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 FigureNo. 2.20) to resolve uncertainties as part of the design process. Feedback fromthe pilot project (s) is used by the designers to remove uncertainty. Again, oncethe uncertainty in How is removed, the project can be implemented as a Type Aproject.

UNCERTAINTY IN HOW RESOLVED THROUGH GATHERING INFORMATIONAND PILOT PROJECTS

Time

Design

GatherInformation

Implementation

Project changesfrom a (vpe B project

FIGURE No. 2.20

As shown in Figure No. 2.21, in some projects, even with the use of processessuch as connective planning and pilot projects, it is not possible to removeuncertainty in How. In these projects, the project always remains complex andnever becomes a Type A project.

UNCERTAINTY IN HOW CANNOT BE RESOLVED THROUGH GATHERINGINFORMATION OR PILOT PROJECTS



Time

Design

GatherInformation

Implementation

FIGURE No. 2.21

Another example of Wave planning for Projam management was followed in theRoyal Australian Air Force (RAAF) / Qantas maintenance contract - a Type Cprogram. In this program Qantas maintain military aircraft for the RAAF.

When the program started a significant number of planes were unable to flybecause of a lack of spare parts. An initial partnering workshop was held whichestablished action plans to deal with the lack of spare parts and measurementprocesses to track performance. A follow up workshop was then held threemonths later, to review the outcomes of the initial action plans and theperformance measurement.

The result of this second workshop was that parts were no longer the main causeof grounding aircraft. The problem was now a lack of engines. The lack of partshad provided sufficient noise in the system to hide the fact that there was a lackof spare engines.

Action plans were set up to deal with the lack of engines and performancemeasurement processes modified to track what was now considered to be thecritical issues.

A third partnering workshop was held approximately six months after the secondworkshop, the performance of the action plans was reviewed, and theperformance measurement results reviewed. The outcome was that it was not alack of engines, but a lack of key components in engines that was the mainproblem causing aircraft to be grounded. Again action plans were established todeal with the lack of key components and a revised performance measurementprocess established.

As shown in Figure No 2.22, Wave planning for this program allowed Projamplanning of the overall program, and its projects, individually and collectively.



WAVE Planning TYPE WWI-lOW

I,e 4,C 7,C

• 00 • 00 • 000000 clear I

DESIGN * *·2, J,

* 2 5,6,8,9

GATIiEll [N] * [ 0 0 0 0 003

* *WHAT~4 ' 1,4,

&7

INFORMATION 0 ~00 unclear 56, A 9,A5 4 3 2 I

* 00 * 00 0 00 ~ ~HOW

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

• Milestone ~8B0Type • WHAI HOW

No Activitv Description clear t1nCle~lr £: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 .4~r;"" (' .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,,,,,,,,.n2. 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 =unclear4. Plot the activities sequentially while sorting each activity for Design,

Gathering Information or Implementing. Where there is a milestone, ignore itin the first run through. Put the activity number beside each point as it isplotted.

5. Once all the activities have been plotted (Design, Gathering andImplementation) using a line connect the activities sequentially.

6. Plot the milestone activities. Put the milestone activity number beside eachmilestone point.

7. The line depicts the Wave Plan for the project. It links each ofthe activities sequentially. The Wave Plan shows the recursiveness of the

process between Design, Gathering Information and Implementation, andmilestone points.

8. Plot each activity onto the WHOW matrix in the top right hand corner of thepage. Put the activity number beside each point.

9. Beside each activity description write in the WHOW Type each activity fellinto. Where an activity falls on the boarder between Types, allocate theactivity to the higher alphabetic letter that it borders with, ie. A goes to eitherB or C, etc.



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 overallproject / program Type into the box on the top of the page:

if there is no recursiveness then it is Type Aif the process is recursive, but then settles into implementationwith Type A activities, then it is a Type C projectif there is ongoing recursiveness then it is a Type B, C or 0program. In these cases refer to the rating (1-5) of activity Whatand How. Look for clarity of What and or How. In the exampleshown there is a reasonable clarity of HOW, but a poorer clarity ofWHAT. The Program therefore resembles more a Type C, than aType A program.

12. Having analysed the overall project / program, each of the individual activitiesneed to be checked. Heuristics for analysing activities are:

Type A activities are usually simple activitiesType B, C and 0 activities are usually programs made up ofmultiple other activitiesa Wave Plan should be developed for each Type B, C and 0activity

The WHOW Matrix and Wave Planning are two Projam management tools forprograms and projects that are characterised by uncertainty, rather than stability.



Dombkins WHOW Model

Documents

Transcript of Dombkins WHOW Model