This process manages the definition phase of the project or programme life cycle. Its goals are to:
- develop a detailed picture of the project or programme;
- determine whether the work is justified;
- describe governance approaches for how the work will be managed;
- update delivery plans and disseminate to stakeholders.
The first three goals of this process relate to the first time it is performed and are triggered by the authorisation of the charter. The governance approaches will be described in a series of management plans.
Once the work is underway, approved changes to the delivery baseline invoke this process to update the delivery plans in accordance with the fourth goal
This process builds on the charter to provide much more detailed delivery plans for the project or programme. This will impact the business case which will, as a result, be more detailed and rigorous. The sponsor should have a further opportunity to review the business case and associated plans at the end of this process. If approved, this will trigger the delivery phase, which is managed through the delivery processes: direct work, control work and control changes.
The approved documentation constitutes the baseline plans for the project or programme.
What actually constitutes a ‘change’ is discussed in the control changes process.
As change requests are submitted to the control changes process, those that are approved will result in changes to the baselines. This develop plans process is also used to update the baseline plans and communicate the changes to relevant stakeholders. The revised plans are then inputs to the three implementing and controlling processes.
An approved charter gives the project manager the authority to proceed with the develop plans process. The elements of the charter will be used as a starting point to develop the more detailed management and delivery plans in this process.
- Lessons learned
Lessons learned should be collected and recorded for all projects and programmes. This process should examine the lessons learned records for any lessons that could apply to the current project or programme.
Each project or programme should maintain a lessons log and it is useful to create that document and initially populate it with relevant lessons from the knowledgebase.
Of course, there is no point in taking note of these lessons unless they are used to inform the plans for the current work.
- Business case
It is useful to think of the business case that is an input to develop charter as the ‘initial’ business case. In the charter that is upgraded to an ‘outline’ business case and the aim of this process is then to produce a ‘full’ business case.
- Approved changes
In keeping with the ISO21500 approach, this process it not exclusively used to manage the definition phase of the life cycle. Approved changes are also an input which will lead to updates of the delivery plans and, on rare occasions, the management plans.
The develop plans process co-ordinates activity in many functions in order to produce sufficiently detailed management plans and delivery plans for the project or programme delivery to be approved. It utilises particular steps from the functional procedures as shown in the diagram below.
Click here to see how the Praxis functions map to the detailed ISO21500 processes.
The initiate step establishes the infrastructure and procures the resources that are needed to perform the activities required by the management plans. But it has to be borne in mind that this detailed planning may reveal that the project or programme cannot be justified – in other words, the business case doesn’t work.
Therefore, money spent on initiating the structures needed to implement the management plans may be wasted. The only function that definitely includes the initiation step is organisation management, since an organisation is needed to actually do the planning.
Based on local circumstances, the project or programme manager will need to assess how much risk is involved in putting infrastructure in place before final approval is given.
Click on the diagram below to see more information about each function
- Organisation management
In order to perform this process, the project manager will need to build a definition team with the requisite skills to deliver the required outputs.
- Schedule management
As well as developing a schedule management plan, this function will take the summary schedule from the charter and build a full schedule. This doesn’t mean that every detail is scheduled through to the end of the work.
In projects, rolling wave planning may be used and in programmes, only the first tranche needs be scheduled in any detail – and even then perhaps only the earliest projects.
It is unlikely that the summary schedule in the charter took any great account of resource limitations and these now need to be considered,
The develop plans process will consider the outputs of all the other functions to ensure the schedule takes account of risks, stakeholder inputs and so on.
- Stakeholder management
Some stakeholder management will have commenced during the develop charter process. In addition to developing the stakeholder management plan, the definition team must now extend the stakeholder register to ensure that all stakeholders have been identified, and that their interests and influence have been assessed.
- Scope management
Everything else in this process depends upon the scope, i.e. what the project or programme is required to achieve. This governs who is affected, what resources are needed, what funding is required and what risk there might be.
The scope management plan will describe how the scope is to be managed, for example, how requirements will be captured, how quality of outputs will be controlled and how deliverables will be accepted.
- Resource management
Some projects and programmes may be performed entirely by in-house staff. Others will be entirely contracted out through formal procurement processes. Either way, the resource management plan must clearly state how resources will be procured and mobilised.
Some early tendering may be conducted to obtain better cost estimates or build short lists of suppliers.
- Change management
If the scope of the work includes benefits, then it is likely that this will involve change management (as distinct from change control) to ensure that new practices are embedded in the organisation and benefits are realised.
The change management plan will describe how people will be prepared for and engaged in the change process.
- Financial management
Initially, this function will contribute investment appraisals to the business case. It will also identify the funding required and the sources from which that funding may be obtained.
The finance management plan will indicate how income and expenditure will be tracked and controlled throughout the delivery of the project or programme.
- Risk management
This function will identify risks within all the other functions. The develop plans process will ensure that the consequences of risk are accounted for in the schedules and budgets.
- The risk management plan will describe how the host-organisation’s attitude to, and appetite for, risk will be taken into account when managing the project or programme.
- Management plans
Governance documentation includes internally produced management plans and any relevant external policy documents. 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.
In Praxis the independent creation of management plans by projects and programmes is an attribute of level 2 capability.
The creation of centrally controlled management plans that are adapted for the context of each project and programme is an attribute of level 3 capability.
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.
- Delivery plans
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. 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.
- Request for authorisation
- ISO21500 does not explicitly require further authorisation of the management and delivery plans from the sponsor. However, the fact that all the detailed planning will result in a new and detailed business case, makes it very clear that further authorisation is necessary to confirm that the business case is still justifiable, achievable and viable.
- Back to develop plans process diagram
Projects and programmes
On small projects the develop plans process may be managed and entirely 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 (i.e. the develop charter and develop plans processes) 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.
A key 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 develop plans process may be performed by a client organisation. The 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 plans as the outputs of the project. All aspects of the process model are scalable and smaller versions may be nested inside larger ones.