Fitting into the staged framework
Small stuff, or ‘simple’ projects
‘Just do it’ projects – loose cannons
Big stuff, or projects and subprojects
The extended project life cycle
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, how you are going to do it and who is accountable for seeing it is done.
‘Through the unknown remembered gate.’
T S ELIOT
The previous chapters have taken you through a project management framework you can use for each of your projects. This framework leads the project sponsor and project manager on a course which, if followed, will ensure that quality and purpose are built into your projects from the start and developed as you proceed to your end-point. It also ensures all projects undertaken in your organisation can be referenced to the same, defined and known set of stages. How can this simple set of stages be applied to the different types of projects you have to do?
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.
Traditional projects tend to be of this kind. These projects have clear goals and a clearly defined set of activities to be carried out. You know what you want to achieve and how you will achieve it.
This project is often formally called a closed project.
You are clear on what is to be done but clueless as to the means (how) to achieve it. It is named after the famous quest for the Holy Grail. The secret of this type of project is get your ‘knights’ fired up to seek for solutions in different places at the same time and ensure that they all return to report progress and share their findings on a fixed date. You can then continue to send them out, again and again, until you have sufficient information on how you can achieve your objectives.
Quests are invaluable as they give ‘permission’ for your people to explore ‘out of the box’ possibilities. However, they are notorious for overspending, being very late, or simply delivering nothing of benefit. You must keep very strict control over costs and timescales while allowing the scope free range.
This project is formally called a semi-closed project.
In this type of project you are very sure of how you will do something but have no idea what to do. Typically your organisation has built up significant expertise and capability and you are looking for ways to apply it. There must be several people committed to the methods you will use.
This project is formally called a semi-open project.
This type of project is one where you have no idea what to do nor how to do it. It is often prompted as a reaction to a change in circumstances (e.g. political, competitive, social), although it can be set off proactively. You know you have to change and do something different; you simply can’t stay still. You also may need to act with awesome velocity. This project needs, in some ways, to be managed like a quest. You need to have very tight control over costs and timescale; you need to investigate many options and possible solutions in parallel. Like a quest, these projects can end up in delivering nothing of benefit unless firmly controlled.
This project is formally called an open project.
Each of these project types has different characteristics and requires different leadership styles. They are also suited for different purposes.
Project type | Type of change it helps create or manage | Application |
Painting by numbers | Evolutionary | Improving your continuing business operations |
Going on a quest | Revolutionary outside current | Proactively exploring operations and ways of working (recipe) |
Making a movie | Evolutionary | Leveraging existing capabilities |
Lost in a fog | Revolutionary | Solving problem or exploring area outside your current operations and ways of working (recipe) |
Source: Eddie Obeng, Putting Strategy to Work (London: Pitman Publishing, 1996)
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.
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.
Some companies tie themselves up in process rules bound neatly in files with quality assurance labels. These rules often go to great levels of detail covering every conceivable scenario.
I would argue that this is a fruitless exercise. It is far better to have a few basic principles and make sure your people understand why you need them and how they help them do their jobs. You can then handle the odd ‘exception’ using ‘exception management’, dealing with it on its own merits within the principles you have laid out. In other words, give the managers and supervisors the freedom to do their jobs and exercise the very skills you are paying them for.
If you write rules at a microlevel:
‘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:
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.)
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).
The lessons from Chapter 2 have taught us that there is no ‘fast track’ process. If there were, it would become the usual process (see p. 18). ‘Agile’, ‘Rapid’ or ‘DSDM’ are software development methods or techniques which enable you to develop your deliverables faster within the overall project framework. A correctly designed and applied staged framework should not slow any projects down unless they need to be.
Agile techniques are used when they suit the particular circumstances of the project. If you use them merely because you are ‘in a hurry’, you risk reducing your project to chaos, i.e. it will become ‘rabid’ rather than rapid!
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:
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:
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:
Programme | Project | |
is equivalent to | ||
Project | Subproject |
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 project, in a business environment, is:
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.
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.
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:
Both these require greater coordination by the project manager.
From this we are able to define subprojects more exactly:
Subprojects are tightly coupled and tightly aligned parts of a project which are undertaken in stages.
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.
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:
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.
3.144.37.196