Planning the Project Initiation Document (Photo: Envato)

Use this easy-to-follow step-by-step guide to producing a Project Initiation Document to increase the chances of your project running to plan, on time, within budget, and delivering the product to the right quality.

A Project Initiation Document, or PID, is integral to effective project management planning and is key to the success of any project. It is completed at the project initiation stage.

The PID is a vital component of the PRINCE2 methodology (PRojects IN Controlled Environments), a widely recognised process-based project management method.

Several project management frameworks exist with slightly different approaches to the PID documentation. Increase the likelihood that your projects run to plan, on time, and within budget with this step-by-step PID guide, featuring common elements and best practices found in different project management frameworks.

What is a Project Initiation Document (PID)?

A Project Initiation Document is a powerful project management planning tool. It can be one document, or a set of documents, used by project managers to define a project’s:

  • scope,
  • objectives,
  • business case,
  • risk,
  • team,
  • deliverables,
  • parameters,
  • and outcome measurements.

Your project approach provides a solid starting point from which the project manager and project board can assess and monitor performance during the project lifecycle.

What is the purpose of a Project Initiation Document (PID)?

The ultimate purpose for Project Initiation Documentation is to get funding approval for projects from the project board. The PID establishes a clear way forward and measures project delivery progress and success. It also provides one point of reference where people can find vital information about the project.

Why is Project Initiation Documentation (PID) necessary?

Quite simply, the best ideas cannot come to fruition without proper project management planning. Project Initiation Documents are an essential starting point and can mean the ultimate success or failure of a project. The Project Initiation Documents sets the parameters, context, and expected outcomes from each team member.

What are the benefits of a Project Initiation Document (PID)?

Project Initiation Documentation provides the following benefits:

  • Projects run according to a plan, on time, and within budget
  • Everyone understands the objectives and their role in achieving those objectives
  • You’re able to manage risk and can monitor progress regularly
  • It provides a baseline against which the project can be monitored and controlled

Compiling a Project Initiation Document (PID)

Follow this comprehensive Project Initiation Document template for your project planning:

1. Scope and objectives

Much like a Project Charter, this section of the PID is a broad introduction that defines the project scope, objectives, and participants’ key roles. Information in this document should outline the following:

  • The project brief – Note, in PRINCE2, this is a separate document to the PID.
  • The project definition
  • What problem you are solving
  • The purpose of the project – what you want to accomplish
  • The project objectives – How will you achieve the project purpose. Use SMART goals, which means they should be Specific, Measurable, Attainable, Relevant, and Time-based.
  • The project deliverables – the project results. Include timings for each deliverable so that you can monitor each milestone.
  • Constraints – the influences which may affect your deliverables and outcomes
  • Assumptions – The assumptions you are making that may affect the project outcome. Include how you will manage these assumptions.

2.Specifics and approach

Stipulating the specifics and approach is an integral part of resource planning and creating timelines. What project management method will be adopted? Everyone in your project team should understand what is expected from them to achieve deliverables and ensure a successful outcome. The project specifics and approach bring you closer to achieving your goals by breaking down and allocating the tasks required for each team member to complete. It is imperative to take the team through this planning to fully understand what is expected from them, when expected and how they should do the job. This will ensure the project team’s buy-in and gives them accountability.

The project approach in PRINCE2 is specifically about how the project will deliver the product. So, for example, in-house or through third parties, will it be an off the shelf product or bespoke.

3. Business case

The business case document justifies the project and shows how it supports the broader strategic business goals of the company. It should provide information that explains the reasons for the project and the impact it will have on the business. A business case should answer the following:

  • The benefits of the project and how these benefits will be measured.
  • Other options considered when developing the project management plan – including the do-nothing option.
  • The possible risks and how these will be overcome.
  • A breakdown of costs.
  • A detailed timeline for each job to be completed.
  • An analysis of costs versus expected return on investment.

4. Role descriptions

The role descriptions section of the document explains how the project will be executed and managed. It provides information around the key roles and responsibilities of each project team member and the reporting structure. This ensures no functions are duplicated and sets out clear parameters and expectations from each member of staff. This section should include:

Organisation Breakdown Structure (OBS):- The OBS diagram illustrates the reporting structure and where each team member fits into this structure.

Project sponsor: – The project sponsor is the head authority designated to the project.

Project manager: The project manager manages and is responsible for the overall project.

Project team: A list of project team members’ names, job descriptions, the department they are from, and what role they will fulfil within the project. This list should include their contact details (email address and phone number) and reporting lines.

Outlining role descriptions in the Project Initiation Documentation will avoid any potential misunderstandings. It will establish the project process for consultation and the time required at each sign off stage.

RACI chart

An effective way of clarifying roles and responsibilities is through a RACI chart, which outlines who is:

  • Responsible (who performs the actual task)
  • Accountable (who makes the decisions)
  • Consulted (who needs to weigh in)
  • Informed (who needs to updated)

This can be completed by mapping out each project task and allocating the roles and responsibilities next to each task.

The RACI acronym stands for Responsible, Accountable, Consulted and Informed. RACI charts are an effective method of identifying roles and responsibilities within a project. (Image: Wikimedia)
The RACI acronym stands for Responsible, Accountable, Consulted and Informed. RACI charts are an effective method of identifying roles and responsibilities within a project. (Image: Wikimedia)

5. Risk analysis

A risk analysis document is a risk log that identifies potential project issues, dependencies, and assumptions, such as budget constraints, unknown factors, or timing issues. It sets out a specific project management plan on how to address these risks, should they arise. A risk analysis should provide the following information:

  • Identifying the risks within the project
  • Explaining how you plan to prevent or manage the identified risks
  • Outlining the contingency plan for dealing with those risk you cannot prevent should they arise
  • How you will routinely monitor the processes put in place to assess the project risks continually

With PRINCE2 specifically, there is no Risk Register contained within the PID. In PRINCE2, the PID should explain how risks will be managed and reference a separate Risk Register document.

6. Implementation

The project implementation section of the Project Initiation Document broadly defines how the project will be implemented and outlines the project rollout plan by detailing the timelines, resources, and management stages. – for me, this would all be covered in the project plans below – Further planning documents to provide more information are often required to support this stage.

7. Project plan

The initial project plan document is the crux of the Project Initiation Document. It analyses the resources available to the project and provides detailed information about the schedule and budget. It also provides a timeline to measure project development and progress. An initial project plan includes the following:

  • Assignments – What the milestones are for the project.
  • Schedule – A report of the estimated time involved to complete the project, which you can pull from a high-level Gantt chart or similar project management software tool.
  • Human resources – The staff allocation needed for the project
  • Project control – how project progress will be monitored and communicated to stakeholders.
  • Quality management – what the quality assurance and checking processes will be for each deliverable. Some businesses have existing corporate governance, which you will need to follow to ensure quality management.

8. Controls

The project controls in PID stipulate the rules put in place to ensure you have identified potential project constraints, such as remaining within budget and on schedule. Measurement and reporting on project progress should be completed regularly to confirm that the project conforms to the project controls. – the project controls section would set out the Project Boards controls that they want in place so they have overall control but can delegate day to day management to the PM. So, for example – communication between the PB and PM, the number of stages, how tolerances will be used, how issues and exceptions will be escalated.

9. Change control approach

However well considered your project controls, changes can happen during a project. It would help to be well-prepared for handling any changes required, or they can completely derail the project. This is why change control needs to be managed. The change control approach stipulates the project tolerance for any deviation and sets out an exception process should you want to put exceptions forward. This document sets out clear policies and procedures for change.

10. Communication plan

This document sets out the project communication plan and details when stakeholders will receive project updates and in what format they’ll receive them.

Project Initiation Document checklist

The PID checklist is a helpful project management tool to ensure you’ve created a quality PID. The checklist should answer and verify the following questions:

  • Is the project scope achievable?
  • Does the project support the strategic business goals?
  • Have optimal human resources been allocated with all roles considered?
  • Have control and reporting structures been stipulated?
  • Have appropriate timelines and budget been given?

Project Initiation Documentation approval and sign off

