• No results found

SELECT THE PROJECT APPROACH AND ASSEMBLE THE PROJECT BRIEF

In document The Prince2 - Pactitioner (Page 143-147)

Starting up a Project (SU)

CARTOON 2 Project mandate

10.5 SELECT THE PROJECT APPROACH AND ASSEMBLE THE PROJECT BRIEF

10.5.1 Responsibility Project Manager.

10.5.2 What does the activity do? Project Brief:

• Identifies all stakeholders; i.e. those with an interest in the project. Ensures their views are known on the information in the following bullet points;

• Confirms project objectives and desired outcomes; • Confirms project scope (including any exclusions);

• Identifies any interfaces required of the project’s products; • Identifies project tolerances from programme or corporate

management. Project approach:

• Identifies the operational environment in which the solution must work when delivered;

• Decides on what kind of a solution (project approach) will be provided to fit into that environment to achieve the points made in the outline Business Case and the general method used to provide that solution;

• Identifies the skills required to implement the project approach; • Identifies any timing implications of the project approach. The main project approaches to be considered are:

• Build a solution from scratch;

• Take an existing product and modify it;

• Give the job to another organization to do for you; • Buy a ready-made solution ‘off the shelf’.

Finally, assemble the Project Brief. 10.5.3 Why?

The project approach will affect the timescale and costs of the project, plus possibly its control over scope and quality. This information should be made available to the Project Board in deciding whether to initiate the project.

A check should be made that the proposed project approach is in line with the customer/programme’s strategy.

The Project Brief is the basis for the Project Board decision on whether to authorize initiation.

10.5.4 How?

• Identify any time, money, resource, operational support or later product extension constraints.

• Check for any direction or guidance on the project approach from earlier documents, such as the project mandate.

• Identify any security constraints.

• Check for any corporate or programme statement of direction which might constrain the choice of project approaches.

• Consider how the product might be brought into use and whether there are any problems which would impact the choice of project approach.

• Check the Lessons Log, current industry thinking and any new techniques or tools available for help with the project approach. • Produce a range of alternative project approaches.

• Identify the training needs of the alternatives.

• Consider how the product might be brought into use and whether there are any problems which would impact the choice of project approach.

• Compare the alternatives against the gathered information and constraints.

• Prepare a recommendation.

• Compare the information available about the required project against the information required by the Project Board to approve project initiation.

• Gather any missing information. • Incorporate the outline Business Case. • Incorporate the Project Product Description. • Incorporate the project approach.

• Incorporate the project management team structure and role descriptions (or point to where these can be found).

• Record any new risks or issues in the Daily Log. 10.5.5 Information needs

10.5.6 In practice

Be careful about how you go about this. Although the activity title suggests that you can sort out the project approach before doing the Project Brief, you need to do it the other way round. The Project Brief contains the objectives, scope, constraints, and you can’t say how you will approach the provision of a solution before you know what the problem and objectives are.

The customer needs to think very carefully about the project approach. Preparation of the above information can avoid the customer being pushed into a project approach which is favoured by a supplier, but later turns out to have problems for the customer, such as lack of flexibility or maintenance difficulties.

Example

The Swiss branch of a multinational was regularly falling many weeks behind centrally imposed cutover dates to new versions of a system used by branches in all countries. I was asked to look into the situation.

TABLE 10.5

Management Usage Explanation information

Corporate statement Input Provides any constraints on the project

of direction approach.

Project tolerances Input Set by corporate or programme management.

Project Product Input Forms part of the Project Brief. Description

Outline Business Input Forms part of the Project Brief. Case

Project management Input Forms part of the Project Brief. team

Project Brief Output Summarizes the objectives of the project. Project approach Output Defines how the solution will be

I discovered that, as the system didn’t quite fit the local docu - mentation needs of the Swiss branch, instead of adopting its manual procedures, the Swiss branch had accepted an offer from a local software house to modify the system in order to produce the required documentation. This was fine, but later the company realized that the software house had to be called in every time an update to the system was issued by headquarters. Eventually they realized that the changes were taking so long to do that their system was many weeks behind each centrally imposed cutover time. When I checked into the reasons why each update was taking longer, I found that, apart from the increasing complexity of modifying the already modified software, the software house now had only one programmer who understood the system, and she was six months pregnant and about to start her maternity leave! In your case, there may have been an earlier feasibility study that looked at a number of different approaches for achieving the end objective and selected one that could be the basis for your project. If the project is part of a programme, a Project Brief may have already been provided, thus rendering this process unnecessary.

The Project Manager should informally check out the Project Brief with Project Board members to ensure there are no problems before formal presentation.

10.5.7 For small projects

There may be pressure on the Project Manager to ‘get on with the job’ and start with incomplete terms of reference. This should be resisted as it opens up the possibility of disagreement later on what the project was supposed to do (its scope). The Project Manager also needs to know how much the solution is worth in order to make appropriate judgements if changes occur later.

10.6 PLAN THE INITIATION STAGE

In document The Prince2 - Pactitioner (Page 143-147)