12

Applying the Staged Framework

Four types of project

In his book, All Change! The Project Leader’s Secret Handbook, Eddie Obeng describes four types of projects, each of which deals with a different kind of change. I have shown these in Figure 12.1.

Figure 12.1 Different types of change project

If you know what you are doing and how you are going to do it, you have a ‘painting by numbers’ project. If you know how but not what, you have a ‘movie’. A ‘quest’ is when you know what you want, but not how you will achieve it. Finally a ‘fog’ is when you don’t know what you want, nor how to achieve it.

Fitting into the staged framework

The staged framework requires that, by the time you reach the Development Gate, you know, with a reasonable level of confidence, what you are going to do and how you are going to do it. That is to say, at the Development Gate you will have a painting by numbers project (see Figure 12.2). The investigative stages are there to give you the time, resources and money to discover a solution to your problem. The Proposal will have settled why you need the project. However, your level of background knowledge will differ for each proposal you want to do. This will have a considerable impact on the way you undertake the investigative stages and the level of risk associated with the project at the start. Painting by numbers projects tend to be less risky than others, but not always. Figure 12.3 shows this in a different way: a ‘normal’ project (if there is such a thing!) can change from being a quest, movie, or fog to painting by numbers as it moves through the project life cycle. The clarity of your scope, timescale, costs and benefits will improve as you gain more knowledge. In addition, as we learned earlier (p. 52), the level of risk should decrease as you progress through the project.

Figure 12.2 Creating a project you can implement

The staged framework requires, by the time you reach the Development Gate, that you know what you are going to do and how. That is to say, at the Development Gate, you will have a painting by numbers project. You may, however, start off as any of the project types – the investigative stages are the means by which you create the final project.

Figure 12.3 Getting to paint by numbers

A ‘normal’ project can change from being a ‘quest’, ‘movie’ or ‘fog’ to ‘painting by numbers’ as it moves through the project life cycle. The clarity of your scope, timescale, costs and benefits will improve as you gain more knowledge.

However, just to make your day, there are circumstances when you would allow a project to continue past the Development Gate as a fog, movie or quest. The level of risk would be higher than under normal circumstances but that is your choice. The ‘game’ of projects has principles but few rules. Directors have to direct and managers have to manage; that is your role. If an action makes common sense, do it and do it openly.

Small stuff, or ‘simple’ projects

‘I understand stages and gates,’ you may say, ‘but isn’t it all a bit too much for smaller simple projects?’ Let us take the example of how what I would term a ‘simple’ project differs from the type of project normally associated with staged processes and how you can deal with them using the same management framework.

A normal project may start off as painting by numbers, a fog, a quest or a movie. The investigative stages are worked through until you are confident (say, around 90–95 per cent certain) that the required benefits can be achieved. At the Detailed Investigation Gate you will have narrowed your options down and have approval and funding to complete the Detailed Investigation Stage. At the Development Gate you would have approval to complete the project as a whole – it has become a painting by numbers project.

With a simple project, you usually know a great deal about it before you even start. By the time you finish the Initial Investigation Stage you may have fully defined the project outputs and plan and your confidence level will be as high as it is normally for a larger project at the Development Gate (Figure 12.4).

In these circumstances, the Detailed Investigation Stage may either be:

• reduced in scope and time to become very small;
• or dispensed with altogether.

In these circumstances, full authorisation to complete the project can be given at the Detailed Investigation Gate (see Figure 12.5). This doesn’t mean you can bypass the remaining gates, you still need to have reviews and checks to ensure on-going viability. So if you omit the Detailed Investigation Stage you must meet the full criteria of the Development Gate before you continue.

In this way, you have used the principles of the framework, checking at every gate but you have avoided doing any unnecessary work. Making the key control documents, Initial Business Case and Business Case identical enables this to happen without the need to duplicate any documentation. (See also p. 194 for a discussion of simple projects in relation to decision making.)

Figure 12.4 Simple project

A simple project can be defined very closely, in the Initial Investigation Stage.

Figure 12.5 The stages for a simple project

The top diagram represents a project where some detailed investigation work still needs to be done. Nevertheless, the level of confidence is high enough to authorise and fund the project to completion.
The lower diagram represents an even simpler case where no further investigative work needs to be done. The project is checked against the criteria for the Development Gate and, if acceptable, moves straight into the Develop and Test Stage.

