Definition process

General

This process manages the definition phase of the project or programme life cycle. Its goals are to:

• develop a more detailed picture of the project or programme;
• determine whether the work is justified;
• create governance policies that describe how the work will be managed;
• gain the sponsor’s authorisation for the delivery phase.

An authorised brief and definition plan will trigger the process, which is fundamentally the same regardless of whether it has been decided to govern the work as a project or a programme. The output will be a set of documents that describe all aspects of the work, with their content and detail varying to suit the context.

 

Click on the components of the diagram for more detail

 

The definition process will plan the management and delivery of the work. A summary of the plans is then presented to the sponsor to gain authorisation for the delivery phase. Although the formal request for authorisation is shown at the end of the process, the manager and sponsor should be in regular communication throughout.

When the formal request for authorisation is eventually made, the sponsor should have a good idea of what is being proposed. This is particularly important where some pre-authorisation work may be needed with the agreement of the sponsor.

Planning how the work will be managed involves the development of policies and procedures for all the relevant functions that will be used. What constitutes a ‘relevant function’ is dependent upon the context of the work.

Planning how the work will be delivered requires the definition team to be competent in all the relevant functions. The resulting delivery documents define the project or programme and how it will be performed. Once authorised they will be baselined to provide a starting point for monitoring and controlling progress.

Thamhain and Wilemon identified that this phase of the life cycle is where conflict is typically at its highest level. If this is combined with the fact that the team is still coming together and probably in Tuckman’s ‘storming’ stage then it is clear that the project or programme manager must be very sensitive to conflict and have good leadership, conflict management and influencing skills.

A well-executed definition process sets the foundation for a successful delivery process.

 

Appoint definition team

On smaller projects the identification team may have sufficient expertise and capacity to continue and carry out the full definition. On larger projects and programmes it is likely that the identification team will need to be supplemented to provide sufficient resource with the necessary capabilities. A construction project may need to recruit additional specialists such as structural engineers or mechanical and electrical (M&E) engineers; an IT or business change programme may need to recruit additional business analysts or system architects.

Such technical roles are focused on defining the scope of the work and they will be less involved in the delivery phase of the project or programme. Preparing the management plans, high level scope documents and initial delivery documents is usually done by roles that will go on to form the team that manages the delivery phase.

 

Back to diagram

 

Define scope

The procedures described in the scope management function will be used to capture stakeholder requirements, develop solutions and define benefits as appropriate. The scope of some projects will only encompass outputs while others will encompass benefits. The scope of programmes will encompass benefits and often significant business change required to achieve them.

Documents that are appropriate to the project or programme could include:

• Specifications
• Blueprint
• Benefits profiles
• Vision statement
• Product breakdown structures
• Work breakdown structures

The range of scope documents and the detail they contain will also be influenced by the chosen life cycle. Typically in a serial life cycle, the objectives (outputs or benefits) will be defined in greater detail at this stage than in a parallel life cycle. Parallel approaches (such as agile) will continually develop scope throughout the life cycle so the initial definition will be high level and flexible.

 

Back to diagram

Pre-authorisation work

The conclusion of all planning work before any mobilisation or commencement of any delivery work is often impractical. Specialist materials or equipment may be required that are subject to long lead times; procurement of suppliers through competitive tender may need to start early; applying for statutory or regulatory approvals can be time consuming.

In parallel with planning, the management team should identify any necessary pre-authorisation work that should be done before it is fully defined or authorised. The advantage of placing provisional orders for materials or initiating a tendering process must be weighed against the risk that the next stage or tranche is not authorised.

The performance of pre-authorisation work should be planned and agreed with the sponsor. The completion of this work must be reflected in the plans but the fact that pre-authorisation work has been completed should not be an influencing factor in judging the viability of the business case when the request for authorisation is made.

 

Back to diagram

 

Prepare governance documents

Governance documentation includes internally produced management plans and any relevant external policy documents. Management plans can be written for many functions and every functional procedure starts with a step called ‘plan’. Some, such as a stakeholder management plan or a risk management plan are universal, since the need to manage stakeholders and risk applies to all projects and programmes. Others, such as a benefits management plan or procurement management plan are relevant only if the scope of work covers delivery of benefits or external suppliers are used.

Based on the scope of the work, the definition team will decide which functions need a management plan. In more mature organisations there will be standard management plans that can be adapted to the specific context of the work. In less mature organisations management plans tend to be re-created for each new project or programme.

