Figure 3.1 Select the right projects to support your strategy

Selecting the right projects will help you achieve your objectives by realising benefits which support your strategy.
(Copyright © PA Consulting Group, London. Adapted with kind permission)

Figure 3.2 Managing the risk

The investigative stages are crucial and you should hold back any development work until your investigations show you know what you are doing and have proved that the risks are acceptable.

Stages

Stages are specific periods during which work on the project takes place. These are when information is collected and outputs created.

For each stage in the project, you should carry out the full range of work covering the entire scope of functional inputs required (Figure 3.3). These functions should not work on the project in isolation but in a continuous dialogue with each other, thus enabling the best overall solution to be developed. In this way your knowledge develops and increases on all fronts at a similar pace and solutions are designed, built and tested in an integrated way. No one area of work should advance ahead of the others. Your solution will not be what is merely optimal for one function alone but will be a pragmatic solution which is best for your organisation as a whole. This has the benefit of shortcutting the functional hierarchies, enabling the flat, lean structures we all seek to attain to work in practice as it forces people with different perspectives to work together, rather than apart. The business of the future, that is created and built using a cross-functional team, will find it much easier to run the all-encompassing cross-functional processes that business process re-engineers and the Theory of Constraints (see Chapter 21) tell us is the way forward. Further, you should limit the work undertaken in any stage to that which is needed at the next gate: there is little point in spending effort and money until you need to.

Figure 3.3 Address all aspects of the project in parallel

For each stage in the project, you should carry out the full range of work covering the entire scope of functional inputs required. In this way your knowledge develops and increases on all fronts at a similar pace and solutions are designed, built and tested in an integrated way.

Figure 3.4 A typical stage

A stage may be represented by the project control cycle together with the key control tools you need to manage it (these are described in Part Four).

During each stage it is essential for the project manager to continuously forecast and reforecast the benefits, resources and costs needed to complete the project. He/she should always keep the relevant functions informed and check on behalf of the sponsor that the project still makes sound business sense. This is illustrated by the ‘project control cycle’ in Figure 3.4.

Before you start work on any stage, you should always know what you are going to do next in order to increase your confidence and decrease risks; you should have a project plan for at least the next stage in detail and for the full project in summary.

‘An unwatched pot boils immediately.’

H F ELLIS

Gates

Gates are the decision points which precede every stage. Unless specific criteria have been met, as evidenced by certain approved deliverables, the subsequent stage should not be started (see also p. 18). Gates serve as points to:

• check that the project is still required and the risks are acceptable;
• confirm its priority relative to other projects;
• agree the plans for the remainder of the project;
• make a go/no go decision regarding continuing the project.

You should not regard gates as ‘end of term exams’, but rather the culmination of a period of continual assessment with the gates acting as formal review points.

Gate criteria are often repeated in consecutive gates to ensure that the same strands of the project are followed through as the project progresses. You should expect a greater level of confidence in the responses to the criteria, the further into the project you move.

At each gate you will need to answer three distinct questions (Figure 3.5):

• Is there a real need for this project and, in its own right, is it viable?
• What is its priority relative to other projects?
• Do you have the funding to continue the project?

It is convenient to think in terms of these questions because, in many organisations, discrete people or groups are needed to address each of them.

Figure 3.5 The three decisions required at each gate

The first question concerns the viability of the project assuming no other constraints. Does it fit your strategy? Does it make business sense? Are the risks acceptable? You will see later on that this question is addressed by the ‘project sponsor’.

The second question (priority) concerns the project in its context. It may be a very worthy project but how does it measure against all the other projects you want to do or are currently doing? Are there more worthwhile projects to address? Is it just ‘one more risk too far,’ bearing in mind what you are already committed to? This question is dealt with in Part Three where I will propose a basic method of managing such decisions.

The third question involves funding. Traditionally, businesses have discrete and very formal rules concerning the allocation of funds and which are generally managed by a finance function. So, you might have a viable project, it may be the best of those proposed BUT have you the working capital to finance it? This question is also dealt with in Part Three. If your finance function is less dominant, the funding question(s) come before the question of priority.

Gates – an end or a beginning?

Gates have traditionally been defined as end-points to the preceding stage. The logic is that the work in the stage culminates in a review (viz. end of stage assessment) where a check is done to ensure everything is complete before starting the next stage.

However, due to time pressures, it is often necessary to start the next stage before everything in the previous stage has been fully finalised. For example, in the typical framework in Figure 3.6, we see that it is sound sense to undertake a trial operation of our new output before all the process, training and communication work is completed. What is essential is that we have sufficient work done to enable us to start the next stage with confidence. We are, therefore, left with the difficulty of having a traditional ‘rule’ that common sense encourages us to break.

The solution to this dilemma is to treat gates as entry points to the next stage. In this way you can start the next stage (provided relevant criteria and checks have been done) as soon as you are ready, regardless of whether or not the full work scope of the previous stage has been completed.

In this way, stages can overlap, reducing timescales, without increasing the risk associated with the project.

This approach also opens another powerful characteristic of the staged framework. Gates are compulsory, stages are not. In other words, provided you have done the work needed to pass into a stage, how you arrived there is immaterial. This allows you to follow the strict principles of the staged approach even if a stage is omitted. In Chapter 12, I will introduce the concept of ‘simple’ projects and show how this principle enables them to be accommodated.

Figure 3.6 The project framework as a bar chart