Agile or rapid projects

Consider also the concept of ‘agile’, ‘rapid’ and ‘dynamic system development’ projects. These are particular development techniques or methods where a project is defined with a fixed budget and timescale but where the scope is varied to suit (see Figure 12.6). If the team runs out of time or money, the scope is reduced in order to meet the time/cost targets. Provided a predefined, minimum scope is delivered, the project will remain within its area of benefit viability. In many ways, it is like a ‘simple’ project except that the scope is variable within known limits. You are, therefore, able to assign resources to it with confidence, knowing when they will become available for other projects.

Agile techniques usually involve iterative requirements definition, design and delivery using either a prototype platform or the actual operational platform. Thus the Detailed Investigation Stage is often merged with the Develop and Test Stage. Having two stages running in parallel on closely knit work such as this can confuse people. The usual point made is ‘What stage do I book my time to on the time sheet?’ This can be dealt with by dispensing with the detailed investigation altogether and moving straight from the Initial Investigation Stage to the Develop and Test Stage (similar to Figure 12.5, lower diagram).

Figure 12.6 Rapid project

A project using rapid techniques has fixed timescale, cost and minimum benefits. The scope varies to suit these constraints.

‘Just do it’ projects – loose cannons

There are cases when senior management will issue an edict to finish a project by a certain time whatever the cost. In certain circumstances this is a valid thing to do, especially when the survival of the organisation requires it. Such projects must be treated with extreme caution as often they come about as an executive’s ‘pet project’ and may have little proven foundation in business strategy. I would argue that there are very few instances in companies where something needs to be done regardless of the costs and consequences. These projects invariably start off being optimistic and end up bouncing around the organisation with the demand that more and more resources are assigned to it without delay. Consequently, there can be considerable impact on day-to-day operations as well as significant delays to other projects, remembering delayed projects equate to delayed benefits. They also tend to be very stressful for those associated with them. The damage left in the wake of such projects can be awesome even if they appear to succeed!

Most organisations can cope with one of these kinds of projects – occasionally. Most organisations cope better if there aren’t any. However, if you believe one is needed it should still be aligned into the project framework as closely as possible and managed as an ‘exception’.

But before starting, consider the following questions:

• Why am I doing this?
• Is it really far more important than everything else?
• Am I really sure what I am doing?

There must be very compelling reasons to allow a loose cannon project to start. Responding to a problem by panicking is not usually a good enough reason! Using the issue breakthrough technique is a better starting point (see Chapter 24).

You must be absolutely clear what other activities and projects it can be allowed to disrupt. You can create more problems, for yourself and for others, than you will solve. You must consider the real ‘cost/benefit’ and take into consideration the inefficiencies and lost or delayed benefits from the disrupted projects. After all that, if you really must do it then:

1. Undertake an initial investigation first so you can make an informed decision;
2. Keep the project as short as possible (say, three months maximum). If you need longer, break the project up into smaller pieces.

Big stuff, or projects and subprojects

Defining the scope and boundaries of a project is often problematic. The term ‘project’, like its cousin ‘programme’, is often used so loosely that it has very little meaning. In some cases, what one person calls a project, another will call a programme. Similarly ‘subproject’ and ‘project’ can cause confusion. The relative structural relationship is identical:

Nine times out of ten it doesn’t really matter what you call things but, if you are to understand business projects fully, you need to be able to see the distinction. It may be that the way your project support systems are configured will determine the terminology for you.

If you are to have clarity of communication in your business, you must decide on the definitions which suit you best and stick to them (see p. 62).

• a finite piece of work (it has a beginning and an end) undertaken in stages;
• within defined cost and time constraints;
• directed at achieving a stated business benefit.

In other words, the key elements of benefit, scope, time and cost are all present. The only place where all this is recorded is in the Business Case, which serves as the key document for approving and authorising the project in initial form at the Detailed Investigation Gate and in full at the Development Gate. As a working assumption, therefore, we can say a project is only a project if it has a Business Case. Business Cases are attached to business projects!