Management plans should not be prepared in isolation. Each one will be influenced by the delivery documents and other management plans. For example, if the stakeholder map identifies potential opposition to the work, the risk management plan must ensure this type of risk is adequately managed.

 

Back to diagram

 

Plan delivery

The content and extent of this activity are unique to each project or programme. Various planning documents will address different aspects. Typical examples include:

• Scheduling documents, e.g. activity networks, Gantt charts, milestone plans.
• Risk documents, e.g. risk register, risk response plans, Monte Carlo analysis.
• Stakeholder documents, e.g. stakeholder register, stakeholder map, communications plan.
• Resource documents, e.g. tendering documents, supplier specifications, contracts, service level agreements.
• Financial documents, e.g. investment appraisals, cost estimates, budgets, cash flows.

Although these tools and techniques are listed separately, they all interact. It will not be possible to prepare each one in turn. The process will be iterative with for example, the first draft stakeholder map providing information for the first draft of the risk register which, in turn may affect the initial investment appraisal.

It is not usually necessary, or even desirable, to plan the whole project or programme in detail. In a project, the first stage will be planned in detail but the remainder of the work will be planned at a higher level. In a programme, the plans for the first tranche will be in greater detail than the rest of the work. This is referred to as rolling wave planning. The delivery documentation will therefore be in two parts, the overall delivery plans and the detailed delivery plans for the first stage or tranche.

Once the project or programme has been authorised these documents will be ‘baselined’. During the delivery phase, progress will be monitored and compared with the baseline documents.

 

Back to diagram

 

Consolidate definition documentation

At the end of the definition process, a request for authorisation will be submitted to the project or programme sponsor. The decision whether or not to proceed to the delivery phase will be made after a review of the relevant documentation. If authorisation is given the next step is to mobilise the first stage or tranche of the delivery phase. If authorisation is declined a minimal version of the closure process will be performed to demobilise the definition team and archive information.

Although the nature of what is submitted for approval will vary according to the context, it is common to provide three documents:

• Project or programme management plan

• This document summarises or brings together all the management plans for the project or programme. It may be a single, self-contained document with a section for each relevant function or a collection of separate management plans.

  In a mature organisation that has standard management plans in use across its portfolio of projects and programmes, it will only be necessary for the overall management plan to cross reference these and highlight the adaptations made for the context of the current work. A sponsor who is familiar with these organisational standards will only need to consider the adaptations to be reassured that the work has the necessary governance in place.

• Business case

• The business case explains the justification for the work. It will summarise the scope and balance this against the cost and risk required to achieve it. In doing so it will cross reference more detailed delivery and content documents such as the specification, budgets, the risk register and so on.

• Project or programme delivery plan

• The delivery plan shows how the objectives will be achieved. It summarises the delivery documents and will include an overall timescale, resource requirements, cash flow and organisational structures. This plan may cover all the work to be done or it may cross reference more detailed plans for stages, tranches or functional areas, such as communication, risk or quality.

 

Back to diagram

Mobilise

Once the authorisation is received the project or programme can be mobilised. This puts in place all the equipment, facilities and other resources that are required to deliver the objectives.

 

Back to diagram

 

Projects and programmes

On small projects the definition activities may be managed and performed by the project manager but the combination of a separate sponsor and manager is the minimum requirement. It may also be possible to combine the identification and definition phases into a single process.

This process creates a lot of documentation. Too much is just as damaging to the potential success of the work as too little. The documentation section of Praxis should not be seen as the set of documents that need to be produced. Rather it is the range of documents that can be used. Deciding on the particular set that best suits the scale and complexity of each project or programme is an important part of this process.

An important element of this is deciding what constitutes relevant documentation for the purpose of requesting authorisation. In small projects the documentation may be distilled into key points in a presentation to the sponsor. On large projects or programmes the governance and delivery documents may be summarised and provided to the sponsor for consideration with the detailed documents being available for inspection as required.

In some contexts, the definition process may be performed by a client organisation. The definition documentation may be given to a contractor organisation that plans the delivery. The definition process is then split between the client side of the project and the contractor side of the project.

In larger programmes the definition process may be a small project in its own right. It can be run as a project with the programme definition documentation and delivery plan as the outputs of the project. All aspects of the process model are scalable and smaller versions may be nested inside larger ones.

 

Back to top