Once you have completed the above documents and you are happy with the PID, it’s time to get approval from stakeholders and the project board. The approval process should include:

  • Emailing the PID to all project management team members and stakeholders and asking for their review and comments
  • Revising the PID to incorporate these comments and changes
  • Meeting with all project management team members and stakeholders to go through the revised version and to discuss the PID in detail
  • Making further changes and then presenting the final PID to the project board for approval

There could be several reviews during the approval process, depending on the size and complexity of the project.

Share the PID

The best project management plan means nothing if you don’t share the document information with the broader project team. Following the stipulated guidelines and procedures and implementing the project according to your plan will decide a successful outcome or not. Use the Project Initiation Document regularly for check-ins and monitor progress to ensure the project is on track.

Project Initiation Document review

Throughout the project, it’s essential to continually assess the Project Initiation Document through a combination of formal and informal review sessions. Informal reviews can be conducted monthly and formal reviews at the end of each quarter, depending on the project’s complexity. How often these take place can be up to you. What’s important is that regular reviews are held to identify potential problems as soon as they arise.

Update the PID

Project Initiation Documents are living documents, which means they should be reviewed and updated regularly. Any updates required are completed at the end of each stage, explaining why and by whom.

Elite are experts in project management training. We train project management practitioners worldwide, and in 2020 Elite was awarded Sole Supplier status to the Scottish Government for Project and Programme Management learning. Do you want to upskill or refresh your project management knowledge? Browse our course portfolio. Alternatively, if you’d rather speak to a training consultant, call us on 0141 222 2227.

Next up

A Primer on the Daily Standup Meeting and it's Future

If you work in an 'Agile' organisation, you'll be no stranger to the daily standup meeting or daily scrum meeting. You might call it the daily standup, daily Scrum, daily huddle or morning roll-call; regardless, the purpose is to get the team aligned and on the same page for that day.

Depending on experience, you might foster some scepticism about the effectiveness of this daily meeting. Reflecting on the unprecedented changes to global working practices in the last year highlights the potential for a conversation around improving the daily standup in the context of remote working and distributed teams.

The origins of rugby within the scrum process

[caption id="attachment_3844" align="aligncenter" width="700"]The Haka ceremony being performed by the All Blacks rugby team (Photo: Shutterstock) The Haka ceremony being performed by the All Blacks rugby team (Photo: Shutterstock)[/caption]

Jeff Sutherland, the co-creator of Scrum, first explored his rugby inspired process at the Easel Corporation. Japanese academics Hirotaka Takeuchi and Ikujiro Nonaka had already referenced rugby in their famous Harvard Business Review article "The New New Product Development Game", published in 1986. Sutherland continued the rugby theme and referenced the All Blacks rugby team's Haka ritual when attempting to inspire his first scrum team in 1993. Sutherland wanted to motivate his colleagues with the energy and passion displayed when the New Zealand rugby players performed the Maori warrior dance. Sutherland also wanted to explore how you transfer the traits of the worlds best rugby team and instil them within a group of software developers.

The antecedent of the daily stand up

Sutherland's team began researching how elite business teams achieved goals. One paper written by James O Coplien was particularly significant. Coplien's report examined software craftsmanship at the Borland Corporation, specifically the Quattro Pro project for Windows project. The discovery that a team of eight had produced one million lines of code in 31 months was record-breaking. Key to the Borland teams rapid development were daily meetings; problems highlighted by team members were swarmed by the group until fixed.

Sutherland admired the approach but believed the hour-long daily meetings adopted by Borland staff were too long. Observing the key elements needing communicating during the huddle, Sutherland devised three questions and a set of rules.

The birth of the Scrum framework

Jeff Sutherland would find a kindred spirit in software developer and consultant Ken Schwaber. In 1995 they unveiled their formal Scrum framework to the world at the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) Conference in Austin, Texas.

Today, companies and organisations adhering to agile frameworks incorporate a daily scrum meeting or daily stand up into the working day.

What is the point of a daily scrum meeting?

If you are a Scrum practitioner, then the purpose of a Daily Scrum meeting is to monitor progress towards the Scrum teams Sprint Goal and modify the Sprint Backlog, reflecting any changes regarding unplanned tasks.

In more general Agile terms, you conduct a daily stand up so that team members can synchronise and gain visibility on progress towards the Sprint Goal.