It, therefore, follows that … any piece of work which is finite, and time and cost constrained, but does not realise business benefit, is not in fact a business project. It may be managed using project techniques or it may be a subproject or work package within a project. On its own, however, it has no direct value. Only when combined with other elements of work does it have any value. It is for this reason that you need to carefully consider how you handle what are often called ‘enabling projects’. Enabling projects are undertaken in order to create a capability or platform which later projects will use as part of the solution. Enabling projects do not create any value on their own. For this reason, enabling projects cannot be ‘standalone’ but must be considered as part of a wider programme, under a single programme-wide business case.

Work packages

In any project, the project manager delegates accountability for parts of the work to members of the core team. This is done by breaking the project into work packages, usually centred around deliverables. Each work package has a person accountable for it. This work package can be decomposed again and again until you reach activity or task level. This structure is called a ‘work breakdown structure’ (WBS) and is a fundamental control tool for a project.

The first level of breakdown is the project itself. The second level of breakdown comprises the life cycle stages (initial investigation, detailed investigation, etc.). Below this are the more detailed work packages.

The top diagram in Figure 12.7 shows this: the Develop and Test Stage comprises three work packages (XX, YY and ZZ). Of these, package YY is divided into three more (Y1, Y2 and Y3). The whole structure of the project flows logically from project to stage to work package. Each work package has its own defined time, cost, scope and person accountable. It will not have its own discrete benefit. All things being equal, this is the way you should structure your projects. It provides good control as no part of the project can proceed into the next stage without all preconditions being present.

Figure 12.7 Explaining work packages and subprojects

The top diagram shows a project divided into the five stages of the project framework. Each stage can then be divided into a number of work packages (e.g. C is divided into XX, YY and ZZ). In the bottom diagram the same project has been restructured to have YY managed as a subproject.

The bottom diagram in Figure 12.7 shows an alternative structure for exactly the same project. In this case, however, the project manager has chosen to treat work YY as a subproject. In other words, it has a single identifiable work package, which is itself divided into stages and then into the lower level work packages (Y1, Y2 and Y3). The remainder of the project is dealt with in the preferred way. There are risks in using this structure:

• You may have a timing misalignment between subproject YY and the rest of the project as there are two separate life cycle stage sets.
• It is a more complex structure for the same work scope.

Both these require greater coordination by the project manager.

From this we are able to define subprojects more exactly:

The conditions under which you would choose to set up subprojects depend on the degree of delegation you want to effect – it is akin to subcontracting the work. You also find this type of structure happens as a result of systems and process limitations or reporting requirements. It may be more convenient to represent and report a completely delegated piece of work as a subproject as it may relate to work which has been let externally, under a contract or internally. Many companies treat their internal software development in this way.

The extended project life cycle

Many projects are undertaken to not only create products, services or capabilities but also to operate the outcomes of the project. For example, a contractor may not only build a road, but also maintain it throughout its useful life. In such situations the traditional project life cycle, described in Chapter 3, is extended to cover the full operation of the service (sometimes this is referred to as a product life cycle). In such situations, the stages of the project may cover:

• Development stages a new capability is developed using a project as the delivery vehicle, taking into account the ‘whole life’ needs of the organisation, with respect to the use of the outputs, cost of creation and cost of operation. The last stage of the project (Release Stage) typically overlaps the early operation of the new capability, in order to facilitate knowledge transfer and to be able to react to any operational issues uncovered. In a contracting situation, this is often defined in the contract (for example in construction’s ‘Maintenance Period’).
• Operational stages the capability is used and minor upgrades are done as ‘business as usual’.
• Upgrade stages more significant upgrades are undertaken to extend the product life, often using a project as the delivery vehicle.
• Retirement or withdrawal stages the capability is withdrawn, retired or decommissioned when it is no longer needed. This is often complex and also requires a project approach.

Whilst the ‘extended’ or ‘product life cycle’ is being seen more frequently, particularly in government work, except in the simplest cases, it is taking the project concept too far to treat all the above as a ‘single project’. It is better to treat such situations as programmes and thereby provide a greater degree of flexibility in how they are directed, managed and structured. Figure 12.8 shows a typical extended project life cycle.

Figure 12.8 The extended project life cycle

The project framework in Chapter 3 can be extended to include the operational stages of the outputs; however, such situations are usually better treated as a programme.