In this chapter, I describe the project start-up processes, explaining how to get the project initiated. Some people assume project start-up only occurs at the very start of the project, in the concept stage, but in reality the processes described in this chapter can take place at the start of any of the stages in the project life cycle, even in close out. You may want to conduct the start processes whenever there is a significant change in the project team, either in its composition or structure, or when you believe the project team's attention needs refocusing on the objectives of the stage ahead. In this chapter, I explain the need for the start-up processes, and describe the objectives and methods of start-up. I describe the tools of start-up including the start-up workshop and the project definition report and project manual.
A project requires the undertaking of a unique task using a novel organization, which must be created at the start of the project. When new teams form, the members take time to learn how to work together before becoming truly effective. Typically, a team goes through four stages of formation in which its effectiveness first falls and then rises1 (Sec. 4.5):
a. Forming: The team members come together. The team members are proud they have been chosen to work on this important project. However, they are uncertain of each other and of their roles and so their effectiveness is only at a medium level. Second worst-case scenario is the team remains in this stage for the duration of the project.
b. Storming: They find areas of disagreement. They can't agree on the problem they are trying to solve, nor the objectives of the project. They therefore can't agree to the project plan, who is responsible for what, what work they have to do, nor how to get started. Perhaps they can't even agree upon the project management methodology to use. The team's performance falls, and worst-case scenario is it continues to fall and never recovers.
c. Norming: The team finds they can agree on some things and build cooperation around that. They agree upon the problem they are trying to solve, and thus the project objectives. From there they develop a milestone plan and responsibility charts, and define the work they individually have to do. This is called norming because during this stage the team forms norms of behaviour about what it means to be a member of this team, and identify with it more. Part of the norming process is they agree with the project management methodology. During this stage team effectiveness rises.
d. Performing: The team maintains its peak performance throughout the project.
A project is subject to time constraints, and so this process must be undertaken in a structured way to ensure it happens quickly. This is called project start-up.2,3 The term project start-up is used to differentiate from start; the former is a structured process for team formation; the latter is an action at an instant of time. Morten Fangel draws the analogy with starting the engine of a car, and starting-up the diesel engine in a ship.2,3 The former is achieved by flicking the ignition switch, the latter by a structured series of activities, a startup process, which gives the most efficient and economical operation. The same applies to projects.
The start-up process can take two to three days but some people think that they don't have time to devote to it. They have to get on with the project, rather than spend time sitting around working on project plans. But you have to ask yourself, what is more effective, to have the team work at 50 percent efficiency for the duration of the project, or 120 percent efficiency for all but the first three days (Example 12.1). It is now widely accepted that a structured start-up process is an essential part of project management. It is necessary, on a unique, novel, and transient endeavour, to improve the understanding of the project team of the task they face, and how they will approach it, and to get them working effectively as a single unit. There has been an increasing need for effective start-up on projects, and this may be due to:
The increasing complexity of technologies used
The use of qualified project management earlier in the life cycle
The need for team building and cross-cultural cooperation
The need for increased effectiveness caused by shorter product life cycles
Changes in the way projects are managed, including goal-directed approaches, which reinforce the setting of objectives, the use of group methods for building cooperation, and the management of the team through the use of a clear and common mission
Example 12.1 The power of start-up
I worked with a project team in British Telecom, a U.K. telephone company. The team of six people had seven weeks to complete a highly critical project. The project manager's manager was a great believer in the start-up process and insisted the team do no work in the first week. They were to spend the first week planning, three of those five days being spent in a start-up workshop with me. At the start of week two, the team hit the ground running and went on to have an extremely successful project. You have to ask which is better:
To work for seven weeks at 50 percent efficiency
Or to work for six weeks at 120 percent efficiency
My view is obvious.
The Objectives of Start-Up
For start-up to be successful, the participants must understand what the objectives of the process are at any stage, and must be aware of what specific outputs are needed to achieve the necessary level of understanding. These objectives can include
To create a shared vision for the project, by identifying its context, the desired performance improvement, and its objectives in terms of desired output and outcome.
To gain acceptance of the plans by defining the scope of work, project organization, constraints of quality, cost and time, and the planned response to the inherent risks.
TABLE 12.1 Shift of the Start-Up Objectives through the Life Cycle
| |||||
Objective | Concept | Feasibility | Design | Execution | Close-out |
| |||||
Context and objectives | Draft | Main | Review |
| Monitor |
The project model | Initiate | Draft | Main | Review |
|
The management approach |
| Initiate | Draft | Main | Review |
Commission and handover |
|
| Initiate | Draft | Main |
| |||||
To get the team working, agreeing its mode of operation and channels of communication.
To refocus the project team onto the purpose of the project and the method of achieving it.
The first three objectives correspond to Parts 1, 2, and 3 of this book, respectively; the fourth runs throughout. As they move through the project, the team's understanding of these develops in turn. During concept, the emphasis is on identifying the project's context, the desired performance improvement, and the changes needed achieve that, and from there to developing the shared vision and project strategy. During feasibility, the emphasis shifts to developing the project model (Fig. 1.11) and determining the feasibility of that model in terms of the ability of the project to deliver the desired output and the operability of that output to achieve the desired outcome and performance improvement. During design, the emphasis now is on formalizing the model into a plan for implementation. In execution, we deliver the desired output, including the detail design of the project's output and work methods, and actually doing the work. Finally, as the new asset is commissioned, and handed over to the client, the emphasis changes back to the purpose of, the benefit expected from the new asset, and the product it produces, to ensure the team are aware of what is actually required and so are better able to achieve it. Hence, the objectives of project start-up will be different at each stage of the life cycle (Table 12.1). Although, as you move from one stage to the next you may review the objectives of the previous stage and look forward to those of the next.
Below each of the 4 objectives are 15 subsidiary objectives (Table 12.2). These in turn may influence the emphasis of the work of the project team depending on the type of activity undertaken and decisions taken. The emphasis of the team's work may be:
Analysis: of the project's context, previous plans, future tasks, and management routines
Planning: of objectives, scope of work, organization, and routines
Communication: between participants of the results of the analysis and plans
Motivation: of participants to carry out work or make decisions
Table 12.2 relates the emphasis of the team's work to the 15 subsidiary objectives. When linked to Table 12.1, this shows that during the life cycle the emphasis shifts from analysis and planning to communication and motivation until the end when it switches back to analysis, which I think will match the experience of most people.
The Methods of Start-Up
Another requirement of a systematic approach to project start-up is the use of appropriate methods. There are three standard methods of start-up:
Project, stage, or even milestone launch workshops: to develop project plans in a joint team-building process
Start-up or stage review reports: to collate the results of analysis undertaken during startup or from a previous stage in accessible form for use during the subsequent stage
The use of ad hoc assistance: to support and guide the project team
TABLE 12.2 Ten Subsidiary Start-Up Objectives and Their Effect on the Working of the Team
| ||||
Subsidiary objectives | Analyze | Plan | Communicate | Motivate |
| ||||
Context & Objectives |
|
|
|
|
Impact of context | A |
| C | M |
Business purpose | A | P |
|
|
Objectives of project |
| P | C | M |
Project Model |
|
|
|
|
Milestone plan | A | P |
|
|
Responsibility chart |
| P | C | M |
Detail work plans |
| P | C | M |
Resource allocation |
| P | C | M |
Management System |
|
|
|
|
Management system |
| P |
|
|
Principles of cooperation |
|
| C | M |
Control processes |
| P | C |
|
Commission |
|
|
|
|
Timely, efficient end |
| P | C | M |
Disband team |
| P | C | M |
Handover to client |
| P | C |
|
Obtain benefits |
| P | C |
|
Record data | A |
| C |
|
| ||||
These techniques may be used individually or in combination. The choice depends on several factors. First, the different methods require varying amounts of time, so you must ensure key team members are willing to devote it. Secondly, the methods have different efficacy in achieving the objectives in Tables 12.1 and 12.2. Table 12.3 shows the different impact of each method. Thirdly, through project start-up you should try to build as much historical experience into the project definition as possible, to minimise the uncertainty. You should choose a method which does that for the case in hand. Other methods of startup include case studies, study tours, social events, education programmes, and other media, such as videos.
Launch Workshops. A launch workshop held at the start of the concept or feasibility stages may be called a project definition workshop, and at the start of design or execution an initiation or kick-off meeting. The objectives of the workshop, the agenda, and the people invited depend on the stage being launched, and are discussed more fully in Sec. 12.3.
Stage Review Report. A start-up or stage review report can be prepared at the end of any stage to launch the next. A report produced at the end of the concept stage for launching the
TABLE 12.3 Effectiveness of the Techniques for Project Start-Up
| ||||
Start-up technique | Analyze | Plan | Communicate | Motivate |
| ||||
Launch workshop | High | Medium | High | High |
Review report | Low | High | High | Medium |
Ad-hoc assistance | Medium | High | Low | Medium |
| ||||
feasibility study may be a one- or two-page project scope statement (Sec. 5.3 and Table 5.1). During the feasibility study, this is expanded into a project definition report or client requirements statement, used to launch design. At the end of that stage, a full project manual or project requirements statement may be produced in support of the design package, and that used to launch execution. The contents of each of these reports depend on the stage being reviewed, and are described in Sec. 12.4.
Ad hoc Assistance. This may be from:
Internal professionals, such as the project support office
External consultants
Team members from similar or earlier projects
Organizational behaviour experts helping manage the team dynamic
External professionals can fill one of two roles. They may be there to facilitate the team dynamics, to initiate the storming and the forming. Or they may be invited to bring specific technical expertise or bring experience from having worked on similar projects in the past. This can provide additional resources with special skills, which may motivate key people. Having someone to share ideas with can be stimulating. A disadvantage is there can be some confusion over responsibilities, which can lead to wasted effort.
Start-Up and the Type of Project
In Sec. 1.4, I introduced the goals and methods matrix, Figure 1.13. This defined four types of project. The emphasis of start-up differs for each type.
Type 1 Projects. The goals and methods of delivery are both well defined, and the team can move quickly into activity-based planning. These projects are usually very similar to ones done in the past, (not so unique and novel, runners or repeaters, Sec. 1.2). The emphasis of start-up is therefore on briefing the team on the standard techniques. External facilitators who have done similar projects in the past may be used to brief the team. The role of the project manager is something of a conductor, leading the team through the predefined score, but putting his or her own interpretation on it.
Type 2 Projects. The goals are well defined, but the methods of achieving them are not. The start-up workshop develops a milestone plan for the project, where the milestones represent the known products. It then develops a responsibility chart to define who is going to take responsibility for determining how to achieve the milestones. The workshop requires a broad cross-section of disciplines to be represented, including all the people who may have a contribution to make on how best to achieve the project. A facilitator may be used to norm the team's behaviour, gaining agreement to the milestones and responsibility chart. The role of the project manager is that of a coach. There is a clear objective of getting the ball in the goal as many times as possible in the next 90 minutes. The coach trains the team in standard plays, but leaving them to put them together as the game unfolds.
Type 3 Projects. The goals are not well understood, but the project will follow a standard life cycle, and the definition of the goals will be refined as the project proceeds, using configuration management. The emphasis of start-up will be on agreeing to the purpose of the project, the nature of the goals, if not their precise definition, and the life cycle and review points to be followed in reaching a better understanding. A facilitator may be used to help negotiate agreement on these. The role of the project manager is that of a sculptor, starting with a shapeless block of clay or marble. Somewhere in there is a statue. He or she will use standard techniques to cut away the clay or marble. However, they will need to avoid flaws, and so the precise nature of the statue will not be evident until it is finished. (I hope the sculptor is more like Michelangelo using an army of apprentices than a hermit in an attic.)
Type 4 Projects. Now neither the goals, nor the method of achieving them is known. The emphasis start-up is very much on agreeing to the purpose of the project. In the early stages of the project, the team works on defining first the goals (turning the project into a Type 2) and then the methods of achieving them. Planning will be by defining a series of gateways (review points) that the project must pass through before they close forever. A facilitator may again be used to negotiate agreement, and then help with team formation as the project converts to Type 2. The project manager must now take the role of an eagle. He or she must be able to hover above the project and see how it fits into the overall context of the organization, but also be able to identify small problems (a mouse) and go down and deal with them. They must then be able to rise back above the project again, before going down to deal with another mouse.
Scheduling Start-Up
A schedule of the start-up activities helps to focus attention on the process, and acts as a means of implementing the chosen techniques. The schedule may take the form of a responsibility chart (Fig. 12.1) with both a definition of roles and responsibilities, and a timescale. The schedule for starting-up design and appraisal may be included in the project definition report.
Project start-up workshops can be used to start a project, or a stage of the project. Indeed, mini workshops may be held to start a work package, by the rolling-wave principle. A workshop held at the start of the concept or feasibility stage is called a project definition workshop and at the start of design or execution stage an initiation or kick-off meeting.
Workshop Objectives
The main objectives of the workshop are
1. Gain commitment and build team spirit: This is the primary objective of a workshop. Many of the others can be achieved by people working alone or meeting in smaller groups. By coming together, they may develop a common understanding, and resolve items of confusion, disagreement, or conflict through discussion. If people are briefed after a meeting (presented with a fait accompli) they may nod their heads in agreement, but you often find they do not truly accept what they are told. If people agree to a course of action in a meeting, you usually find they have internalized that agreement, but if they have not, it is difficult for them to avoid their commitments later because several people have heard them make them.
2. Ratify earlier project definition: Whatever stage is being launched, it is vital for the team to agree what the current level of definition entails, and that it truly represents user requirements.
© 2008 Goal Directed Project Management Systems Ltd
FIGURE 12.1 Responsibility chart used as a start-up schedule.
3. Plan the current stage: The workshop is used to launch the current stage and so producing a plan for the stage is key. This should at least consist of a milestone plan and responsibility chart.
4. Prepare preliminary plans for execution: It is usually worthwhile to prepare a draft milestone plan for project execution, as this can be a useful basis for the feasibility study or design, even if the subsequent project follows a slightly different course.
5. Conduct a stakeholder analysis: It is always worthwhile to identify the project's stake-holders and conduct a stakeholder analysis. Remember you should gain agreement of all the stakeholders to the project's objectives before starting work.
6. Prepare preliminary estimates: This gives the project team some idea of the expectation of the cost and benefit of the project. Although their subsequent work should not be constrained by the estimates, it can help to set the basic parameters.
7. Access risk and develop risk reduction strategies: Preliminary risk analysis should be undertaken, and risk reduction strategies developed.
8. Start work promptly: The workshop should be used to plan the initial work of the current stage so that the team members can make a prompt start.
9. Agree a date for reviewing the stage deliverables: Ideally, the plan should contain a timescale and budget for the stage. An end date at least should be set for completion of the stage so it is not left open ended.
Apart from the first, these are the objectives of start-up given above, but at a more detailed level.
Workshop Attendees
The workshops should be attended by key managers, including:
The project sponsor
The manager of the current stage
The manager designate of future stages, especially execution
Key functional managers whose groups are impacted by the project, including technical managers, user managers, and resource providers
A project support office manager
A facilitator
The sponsor may attend the definition workshop, but not later ones. Possible attendees for a project definition workshop on the CRMO Rationalization Project are given in Table 12.4.
Workshop Agenda
A typical agenda for a workshop is
1. Review the current project definition
Purpose, scope, and outputs of the project
2. Define the objectives of the current stage
3. Determine the success criteria of the project and the current stage
Set a project mission
TABLE 12.4 Project Definition Workshop Attendees for the CRMO Rationalisation Project
| |
Role | Possible person |
| |
Sponsor | Regional managing director, or Regional operations director, or Regional financial director, or Regional technical director |
Manager of the feasibility study | Regional operations director, or Regional financial director, or Regional technical director |
Project manager designate | Customer services manager, or Network manager, or IT manager |
Key functional managers | Estates manager, and Finance manager, and Sales and marketing manager |
Project support office | May already exist, otherwise a temporary one may be created for this project |
| |
4. Prepare a milestone plan for the current stage
5. Prepare a responsibility chart against the plan
6. Estimate work content and durations for the work packages
7. Schedule the work packages
8. Define the quality objectives of the current stage
9. Assess risk and develop reduction strategies
10. Prepare initial activity plans
11. Prepare a management and control plan
Most effort goes into the milestone plan and responsibility chart, as that is the most effective use of group work. Sections 5.4 and 6.3 described how to develop them using whiteboards, flip charts, Post-its, and a data projector. Involving everyone present around a whiteboard, gains their commitment to the plans produced. Working around a table with pen and paper can isolate members of the team from the working process. Estimates and schedules are best agreed through a process of negotiation immediately after the workshop. The initial activity schedules are prepared so that the team members know what to do immediately following the meeting; it is an initiation meeting. The management and control plan agrees the approach to be used in managing the project and the mechanisms, priorities, and frequency of the control process. It may be the basis of the management approach outlined in the project manual (Sec. 12.3).
Workshop Timetable
A workshop typically lasts one to three days. I usually allow two hours per item, except items 4 for which I allow four hours. However, it is important not to stick rigidly to a timetable, but to allow discussion to come to a natural conclusion, as people reach agreement and a common understanding. I sometimes include project management training as part of the timetable, which extends the duration by about a day. I find it useful to schedule a break in the middle of agenda item 4. When developing a milestone plan, people often reach a blank; the plan will just not make sense. However, when left for a while, it just seems to fall into place.
12.3 PROJECT DEFINITION REPORT
AND MANUAL
Stage review reports gather the results from the work of one stage and are then used to launch the next stage. Three reports may be produced at the end of each of the first three stages of the project (Table 12.5). I describe the project definition report and project manual here. The project scope statement is described in Sec. 5.3. Table 12.5 also shows the names used for equivalent documents by the PRINCE2 process.4
Project Definition Report
Objectives of the Project Definition Report. The project definition report gathers the results of the feasibility study into a readily accessible document. It is a handbook for the management, design, and execution teams, which defines what the owner expects from the project, and the reasoning behind the chosen options and strategies. This reasoning can always be open to questioning. It is healthy that the teams involved in later stages question earlier decisions. However, by having earlier reasoning recorded, the project teams can avoid repeating work, and more importantly avoid following previous blind alleys. The project definition report will also be used to launch the design stage, and may be the input to a kick-off meeting at the start of that stage. Hence, the objectives of the project definition report are
To provide sufficient definition, including costs and benefits, to allow the business to commit resources to the design stage
To provide a basis for the design stage
To provide senior management with an overview of the project's priority alongside day-to-day operations and other projects, both proposed and on-going
To communicate the project's requirements throughout the business
To define the commitment of the business to the project
Most of these objectives look forward; the report is not produced as a bureaucratic exercise to record the feasibility study, but as a basis for the future stages.
Contents of the Project Definition Report. The suggested contents of the report are
1. Background: Sets the context of the project, describing the problem or opportunity which creates the need for the desired performance improvement. It may describe the purpose of the higher level program of which the project is a part (See Examples 2.3 and 2.6).
2. Purpose, scope, and objectives: The reason for undertaking the project with expected benefits, the sort of work needed to achieve that, and the product to be produced by the project in order to achieve the returns (See Table 5.1.).
| ||||
Report | Produced in | To launch | See | PRINCE2 names |
| ||||
Project scope statement | Concept | Feasibility | Project mandate | |
Project definition report | Feasibility | Design | App. A | Project brief |
Project manual | Design | Execution | Sec. 12.3 | Project initiation document |
| ||||
3. Success criteria and project mission: A statement of how the project will be judged to be successful, and what the project aims to achieve. This may include a statement of different stakeholders' aspirations (See Table 3.3).
4. Work breakdown structure: Initiates work breakdown, starting with areas of work, and including a milestone plan, with a list of milestones in each area of work. It may also include milestone scope statements (See Fig. 5.3 and Table 5.2 and 5.3).
5. Project organization: Defines the type of project organization, including:
Organizational units within the business involved in the project
Their involvement in different areas of work
Managerial responsibility for different areas of work
The type of project organization to be used
The location of project resources
The source of the project manager
Their source and limits of authority
and describes the responsibilities of key managers and groups in the business, including:
Project sponsor, champion, and manager
Work-area and work-package managers
Project steering board
Quality assurance board and project support office manager
It may be necessary to include a tentative resource schedule, so the project can be assigned priority. This schedule is derived from high-level assumptions applied to areas of work or work packages. It should not be based on a detailed definition of work except in areas of high risk because that requires an investment in planning resource before the business has agreed to commit it (Fig. 6.5).
6. Stakeholder register: Shows the stakeholders their personal expectations of the project, their influence on the project, and the planned communication strategy to win their support for the project (Table 4.3).
7. Quality plan: The milestone scope statements will show the measures of achievement of each milestone (Table 5.3).
8. Schedule: The bar chart or the responsibility chart shows the planned schedule for the project (Fig. 6.5).
9. Cost estimates: The cost estimate at the project level may be included showing the cost-breakdown milestone by milestone (See Fig. 8.4).
10. Risks register: The project definition report should include the risk register (Table 10.8) but not the individual risk item-tracking forms (Table 10.7). The latter will be included in the risk log.
11. Initial activity plans: Initial activity plans will be included for early milestones to show how work on the next stage of the project will begin. These may include cost estimates at the activity level (Fig. 8.5).
12. Project appraisal: Initial statements of cost and benefit and associated payback may be included. This will justify the commitment of resources to the design and appraisal stage.
13. Project management system: Tools and techniques for planning and controlling the project and supporting computer system may be described. This may include preliminary quality plans and control procedures.
The report is typically 10 to 40 pages long, depending on the size and complexity of the project, and its impact on the organization. It is developed throughout the feasibility stage. However, once ratified by senior management at the end of that stage, it should be sacrosanct, and only modified by formal change control. Appendix A contains the project definition report for the CRMO Rationalization project, incorporating the figures and tables introduced throughout the previous chapters into single document.
Project Manual
Objectives of the Project Manual. The results of the design stage are recorded in a project manual. This is a definitive document which explains how the owner's requirements set out in the project definition report are to be delivered by describing the objectives and scope and management strategy for the project as they are defined at the end of the stage. It is used as the briefing document for all people joining the project team during execution.
The manual is developed progressively by the project manager from the project definition report throughout the design stage. The draft manual is reviewed by the owner and project manager together, until it is signed off at the end of the stage as reflecting their mutual understanding of how the owner's requirements are to be delivered. When the manual is signed off, the project manager must accept responsibility for delivering the project as defined in the manual, and from that point on changes to the manual can only be made through strict change control. The development of the project manual and the master plan it includes often represents the largest proportion of the project manager's efforts during design after the management of the actual design process itself.
Through execution, the manual is extended down to the work-package level as part of the start-up of individual work packages. The manuals at the work package level must be derived from the project manual but they may highlight the need for modifying the project manual.
Contents of the Project Manual. The contents of the manual may include the following items:
1. Project description and objectives: These summarise the project definition report, as modified by the design process (Example 12.2).
2. Master project plan: This forms the major part of the manual. The design process results in this master plan. The contents of this plan, which cover the definition of scope, organization, quality, cost, and time in the project model are summarized in Table 1.5.
3. Management plan: This describes how the project is planned, organized, implemented, and controlled, although the first two only need to be done at lower levels of work breakdown.
4. Performance specification: This defines the required levels of performance of the facility and its product. This is one of the major elements of the quality specification of the project and would have been developed and refined during the design process.
5. Functional specification: This explains the technology to be used in the development of the facility, and how that will function to deliver the required output.
6. Acceptance tests and acceptance criteria: These are derived from the previous two and are an important part of the manual. They must be defined before work starts for two reasons. They must be independent. The project team members must not be allowed to develop testing procedures which match the facility built. Secondly, the project team must know how they are to be judged, if they are to deliver a quality product. In Chap. 8, quality was defined as meeting customer's requirements. These must be defined in advance so the team members know what their objective is, and they do not produce a product which is either over- or underspecified.
7. Project constraints: These are derived throughout the first three stages, and so must be recorded for all people joining the project at a later date.
8. Risks and assumptions: These must also be recorded for two reasons. So people joining the project later know what has been addressed, and so others, especially owners, sponsors, financiers, and auditors can see they have been properly addressed and that adequate weight has been given to them.
Example 12.2 Summarising the project definition report in the project manual
I had a discussion with managers attending a course at Henley Management College about whether the manual would contain the definition report in its entirety, or whether it would be summarised into a single section as a background. We decided on the latter for two reasons. First, it is the job of management to summarise the instructions from the level above when passing them on to the level below, so the next level down can focus on those things which enable them to do their jobs effectively. You inform people on the next level on a need-to-know basis. This does not mean you need to be excessively secretive. You tell the next level enough to motivate them, and make them feel part of the overall management team, without overburdening them with unnecessary information. Secondly, taken to the extreme, you would include the entire corporate plans in the briefing documents to every project.
1. There are four stages of team formation:
Forming
Storming
Norming
Performing
2. Project Start-up is a structured way to moving the project team quickly and effectively through these four stages, so as to:
Define the project's context and objectives
Develop the project model
Define the management approach
Commission the facility and hand it over
3. The methods of project start-up include
Stage launch workshops
Start-up reports
Ad-hoc assistance
4. A stage launch workshop may be held with the objectives:
To gain commitment and build the team spirit
To ratify the project definition as produced in the previous stage
To plan the current stage of the project
To prepare preliminary plans for the execution stage
To prepare preliminary estimates for the project
To ensure work starts promptly
To agree a date for review of the stage deliverables
5. A project definition report may be prepared with the objectives:
To commit resources to design
To provide a basis for design
To inform all those effected by the project
To gain commitment
6. The contents of the report may include
Background
Purpose, scope, and objectives
Project success and mission
Work breakdown structure
Project organization
Stakeholder register
Quality plan
Cost estimates
Schedule
Risk register
Initial activity plans
Project appraisal
Project management system
7. The systems design produced during the design and appraisal stage may be summarized in a project manual, which may have as its contents:
Project description and objectives
Master project plan
Management plan
Performance specification
Technical specification
Acceptance tests and criteria for acceptance
Project constraints
Risks and assumptions
1. Tuckman, B.W., "Development sequence in small groups," Psychology Bulletin, 1965.
2. Fangel, M., "The essence of project start-up: The concept, timing, results, methods, schedule and application," in the Handbook of Project Start-up: How to Launch Projects Effectively, Fangel, M. (ed.), Zurich: International Project Management Association, 1987.
3. Fangel, M., "To start or to start-up?—That is the key question of project initiation," International Journal of Project Management, 9 (1), 1991.
4. Office of Government Commerce, Managing Successful Projects with PRINCE2, 4th ed., London: The Stationery Office, 2005.