Who should show up at a daily scrum meeting?

The more pertinent question should be; who is allowed to participate at a daily scrum meeting? Scrum is very clear that the daily scrum meeting is a meeting for the development team. It's the responsibility of the Scrum Master to organise the meeting. However, be warned, the meeting should not be run as a status update for the Scrum Master, Product Owner or Line Manager. Development team members should be sharing information on a peer-to-peer basis at the daily Scrum.

Can anyone outside the development team attend? Non-team members can observe but not participate in the daily Scrum. If your head of marketing wants to catch up on the engineering team's progress on a new product, they can, but they can't participate as a team member in daily standups. Remember, this is not a status meeting for senior management.

Where and when is the best time to hold a standup meeting?

The conventional pattern for a successful daily standup advocates starting at the same time each day, in the same place. The meeting should take place in front of the task board. Many practitioners advocate a morning team meeting, making sense if everyone works in the same location and has similar working hours. However, in recent years, the rise of remote working has challenged established practice, and some companies have successfully introduced alternative patterns.

How long should a standup meeting last?

Scrum uses a practice called timeboxing. Timeboxing works by defining a set, maximum time limit for activities. The objective of timeboxing is to restrict the time spent on activities, reduce waste, and become more time-efficient.

The daily Scrum meeting is timeboxed for 15 minutes each day and allows the team to plan for the upcoming 24 hour period. Discussions should be short and concise, and team members should not use standups to solve sprint impediments. Blockers and impediments should be resolved outside the scrum meeting.

Do I really have to stand up at the daily standup?

It depends on the culture and leadership of your organisation. Opinions vary. The idea of standing up was originally meant to combat overly long meetings. If you're not sat in a comfy chair, you're more likely to want to keep things short and to the point. Does it work? It does depend on who you ask. Certainly, the rise of remote working and advances in technology make the ritual seem ridiculous. Is requesting team members to stand up during a virtual scrum meeting a reasonable expectation? We'll let you decide. Our best advice is to adopt practices that fit your organisation's culture.

The three questions of the daily meeting

Historically, a scrum team member or anyone practising Agile would have to answer three questions at the daily standup:

  • What did I do yesterday?
  • What am I doing today?
  • What are my impediments?

These questions allow the team to see what work has been completed and what tasks remain to achieve the sprint goal. It also highlights impediments or blockers obstructing progress towards the sprint goal. This daily update on obstacles allows team members to offer help and overcome problems with greater speed.

However, things may be changing. In the 2017 version of the Scrum Guide, these three questions are categorised as being an optional part of the daily scrum meeting. In the 2020 version of the Scrum Guide, the three questions aren't even mentioned. What gives? Well, co-author of the Scrum Guide, Dr Jeff Sutherland, has stated that he's trying to create a less prescriptive Daily Scrum meeting.

The future of the daily standup

The daily scrum meeting is evolving, and the creators of Scrum are determined to answer the critics and make it less prescriptive. The workplace is also changing, and agile practices must embrace advances in workplace technology and the rapid adoption of remote working.

One development in the evolution of the daily standup is the introduction of an asynchronous daily standup. This approach attempts to tackle several problems using technology. Coordinating team members in different time zones or working from home can be difficult. However, this is becoming increasingly common as work practice. How does a team observe the guidance on having a daily scrum meeting or standup simultaneously and the same place each day? It's just not practical in specific scenarios.

An asynchronous daily standup is conducted over a more extended period of the working day. Team members answer standup questions via a Slack bot or collaboration software. This form of standup can be more convenient and, more importantly, results are recorded and knowledge shared with anyone interested in sprint goal progress. Are there any drawbacks? Yes, blockers can be harder to manage. A face to face meeting can be much more direct in dealing with impediments.

Whatever your flavour of Agile, the daily standup is changing.

Elite are experts in project management training. We train Agile practitioners worldwide, and in 2020 Elite was awarded Sole Supplier status to the Scottish Government for Project and Programme Management learning. Do you want to upskill or refresh your Agile knowledge? Browse our Agile course portfolio.  Alternatively, if you'd rather speak to a training consultant, call us on 0141 222 2227.

Send this to a friend