The project framework is shown here in ‘bar chart format’ at the top, with the document deliverables for each stage shown below. These are described more fully in Chapters 5 to 11; see also the CD-ROM for more details on each document.

Figure 3.7 The project framework in diagrammatic form

The project framework is shown here in a format which clearly distinguishes between the gates and the stages. It also shows the activities and deliverables which relate to each stage.

How many stages should I have?

Consider the types of project you undertake in your organisation. Do they fit the generic stages described earlier? Are there some modifications you would like to make? Some organisations have only four stages, others six or more. Generally, the fewer the better, but they must be meaningful to you and fit every project you are likely to do. My experience is that three is too few and five will fit most purposes, so if in doubt try five. Of the five stages used in this book, it is the Trial Stage which is often either left out (see ‘Is a trial really needed’ later in this chapter) or merged in with the Develop and Test Stage. I prefer to have the trial as a distinct stage to differentiate it from testing. Testing is very much an internal, ‘private’ activity. A trial on the other hand is ‘public’ involving real users and customers. You are therefore open to poor press comment and to hostile reactions from employees. By making the trial a distinct stage you force people to focus on whether they really are ready. There have been enough high profile cases of beta test failures of software and of premium automobiles receiving very poor press due to a poor state of market readiness to act as a warning to us all.

How do I decide what work is done in the investigative stages?

The investigative stages exist in order to reduce risk (see Figure 3.2). Therefore everything you do should have that aim. If any proposed activity does not reduce risk, you should consider postponing it to a later stage.

What should I call the stages and gates?

The stage and gate names I have chosen and used throughout this book have evolved over a number of years and are based on my experience of working in several organisations on different business projects. What you choose to call them is up to you but that decision is not trivial. Words are emotive and hence can be both very powerful movers for change or inhibitors of change. In all organisations there are words which:

• mean something particular to everyone;
• mean different things to different people.

You can build on the former by exploiting them in your project framework, provided the meaning is compatible with what you wish to achieve when using the words.

You should avoid the latter and choose different words, even making up new words if the dictionary cannot help you. For example, working in one company I found the word ‘concept’ problematic, despite its being very well defined and in the dictionary. ‘Concept’ to some people was a high level statement of an idea (the meaning I wanted to convey), but to others it meant a detailed assessment of what has been decided should be done (this was not what I wanted). Rather than try to re-educate people in their everyday language, I found a word (proposal) which had no strong linkages to current use of language. There were similar problems with the word ‘implement’: it has so many preconceived meanings that it is better not to use it at all! If you look at the list of possible names, you will notice that certain words appear in more than one place: this is a sure sign that they might be misunderstood.

The same issues apply to the naming of the gates. For these, however, it is better to name each one according to the stage it precedes. This emphasises the ‘gate as an entry point’ concept. An alternative approach is to name the gate after the document which is used as the control on the gate. You will see I have mixed these. Again this is your choice, but make the same terminology apply across the whole organisation.

I do, however, strongly suggest you do not refer to the stages and gates by a number or letter. It will cause difficulties later (including significant cost) if you need to revise your framework. You will not believe the number of times a ‘Gate 0’ or ‘Stage 0’ has had to be added to the front of a framework! Using proper names is simpler, more obvious and will not box you in for the future.

Where do people go wrong?

In designing their frameworks, I have found people make mistakes in two key areas, the front end and the back end.

All too often, I see frameworks with minimal start-up activity, immediately followed by the Develop and Test Stage. They have in effect gone from ‘idea’ to ‘do it’ in one small step. In all but the simplest projects such a leap is naive and may account for why so many projects are ill-defined and doomed to failure. By all means make it easy to start the project off (i.e. pass through the Intial Investigation Gate), but do ensure there is rigour in the actual investigations themselves. A project comprises both investigation and execution.

At the back end, people often confuse Project Closure with Post-Implementation Review. The former looks at project efficiency and delivery, whilst the latter looks at benefits realisation and operational effectiveness. These two views cannot be combined as the measurement points are entirely separated by time. Also note that ‘Proposal’ and ‘Post-Implementation Review’ are not stages of the project. They are activities which happen before and after the project, respectively; that is why they are shown as a circle and not an arrow in Figures 3.6 and 3.7.

Is a trial really needed?

‘I have already tested this rigorously. Surely I don’t really need to trial it all as well? Won’t this just delay the benefits?’

This is a very valid question. The answer, as always, is ‘yes and no’. Assume you have a choice of strategy from:

• product leadership;
• operational efficiency;
• customer intimacy.

1. Under ‘product leadership’ you are developing and delivering innovative, new products and services; you must be sure they really work as intended. You are aiming to be first and best in your market.
2. Under ‘operational efficiency’ you deliver what others deliver but more efficiently and at lower cost.
3. Under ‘customer intimacy’ you provide an experience for your customers such that they want to do business with you.

Thus, if your strategy is to have any practical meaning you must be sure that anything you do does not compromise it. The choice of ‘to trial or not to trial’ comes down to risk. What is the likely impact on your business if this goes wrong? How confident are you that it won’t go wrong? With this in mind, you may choose to subject certain aspects to a trial more rigorously than others – balancing the speed to benefits realisation with the risks.

Always assume that you need a trial. Omit it only if you have proved to yourself and your stakeholders that it will not add any value to your project. Never skip the trial because you are in a hurry! If in doubt, try it out.