Project initiation is where all the necessary analysis is undertaken to allow the project to be planned. Initiating a project usually involves a considerable amount of work, and therefore expenditure, and this is why PRINCE2 recommends that project initiation be considered as a stage in its own right ie it should be formally given approval to go ahead and should be planned and budgeted for as a phase of the project.
The single most important piece of documentation you will produce at this stage, and probably during the course of the entire project, is a project initiation document (PID).
The project initiation document takes as its starting point the business case, if one exists, and builds upon it using the information and analysis data produced during the initiation activities.
The PID may also be called a project scoping document, project outline, project management plan or sometimes even a project brief.
This will tell you what you need to know to plan and resource the project. Remember projects don’t usually fail at the end – they fail at the beginning!
It will look in detail at risks and a plan to deal with them will be one of the outputs of the initiation.
During this period a thorough analysis must be taken and recorded of how any business processes, that the project will affect, are structured, staffed, and run. Measurements should be taken at this point that will be key or critical success factors of the project eg if the project aims to increase the rate of data entry of forms to a computerised system then a comparison cannot be made at the end of the project if initial measurements during the old business process do not exist.
A PID should include:
- Details of project goals and objectives and the critical success factors by which achievement of the objectives will be judged
- Details of the project scope in relation to the organisation, functional areas and time as well as a statement about any related areas that are considered to be out of scope
- Details of identified risks and any constraints affecting the project
- Details of any assumptions made about the project - these might be assumptions that you as the project manager are making about what support you will receive from other parts of the institution or, if you are working with a third party supplier, assumptions about what the supplier will deliver
Let’s look at a few examples of assumptions that could trip you up unless they are stated and agreed:
- You are implementing a piece of software and you assume it is someone else’s job to specify, procure and install the necessary hardware before you start the project.
- You have drawn up your project plan on the basis that you will have a full team in place from day one although the team isn’t yet recruited.
- You are assuming that the project team has the authority to change administrative processes in user departments to ensure the effective working of a new system and/or you are assuming that somebody will actually implement those changes to working practice.
- The assumptions you make about third party involvement are best resolved as part of drawing up a contract with them (in other words there should be a formal definition of responsibilities). It may however be worth stating here that you assume they will provide goods/resources of the stated quality at the stated times otherwise there will be an impact on your plan.
- Details of the project’s organisation structure and roles and responsibilities within the team.