In this part, I describe methods, tools, and techniques for managing the six project management functions: scope, organization, quality, cost, time, and the risk that pervades them all. The aim of these six functions is to undertake the work of the project and to deliver the desired performance improvement at a time and a cost that provides value for the sponsor. That is, they are about managing the performance of the project, and the asset it produces. I start with scope. The next four chapters deal with the other five functions.
Scope management is mandatory; without scope management there is no project. It can be defined as the process of ensuring that
An adequate, or sufficient, amount of work is done.
Unnecessary work is not done.
The work which is done delivers the desired performance improvement.
There are four essential steps to scope management:
1. Developing the concept through the project's objectives and product breakdown structure
2. Defining the scope of work through the work breakdown structure
3. Authorising and executing the work, and monitoring and controlling progress
4. Commissioning the facility to produce the product and obtain the desired benefit
Through the process of managing the scope the owner's requirements are converted first into the definition of the new asset required to produce the desired performance improvement, and then into a statement of the work required to construct and commission that asset, and then the work identified is brought to a successful conclusion. This is the raison d'être of project management, and so scope management is the principal project management function.
In this chapter, I describe the methods, tools, and techniques used to manage scope. I start by revisiting the principles of good project management introduced in Sec. 3.5 and show how these are achieved by the use of product and work breakdown. I then explain how the products and work are defined at the three fundamental levels of breakdown: How to define the facility required to achieve the owner's purpose and the broad areas of work required to construct that facility? how to break the facility into intermediate products, or milestones, in each of the areas of work? and how to specify the work, as activities required to produce the intermediate products? I end by illustrating the concepts with several case studies.
5.1 PRINCIPLES OF SCOPE MANAGEMENT
Four of the principles introduced in Sec. 3.5 relate to scope management:
Manage through a breakdown structure.
Focus on results.
Balance objectives and levels of ambition.
Keep it simple.
All four of these principles can be met by the use of a breakdown structure. I showed in Sec. 1.1 that breakdown is inherent in projects and follows from the definition, and so the principles support the inherent nature of projects. The second will be achieved if the primary breakdown is via a product breakdown structure (PBS). The third is achieved by ensuring that results are delivered in all areas of the project, and by balancing the work through the work breakdown structure (WBS). The fourth is achieved if we use single-page reporting at all levels of the project. In this section, I consider product and work breakdown.
Breakdown
Breakdown is a technique by which the project is divided and subdivided for management and control purposes. Rather than breaking the work of the project into a low level of detail in a single step, it is devolved through increasing levels of detail. Focusing on results means we start with a PBS. The PBS is developed by breaking the asset into intermediate or subproducts. The work required to produce each subproduct and the work required to assemble and commission the facility from the subproducts is then identified. In Sec. 1.1, I described three fundamental levels of breakdown: integrative, strategic, and detail. However, a WBS can be developed to many more levels and I have seen up to seven levels used on large engineering projects. Table 1.5 shows a typical structure, with several levels of deliverables, associated work elements, and possible relative durations for a project lasting about a year. This structure shows the project as part of a much larger program of work, required to deliver the company's 5- or 10-year objectives.
Advantages of Using a Breakdown Structure
There are several reasons for using breakdown:
Better Control. The use of a breakdown structure satisfies the first three principles of good project management in Sec. 3.5. One of the pitfalls in planning is to develop the work definition at a single, detailed level. Developing the definition in a structured way ensures better results. Further, by defining work through its deliverables ensures that, as the project progresses, only work necessary to produce the facility is done, not work which was envisaged some months previously but is no longer required. Hence, the plan also becomes more stable. The work required can change in changing circumstances, but only certain results build towards the required end objective. This is clearly the case in research and development projects, where the process of doing the project defines the work to be done. However, it can also be true of engineering, construction, information technology, and organizational development projects. For example, the construction of an aeroplane and a submarine involves similar activities:
The fabrication of metal into a cylindrical pressure vessel
Internal outfitting to support life in a hostile environment
The fitting of propulsion equipment
On a detail level the work appears the same. However, one set of intermediate products leads to an airbus, and another to a submarine. The high levels of definition can also be used to balance areas of work. By developing the definition at a detail level only, there is a risk that we give undue emphasis to one area only. This may be technical work over cultural work (Sec. 2.2), or it may be our own area of expertise at the expense of another. On Heysham 2 Nuclear Power Station in the United Kingdom, the computer systems required to operate the plant were not given sufficient emphasis in the plan, swamped by the engineering work, and would have delayed commissioning several months, if it were not for another technical problem. A small amount of work could have kept a multibillion pound investment lying idle.1
Coherent Delegation. The parcelling of work in a breakdown structure is natural, because it is aimed at achieving a product. Responsibility can be assigned to individual parties for each product. In fact, they can be left to identify the actual work required, and in this way experts retain their integrity, while being set measurable targets. Sometimes this can be the only way to control progress on a research project, as the work itself is unknown, only the intermediate results can be measured. If work is defined at a detail level and amalgamated into packages, then they may not actually be natural packages of work, and the project manager can appear to be telling people more technically skilled than themselves how to do the work.
Levels of Estimating and Control. The lowest level of work breakdown appropriate for estimating and control depends on
The size, type, and duration of the project
The purpose for which the estimates will be used
The current stage in the project management life cycle
The requirement for effective control
I find on projects of a year's duration that activities of 2-weeks duration are the lowest appropriate level for planning and control. There is a law of diminishing returns which makes it inefficient to plan and estimate at lower levels, except in areas of high risk.
Lowest level of work breakdown: The activity level is the lowest level for central planning, estimating, and control. However, individuals may plan their own work at the task level. The lowest level does depend on the size of the project. On a 4-week overhaul of ammonia plants, the lowest level of planning was activities of 2 to 4 hours. On the other hand, I worked briefly on a project of 7-year duration, on which people were planning steps of 4-hour duration 6 months in advance. The plans were meaningless.
Lowest level of estimating: Because of inherent uncertainties, there is only a certain level of accuracy you can expect. It is pointless to plan in greater detail. The people on the 7-year project thought planning at lower levels improved the overall accuracy. Unfortunately, this is not the case. Probability theory tells us that the percentage error of the part as a ratio of the percentage error of the whole is inversely proportional to the square root of the size:
±e%/±E% = √(S/s)
We might expect to finish a year long project, S = 52 weeks, to within a month, E ± 10 percent. Therefore on an activity of 2-weeks duration, we need to be accurate to within 1 week, i.e., ±50 percent. On a task of 2-day duration, we need to be accurate to within 2 days, e = ±100 percent. The accuracy on smaller steps is even more meaningless.
Planning in greater detail also requires more effort in estimating. The formula above implies that doubling the accuracy of the estimate requires four times as much planning effort, and this has been measured in the process plant industry.2 Therefore, at early stages of the project, you want very coarse estimates, obtained by planning at high levels of breakdown, with lower levels developed only as the project is shown to be viable at the high levels. You also reach a point at about E = ±5 percent accuracy, at which it costs more to estimate than the value of the data you are getting. This sets a limit on the lowest worthwhile level of breakdown for estimating purposes. I return to this concept in Chap. 8.
Lowest level of control: Similar arguments apply to the level at which the project is controlled: Controlling at a lower level can mean more time is spent in control than doing work; controlling at a higher level means slippages can get out of hand before they are recognized. The appropriate size of activity for control is the same as the frequency of control meetings. If meetings are once a fortnight, activities should, on average, be a fortnight long. Then, at each review an activity is either not started, finished, or half finished: three simple states. If activities are very much shorter, then it will be difficult to determine what is critical for completion. If they are very much longer, then the percentage completion will be reported as the elapsed time divided by the original duration while that is less than one, and 99 percent while it is greater until the activity is actually finished.
Containment of Risk. I qualified remarks above by saying it did not apply in areas of high risk. In fact, there is no need to take the WBS down to the same level. The lowest level of WBS may vary according to the level of risk: In areas of low risk you may stop as high as the work package level; in areas of high risk you may continue to a very low level of WBS, depending on
The uncertainty introduced by the risk
The need to contain the risk
Project definition initiates the project and therefore relates the work of the project to the sponsor's business objectives. To achieve this, it is necessary to identify the sponsor's requirements, including the facility expected to satisfy them, and then to identify the broad areas of work required to construct the facility. The benefits map (Sec. 2.3) has already initiated this process; project definition converts them into a form the project team can work with. This requires the following three things to be defined:
The purpose of the project
The overall scope of work
The outputs from the project
The Purpose. This is a statement of the business need to be achieved. As we have seen, it may be a problem to be solved, an opportunity to be exploited, a benefit to be obtained, or the elimination of an inefficiency, and will be derived from the strategic objectives of the parent organization and the desired performance improvement (Chap. 2). The statement of the purpose should be clear and precise, and contain both quantitative and qualitative measures. Once the project is underway, it will become the mission of those involved in the project, both as project team members and as resource providers. It can be a powerful motivating force if it is seen to be worthwhile and beneficial to the business, and can help to build cooperation. Of course, it can be a powerful demotivator if it is seen to conflict with individuals' self-interest (Example 5.1).
Example 5.1 Project objectives and personal objectives in conflict
I was involved with a project where the user representative on the team stood to be made redundant if the project was successful. He had been appointed by his general manager, because the project was likely to make a large proportion of his department redundant, reducing his empire. The project was not successful; and in fact came to an abrupt halt when we held a project definition workshop (Chap. 11). It was impossible to maintain the pretence. However, 2 years later it was overtaken by a larger project which merged several subsidiary companies into a larger unit. The general manager lost his job.
The Scope. This is an initial, high-level description of the way in which the purpose will be satisfied. If the purpose is viewed as a problem to be solved, the scope will identify possible solutions, and the one selected for further work; these comprise the fourth, fifth, and sixth steps in Fig. 1.6 and Table 1.4. The statement of scope includes three things:
1. The work within the remit of the project, required to solve the problem and achieve the benefits
2. The work which falls outside the remit of the project
3. Interfaces with other projects in the program
The inclusions will later be made redundant by the initial stages of work breakdown. However, it is important to include them in the statement of project definition. They are a key step in the problem-solving process, which indicate the thought processes of the people drawing up the project definition. The exclusions can arise either because the work is not required to achieve the benefits, (although it would be nice to have), or because it is being handled elsewhere. The sponsor does not have a limitless pot of gold, and so a boundary must be set on the work to be done. Sometimes the potential benefit must be reduced to match the available funds. Also, when a project is taking place as part of a larger program, it may share work with other projects. It can then be more efficient to have one project handle all the joint work. This is especially true when projects create a need for redeployment or redundancy. One project may then delegate the work to the other. For whatever reason, the exclusions must be clearly stated, so that they are understood by people joining the project later, and so that interfaces with other projects are identified and managed (Chap. 16). These exclusions will include the definition of interfaces with other projects in the program.
The Outputs. These are quantitative and qualitative measures by which completion of the project will be judged. They identify the facility to be produced by the project. If the facility is an engineering construction (factory, dam, or chemical plant, say), then the outputs may be something like:When the facility has been constructed, the supporting establishment is in place, the facility has been commissioned, and is operating to a certain percentage of capacity.
A similar statement can apply to a computer system, management development program, or organizational change. You will notice the statement implies the facility has been shown to be able to achieve some of the benefits. People are usually quite happy with this for a factory, less so for a computer system, or organizational change process. In the latter cases, the project is over once the system is commissioned, and the project team have no responsibility for ensuring that it works properly!!! It is not always possible to set the project's benefits as the objectives, as they may not be achieved until some time after the end of the project, and the facility has been commissioned. However, it is important that the outputs are likely to deliver the benefits, and the project team addreses the question of how they are to be attained. Further the outputs should
Address all the work within the scope of the project
Not address work outside the scope of the project
Begin to set parameters for managing quality, cost, and time
You will see now why it is important to record the scope of the project.
Initiating Work Breakdown
The statement of the outputs completes the project definition. It is now possible to begin the process of work breakdown by defining areas of work. Each area of work delivers one of the project's objectives, linking the integrative level, level 1, to the strategic level, level 2. The areas of work may form subprojects, as in Table 1.5. In Chap. 12, I describe the project definition report. The statement of purpose, scope, and objectives appears in an early section, and sets the scene for the project. The areas of work appear in the section on work breakdown. It is important that the areas of work cover all the objectives, but no more.
Case Study
Table 5.1 gives the project definition for the CRMO Project from TriMagi introduced in Example 2.6. It gives statement of purpose, scope, outputs, and areas of work. The definition of the project contains a statement of the expected time scale: 5 months to the commissioning of the first offices and 9 months to completion of the project. At this stage, these are targets. People familiar with the technology should be able to say whether they are realistic, but the precise timescale would only be determined as the project plan is developed to lower levels. However, I am a great believer in being goal directed, aiming to achieve this target and scheduling the work appropriately, rather than allowing theoretical mathematics in the form of a network to impose a longer duration. Often tight timescales can be achieved with management effort. Similarly, there is already enough information for experts to begin to develop initial estimates of capital cost and revenue for the project.
5.3 PLANNING AT THE STRATEGIC LEVEL:
MILESTONE PLANS
Having defined the project, we are in a position to develop the work breakdown structure to the second level, the strategic level. I now describe the requirements for planning at this level, and then introduce a tool, the milestone plan,3 which satisfies these requirements.
TABLE 5.1 Project Definition for TriMagi's CRMO Rationalization Project
Requirements for Planning at the Strategic Level
At the second level of breakdown, the manager sets the strategy for the project. The plan at this level:
Shows how the intermediate products, or deliverables, build towards the final outputs
Sets a stable framework, fixed goal-posts, for the team, and so provides a common vision
Controls devolution of the management of the scope to other parties
I described above how similar activities are involved in the manufacture of an airbus or submarine, yet one set of intermediate products delivers an aircraft, another a submarine. It is at the second level of WBS that we set the strategy, showing how the intermediate products build towards the facility to be delivered by this project. Because only one set of intermediate products delivers the required final objective of this project, the plan at this level can be made stable. This can be a powerful motivating tool, giving the project team a common vision.
To build a common vision, the plan should be represented on one page. It then presents a clear picture of the strategy for the project. It is through this single page, the milestone plan, that the project manager communicates the overall strategy of the project upwards to the project sponsor, and downwards to the project team. This was the fifth principle of good project management introduced in Sec. 3.5. It is also at this level that focusing on the deliverables can help delegate work to subproject teams. A team accepts responsibility for the delivery of an intermediate product, and plans its own work to deliver that milestone independently of other project members. They know that they must achieve their milestone by a certain date to enable the project to proceed, but they are able to work without interference. We have seen how this can allow professional people to retain their integrity when working for a project manager from a different discipline.
Milestone Planning
It is common, when developing the plan at the second level to define the packages of work first, and then define the deliverable which results from each work package. However, for the reasons above, I suggest that you define the deliverables, or milestones first, in the form of a milestone plan.3 The packages of work which result in each milestone are derived later. The milestone plan is a strategic plan, or framework, for a project, defined in terms of intermediate
FIGURE 5.1 The milestone plan.
products, or results, to be achieved. It shows the logical sequence of the states a project must pass through to achieve the final objectives, describing what is to be achieved at each state, not how the state is to be achieved. Figure 5.1 illustrates the milestone plan, with the circles representing the milestones, and the lines joining them representing the logical dependency between them. Hence, the milestone plan represents a logical network for the project.
We return to networks in Chap. 9 where two types are described: precedence and activity-on-arrow networks. In precedence networks, work is represented by the nodes of the network. These are joined by arrows representing the logical dependency of the work. In an activity-on-arrow network, work is represented by the arrows. The nodes are events in time, and the logic is represented by the way the arrows join at the nodes. The milestone plan is a precedence network. The circles in Fig. 5.1 represent packages of work, defined by the results they deliver. The arrows show how one package follows another, and are known as end-to-end dependencies: The end of one package, milestone, is dependent on the end of the previous one. They say nothing about the start of the work: One package can start before the previous one has finished. This allows greater flexibility in scheduling the work.
Areas of Work
In Fig. 5.1, the milestones are grouped into vertical columns representing the areas of work. One of the principles in Sec. 3.5 was to balance the changes. I suggested that the WBS should be used to ensure that equal emphasis is given to work in different areas. The areas of work give visual representation to this. By inspecting the areas of work you can ask yourself one of two questions, as illustrated in Example 5.2:
Have all the areas of work been covered, or has something been left out? In particular, have the cultural changes been addressed?
Has equal emphasis been given to all areas of work?
Example 5.2 Balancing objectives through the areas of work
I did some work with a research establishment where they were installing a larger computer to store the empirical data from a particularly large experiment they were conducting. I helped them plan the project to make the change. The plan had three areas of work:
1. Hardware and software
2. The database
3. The establishment
Down the first path, there were a large number of milestones:
Hardware and software selected
Hardware installed
Operating system loaded
Database software loaded
System tested
There were a similar number of milestones in the third path:
Computer room ready to receive machine
Furniture obtained
Operating procedures written
Operators recruited
Operators trained
There were only two milestones in the central path:
Data transferred
System commissioned
Without prompting from me, the two people working with me on the development plan said, "Hold on! The purpose of this project is not to obtain new hardware and software, and not to create a new establishment. It is because the data has got too large for the old machine. We ought to be giving greater emphasis to the database." They, therefore, inserted two more milestones in the centre column. One dealt with data cleanse, that means, removing incorrect, incomplete, or redundant data. The other dealt with restructuring the database to meet future, rather than historical, requirements. (These two milestones may have made the rest redundant!!!)
Features of the Milestone Plan
A good milestone plan should satisfy several requirements.
Be Understandable to Everyone. The milestone plan is a tool to build cooperation and commitment to a common vision. It must therefore be understood by all those involved in the project. This requires the milestone descriptions to be written in clear English, not in technical jargon, only understandable to a few. Writing the plan in technical jargon shows how important you are, protects the work for yourself, and builds demarcations to make sure others aren't involved in the project. It is not good for the involvement, commitment, and cooperation of others.
Provide Quantitative and Qualitative Control. The plan is a tool for control, and so the milestone descriptions must be precise, so you can determine when they have been achieved. Technical milestones can be given a quantitative measure, such as "when the new machine is operating at design capacity." (Even that will have a quality measure built in.) Other milestones must be given a qualitative description, with some measure of quality written in. For example, it is not adequate to say "when a report is written." Two lines on the back of an envelope satisfy that. The report must
Meet certain requirements
Satisfy a steering committee
Allow a decision to be made
A milestone such as "when the design is finished" is neither measurable nor achievable. You can't know the design really is finished, so you can't achieve it. A milestone such as "when the team accept the design as a basis for the next stage of the project" can be measured and achieved. Focusing on the decision provides better qualitative control.
Focus on Decisions. Milestones represent intermediate deliverables en route to the final objective. Often the interesting deliverable is not the production of a design or report. That is not the purpose of the work. It is the taking of a decision, based on the design or report, to allow more work to proceed. That is the required deliverable, and is controllable. The responsibility chart (Chap. 6) defines who is to take the decision.
Show the Logical Sequence. The milestone plan is a logical plan. It contains a network, which shows the strategy for building through the intermediate products to achieve the final objective.
Give a Single-Page Overview. The objective is to produce a plan on a single page which clearly communicates the project strategy. This is achieved if the number of milestones and areas of work is limited. The ideal number of milestones is somewhere between one and two dozen. With fewer the plan does not give a useful structure, and with more it becomes confusing. Similarly, I suggest three or four areas of work. Thus the number of milestones determines the size of the work packages, rather than the size of work packages determining the number of milestones. On small projects this will be the only level of planning. On large projects it will be the first of several.
Representing the Milestone Plan
In Fig. 5.1, the milestone plan is drawn down the page, whereas it is common to draw a network across the page (Chap. 9). However, I like to represent the milestone plan as a process flow diagram for the project, with three columns (Fig. 5.2):
1. The central one is for drawing the network.
2. The right-hand one is for writing the description of the milestones (which in themselves describe the packages of work).
3. The left-hand column is for the dates, once the work has been scheduled (Chap. 9).
The right-hand column gives adequate room to write a full description of the milestone, whereas if you draw the network across the page, you have to write small to fit the description into the box or onto the arrow. It may seem heretical to draw the network down the page, but it does allow the network and a full description of the work to be portrayed on a single page. It also represents the milestone plan as a process flow diagram for the project, emphasizing the process nature. Figure 5.2 is a milestone plan for the CRMO Rationalization Project.
FIGURE 5.2 Milestone plan for the CRMO Rationalization Project.
Developing the Milestone Plan
Ideally, the milestone plan should be developed in a project start-up workshop (Chap. 12), with selected managers and project personnel present. Developing the plan in a group session builds greater commitment than the project manager developing it on their own and trying to impose it on the team. However, to be effective the workshop should not have more than about six people present. The process I recommend for developing the plan has six steps:
1. Start by agreeing the final milestone, the end of the project. The project definition and benefits map should help this. If you have completed Hartman's three questions (Sec. 3.1.1), you will already have done this step.
2. Generate ideas for milestones. Brainstorm them on to flip-charts.
3. Review the milestones. Some will be part of another milestone. Some will be activities, but will generate ideas for new milestones. As you rationalize the list record your decisions, especially where you have decided that a milestone is part of a larger one.
4. Write the milestones on Post-It notes and stick them in the areas of work, in the order they occur. In this step, you may actually review the definition of the areas of work (Example 5.3).
5. Draw the logical dependencies, starting with the final objective and working back. This may make you to review the definition of milestones, add new milestones, merge milestones, or change the definition of the areas of work (Example 5.3).
6. Make a final drawing of the plan.
Example 5.3 Reviewing the areas of work
I was working with a project team who were developing a computer system. They started with four areas of work
The hardware and software in the computer centre
The computer network linking the computer centre to offices
Furnishing of the offices
Management procedures and people development
When they came to put the milestones into the areas of work, they found that there were several that didn't fit into those four areas. They included things like
Agree the success criteria.
Obtain approval for the budget.
Mobilize the team.
Measure achievement of the success criteria.
These were for them important project management milestones. So they created a fifth column to contain them. But when they came to draw the project network, they found that the computer network and office furnishing were so intertwined they combined those two areas of work and went back to four.
Work Breakdown Structure
The milestone plan, as shown in Fig. 5.2, is a communication tool to communicate the project strategy to the parties involved. It represents both the work and its logical relationship. However, we should not lose sight of the fact that we are developing level 2 of the WBS. Figure 5.3 shows the WBS tree, for the CRMO Rationalization Project. This can be represented as a simple list (Table 5.2).
The milestone plan can be supported by plans at lower levels. These will include activity plans, work package scope statements, and subsidiary milestone plan.
Activity Plans
These detail the work packages which lead to the milestones, and describe the work at the next level of work breakdown. Following the principle of single-page reporting, the number of activities making up a work package should be limited to 15. I find six to ten a useful number. Figure 5.4 is an activity plan for Milestone P1 in the CRMO Rationalization Project.
FIGURE 5.3 WBS for the CRMO Rationalization Project.
TABLE 5.2 WBS for the CRMO Rationalization Project
| |
TriMagi Milestone List | |
| |
Accommodation | A1: Estates plan A2: Sites 1 and 2 obtained A3: Sites 1 and 2 ready A4: Estates roll-out |
Technology | T1: Technology design T2: MIS design T3: Technology plan T4: System in sites 1 and 2 T5: MIS delivered T6: Technology roll out |
Organization | O1: Communications plan O2: Operational procedures O3: Job/management design O4: Staff allocation O5: Management changes O6: Redeployment and training O7: Procedures implemented |
Project | P1: Project definition P2: Financial approval P3: Intermediate review P4: Post-completion audit |
| |
FIGURE 5.4 Activity plan for milestone P1 in the CRMO Rationalization Project.
Some people try to derive a full definition of the activities before any work is done. People who misuse networking systems, creating activity definition without the supporting WBS, are forced into this. However, most modern approaches to project management recommend what is called a rolling-wave approach to activity planning. This is core to the PRINCE2 methodology, for instance.4 Fully detailed activity plans are only derived and maintained for those work packages which are current, or about to start. The detailing of later work packages is left until necessary, so that as much current information as possible is used to derive the activities. Some computer-based networking packages will support this approach by allowing the nesting of networks. There are several reasons for this approach:
1. You wait until you know you are likely to do the work before expending effort on detail planning. I spoke above of increasing the accuracy of the estimates during subsequent stages of the life cycle by spending increasing time on planning and design. To prepare estimates at project initiation stage you should estimate at the work-package level, and not prepare the activity definition. Some people find this uncomfortable, but I have worked in organizations which have prepared quite detailed designs and estimates for projects, only to find the project uneconomic.
2. You prepare detail activity plans when you have maximum information. If you prepare a detail plan for a yearlong project at the start, the only thing you can guarantee is you are wrong. You would have left out things which should be included, and included things which should be left out. It is better to prepare the detail activity definition when you have gathered information about the best way to achieve the milestone. This is especially true on development projects, where work in the early stages will determine work in the latter stages. You will know what the later milestones are, if you are to reach your final objective, but you will not know how they are to be achieved. There is no point in trying to guess, because it serves no purpose and wastes time.
3. You can delegate the definition of activities to reach a milestone to the teams who will be undertaking the work.
Work Package Scope Statements
Although the detail activity planning is done on a rolling-wave basis, it is necessary to prepare some definition of the scope of each work package at an earlier stage. There are several reasons for this:
1. It is necessary to prepare some form of estimate of work content and duration for early, high-level estimating and scheduling. This should be based on some substance, even if it is only an approximate statement of the most likely outcome.
2. Work packages may include activities with a long lead time. These must be recognized and started in time.
3. While preparing the milestone plan you may decide that one proposed milestone is actually an activity in another milestone. This must be recorded.
These requirements can be satisfied by preparing work-package scope statements. These will be akin to the definition of scope and areas of work for the project as a whole, but on a smaller scale. The milestone name, remember, defines the purpose and objectives of the work package. The work-package scope statement can also include a measure of completion for configuration management purposes (Chap. 7). Table 5.3
TABLE 5.3 Work-Package Scope Statement for Milestone P1 for TriMagi's CRMO Rationalization Project
| |
TriMagi | |
| |
Milestone | P1: When the project plans have been prepared and resources assigned to the project. |
Scope | The work package requires the preparation of high-level plans and estimates to be prepared, to enable resource budgets to be prepared, and their availability agreed. |
Possible work | Identify key managers. Hold launch workshop. Finalize milestone plan and project responsibility chart. Estimate resource requirements and durations. Schedule resource requirements. Discuss requirements with managers. Plan and agree resource availability. |
Measure of completion | Project plans approved by the steering committee. Resource managers sign agreements to resource availability. |
| |
contains a sample work-package scope statement for Milestone P1 in the CRMO Rationalization Project.
Subsidiary Milestone Plan
Sometimes there is a milestone which requires a particularly large amount of work. You may want to define intermediate milestones as control points through that work, but there may be no natural milestone to use on the level of the milestones plan. It is not sufficient to define milestones such as "when the work is 25 percent complete," because that is not measurable. In these circumstances, it may be worthwhile to derive a subsidiary milestone plan for that package of work. In effect, the work package is treated as a miniproject. Figure 5.5 is the milestone plan for developing a compiler for a computer language. Milestone C1 is of the type described, requiring 5 months of work to achieve it. However, there are no natural milestones on the level of this plan to define control points through the work. The team therefore derived a subsidiary plan (Fig. 5.6) for that milestone alone.
FIGURE 5.5 Milestone plan for developing a compiler language.
FIGURE 5.6 Subsidiary milestone plan for milestone C1.
I close this chapter by describing some applications of milestone planning:
Different Stages of the Project Management Life Cycle
Milestone plans can be prepared for work at all stages of the project life cycle, not just the execution stage. The management emphasis changes throughout each of these stages:
1. At the early stages, the emphasis is on encouraging creativity. The milestone descriptions should enable this by allowing maximum flexibility in the way the milestones are achieved, and the results delivered, while still providing a framework for control.
2. At the later stages, the emphasis will be on completing the work. Money is being spent, and so the benefits must be obtained as quickly as possible. Therefore the milestone names will be more prescriptive, providing more rigid control.
Large Multidisciplinary Projects
I have worked on several large multidisciplinary projects which for management purposes we divided into several subprojects almost independent of each other, and each the responsibility of a separate discipline. The project team derived a milestone plan for each subproject, and each discipline was then able to work virtually independently of the other, corresponding only at key milestones. I have applied this approach to construction projects, development projects, and IT projects.
North Sea Oil Field Development. This development consisted of two phases each of £3 billion. In the first phase, the project used well-known, mainframe-based project planning software, and planned at a fairly low level of detail. Management reports were 150 pages of computer output, and the management team had no visible control. In the second phase, it was recommended that they adopt a work breakdown structure. The development was divided into several contracts, and each contract into several stages, such as
Feasibility
Design
Procurement
Construction
Linkup
Commissioning
A milestone plan was prepared for each contract stage. The management team monitored against the milestone plans. The project teams supported these with lower level plans.
Regional Health Authority, Regional Distribution. The Health Authority was changing from distributing supplies through each of the 15 districts, to regionally coordinated distribution. The project was divided into 22 subprojects, each with its own milestone plan, and each the responsibility of a separate discipline. There were a few easily monitored links between each plan. The projects were:
Construction of the regional warehouse
Creation of the warehouse establishment
Implementation of computer systems
Recruitment, redeployment, and training
Switching from district buying to regional buying
Switching from district revenue to regional revenue
District implementation (15 districts)
Commissioning the warehouse
Each discipline met once every 2 weeks to monitor progress against their plan. The team leaders then met every 6 weeks to monitor progress of the project overall, by comparing progress on each plan.
Computerization of the Norwegian Securities Service. This program consisted of four subprojects:
Design and implementation of the computer system
Creation of a company to operate it
Registration of dealers and holders of stock
Legal basis
An overall milestone plan was developed for the program as a whole. Subsidiary milestone plans were also prepared for the first two subprojects. This project involved one million people, and yet was managed to a successful conclusion using manual planning methods only by taking this structured approach. At one point the Norwegian government tried to delay passing the enabling legislation by 12 months. Using the top-level plan, the project team was able to demonstrate to the minister that would delay the project by 12 months, and effectively kill it. The argument won the day and the bill was passed.
Customer Service System in a Regional Supply Company of a Large Public Utility.Implementation of the customer service system (CSS) required several projects:
Implementation of hardware and software
Transfer of data
Networking of buildings
Estates refurbishment
Writing operating procedures
Training
Commissioning
Again, an overall milestone plan was developed, supported by milestone plans for each subproject.
Summary. All of these projects involve a mixture of
Construction or building work
Information systems work
Organizational change
Recruitment, redevelopment, and training
They were all PSO Projects. They each also had a duration of about 2 to 3 years, and each was finished on time and to cost, while just using simple planning methods.
1. The purpose of scope management is to ensure
Adequate work is done
Unnecessary work is not done
The project's purpose is achieved
2. Work breakdown is a process by which the work of the project is subdivided for management and control purposes.
3. The project is defined at the strategic level, through
The purpose: The problem to be solved, or the opportunity to be exploited, and the benefit to be obtained
The scope: The solutions to the problem, and covering the inclusions, (work within the remit of the project), and the exclusions (work outside the remit, because it is deemed unnecessary, or because it is shared with other projects)
The outputs: The facility to be measured, quantitative and qualitative measures of when the project is complete
4. At the strategic level, the milestone plan
Shows how the intermediate products, or deliverables, build towards the final objectives of the project
Sets a stable framework and fixed goal-posts for the project team, and thereby provides a common vision
Controls devolution of the management of the scope
5. A good milestone plan
Is understandable to everyone
Is controllable
Focuses on necessary decisions
Is logical
Gives an overview to build cooperation and commitment of all the parties involved
6. There are seven steps in milestone planning:
Agree the final milestone
Brain-storm milestones
Review the list
Experiment with result paths (areas of work)
Draw the logical dependencies
Make the final plan
7. Plans at lower levels of work breakdown include
Subsidiary milestone plans
Work-package scope statements
Activity plans developed on a rolling-wave basis
1. Morris, P.W.G. and Hough, G.H., The Anatomy of Major Projects: The Reality of Project Management, New York, N.Y.: Wiley, 1987.
2. Gerrard, A.M., Guide to Capital Cost Estimating, Rugby, U.K.: Institution of Chemical Engineers, 2000.
3. Andersen, E.S., Grude, K.V., Haug, T., Katagiri, M., and Turner, J.R., Goal Directed Project Management, 3rd ed., London, U.K.: Kogan Page/Coopers & Lybrand, 2004.
4. Office of Government Commerce, Managing Successful Projects with PRINCE2, 4th ed., London, U.K.: The Stationery Office, 2005.