Detailed Analysis of PID, Business Case, and Communication Plan

This report provides a comprehensive overview of Project Initiation Documents (PIDs), Business Cases, and Communication Plans, essential components for successful project management. The PID is defined as a document outlining project scope, management, and success criteria, serving as a guide for the project team and stakeholders. The purpose of the PID is to secure commitment from senior management and stakeholders by detailing how the project will be executed and measured. The report explains the process of developing and using the PID, including the importance of stakeholder engagement and the potential for project cancellation if costs or risks increase. It also outlines the key elements of a PID, such as accountabilities, activity plans, risk assessments, cost/benefit analyses, and governance and communication plans. Furthermore, the report explores the Business Case, which justifies project undertaking based on costs and anticipated benefits. It emphasizes the importance of demonstrating that the proposed solution meets business needs, is affordable, feasible, and aligned with high-level strategy. The report also discusses the development and use of the Business Case throughout the project lifecycle, including at project closure and during the benefits realization stage. Finally, the report details the significance of a communication plan within a project, covering both internal and external communication aspects to ensure effective information flow and stakeholder engagement, including planning and plan contents.

Project Initiation Document (PID)
Definition
A Project Initiation Document defines the project scope, management
and overall success criteria that the team can go back to during the
project. It contains the basic information of the project such as context,
scope, team, and collaboration. It is equally important as an internal
guide and for external stakeholders
Purpose of the PID
The purpose of the PID is to provide the information required by senior management and
stakeholders to enable them to commit to the resources and timelines proposed. It is a sort of
‘contract’ between the Project Manager and SRO/Project Board that defines how the project will be run.
The PID provides a detailed proposition against which success can be measured. To do this
the PID builds on the approved Project Brief by defining in detail how the project will be
developed and when it will be delivered. It provides a more detailed understanding of the costs
and benefits of the project and, in particular, the resources, risks and timelines required for
successful delivery.
How the Project Initiation Document (PID) is used
The PID is presented to the SRO/Project Board so that the views of key stakeholders can be
considered. This is an essential stage in the process to ensure engagement and buy-in from
all interested parties to the proposed outcomes.
Acceptance of the PID is the start of the next stage of the project where teams are pulled
together to execute the project over the agreed timeline under the accountability of the

SRO. It is possible that the detailed analysis undertaken for the PID will uncover increased
costs or risks such that the project is cancelled. This is a strength of the staged project
process as it avoids significant resources being expended on the wrong project.
Developing the Project Initiation Document
The Project Initiation Document is all about explaining how the project will be delivered and
managed. It will update the Project Brief on all aspects of the project, but specifically it should
provide the following:
· Accountabilities, roles and responsibilities of each of the project team, including part time
members (who will do what)
· An activity plan (e.g.: a Gantt Chart) on when each deliverable should be completed
(who will do what, and when they will do it by). This will include dependencies and
milestones
· An updated assessment of Risks, including their probability and impact, as well as some
mitigation plans and contingency arrangements
· Updated Cost/Benefit analysis, in particular a detailed resource and timing plan
(resources and timing often have a direct impact on each other)
· Governance plan that details how the project will be monitored and controlled in terms of
decision points, reports and reporting cycles, including whether updates will be on an
exception or ongoing basis.
· Communications Plan that will start to determine how the project will be
communicated to the different audiences, including the press
For further guidance on the contents for each section please refer to the
downloadable template.
When defining a new project it is often worth running a Project Planning Workshop with
representatives from affected parts of organisation (and partner organisations, if appropriate).

This speeds up the process and ensures that all interested parties meet early in the life of the
project and agree what the project is intended to achieve and, in broad terms, how it will be
achieved. The bullets above can be used as the agenda for the workshop.
The PID must document the project management organisation and the stakeholders with
an interest in the project's outcome. The following guidance will help you do this.
The Project Manager must identify and gain commitment from appropriate individuals to
participate in project management roles. If any individual appointed to a project role lacks
experience of working in a project environment the project manager should brief them and
manage their expectations to make sure they fully understand the nature of the commitments
they are making in terms of:
· the time and effort they must devote to the project;
· the sort of decisions they must take;
· the type of resources they must commit to the project;
· the people and organisations they will need to communicate with;
· the sort of risks they will need to consider;
· their role in delivering benefits after the project has completed its work.

The Business Case
Purpose
The business case documents the justification for the undertaking of a project, based on
the costs of development and the anticipated benefits to be gained. It provides an initial
appraisal of the different options available, drives the decision making processes, and is
used continuously to align the project's progress to the achievement business objectives.
The initial Business Case is used to secure full senior management and stakeholder
commitment at the end of Project Initiation. It is subsequently updated and used to assess
the ongoing viability of the project and take decisions affecting the future of the project.
After project closure the SRO will require the Business Case to compare desired benefits
with those actual achieved during the benefits realisation phase.
The business case should demonstrate that the proposed solution:
· Meets the business need
· Is affordable and likely to achieve value for money
· Is feasible and achievable in the time allowed
· Has been chosen after exploring an appropriate options (including the 'Do Nothing'
option) and their associated benefits, costs and risks
· Is clear as to what will define a successful outcome
· Consistent with high level strategy
· Has identified benefits and is clear as to how they will be realised
· Is it clear how the necessary funding will be put in place
Developing a Business Case to suit the project content - minimum requirements
As a minimum the business case should provide an overview of the project, its scope and
objectives, the strategic business fit, options appraisal, affordability and achievability. For less

complex projects this might be just a heading in the PID, but many projects should have a
more detailed ‘free standing’ business case. The level of detail will depend on the complexity
and size of the project, its scope, drivers, scale, amount of expenditure, risks and number of
stakeholders etc.
At the project start up phase, outline business cases for potential project is should be used in
the strategic planning process to help decide which projects offer best value for money and
will best achieve strategic priorities.
At this stage the business case should contain enough information to enable the SRO/project
board to decide whether the project is viable, affordable and worth considering in more detail. It
should explain the business need and why the project needs to be done now, fit to the
organisation's overall strategy, key benefits, the critical success factors and how they can be
measured. Project objectives, scope, risks and outline estimates of time and costs should also
be outlined. For larger projects and those requiring significant financial commitment you may
also wish to include a high level cost benefit analysis of the different options.
Using the Business Case
· During the project: The business case should be updated to reflect actual costs incurred
and any changes to forecast costs and benefits. This information can be used by the
SRO/Project Board to assess whether the project remains viable and to take decisions
accordingly.
· At project closure: The updated business case should be handed over to whoever is
going to take long term responsibility for delivering the benefits. (SRO by default)
· Benefits realisation stage: The business case will be used as the baseline against
which to measure achievement of the actual benefits and to inform any resulting
decision-making.

Communication Plan
There may be two aspects of communication within a project: the first focused on the internal
communication and reporting with regard to the delivery of the project, and the second focused on
communication both internal and external about the nature of the project, its objectives and
deliverables.
Internal Project Communication
Set out the process, timings and governance for internal project communication.
An example could be:
The Project Manager will be the central hub of all communication within the project. All internal
stakeholders to the project should pass information through the Project Manager who will maintain an
effective audit trail. Within the project there will be a series of regular progress reporting developed to
meet the needs of all recipients and to include progress, risks, issues, and budget spend.
External Project Communication
This section will not necessarily apply to all projects, but all projects are about delivering a change
(something that was not previously there), for a business reason. To realise the business benefits a
communication strategy will be needed, be that for internal staff impacted by the change or for external
parties.
The plan could include: (amend as necessary)
1 Communications Objectives
2 The Audiences – both internal and external
3 The Key Messages to be communicated to each audience
4 The Channels of Communication
5 An Activity Time line
6 A Media Plan
7 Evaluation method
The RACI is a great way, especially when you’re new to get a handle on how things work in an agency
and to get up to speed with the internal process. It can be accompanied by a communication plan that
outlines things in more detail.
Communication plans matter in your projects because effective communication, both internal and
external, is critical to project success. Getting feedback on a deliverable, asking a co-worker where a file

is saved, receiving crucial information from a client, conducting the review and approval process, and
other daily project tasks all involve communication. Having a project communication plan outlining
stakeholders, as well as when and how to reach them, is essential. This article covers:
.
Planning project
Without careful planning it is likely that your project will fail to achieve its objectives. In a small
project it is possible that one plan may be used to define the entire scope of work and all the
resources needed to carry out that work. For larger projects, planning will be carried out at
different levels of detail at different times. In all types and sizes of project you must be
prepared to re-plan in the light of experience.
Remember that plans are essential for ongoing project control and must be used and kept up
to date right through the life of the project.
The contents of the project plan
The Project Plan, the first version of which will form part of the PID, will typically contain the
following:
· Plan Description (a brief narrative description of the plan's purpose and what it covers)
· Pre-requisites (things that must be in place for the plan to succeed)
· External dependencies (e.g. commitments required from outside agencies)
· Planning Assumptions (e.g. availability of resources)
· Gantt/Bar chart showing Stages and/or Activities
· Financial budget - planned expenditure

· Resource requirements (e.g. in a table produced using a spreadsheet or project
planning tool)
· Requested/assigned specific resources
The steps in planning
Planning should be carried out in the order shown but bear in mind that iteration around
some or all of the steps will be necessary for all but the simplest of plans.
· Make sure you understand the project's desired outcome, scope, objectives,
constraints, assumptions and the purpose and level of detail of the plan you must
produce.
· Define the deliverables to be created as a result of the plan.
· Specify the activities necessary to develop the deliverables.
· Put the activities in a logical sequence taking into account interdependencies.
· Estimate resource requirements (people, skills, effort, money and other things that will
be needed to carry out each activity).
· Estimate the timescale for each activity (e.g. elapsed duration).
· Schedule the work from the target start date onwards.
· Define project management progress controls and decision points.
· Identify and deal with risks and uncertainties.
· Document the plan.
· Gain approval to proceed with the plan.
The following detailed checklist will help you through these steps.
Planning checklist
This checklist may be used when planning an entire project, a phase/stage within a project, an
activity within a stage/phase or a task that contributes towards completion of an activity. You
might also find it useful if you are applying project management techniques to help you

manage non-project work.
Running the project
Control - the key to a successful project
To appreciate how project control works you must first understand that, despite all the effort
devoted to developing and gaining commitment to a plan, there is little chance that the
resulting project will run precisely according to that plan.
This doesn't mean that you will fail to achieve the objectives of the plan - on the contrary,
you must have a very high level of confidence that you can achieve those objectives and
deliver the full scope, fit for purpose, on time and to budget.
The plan describes what you would like to do but it models just one of the infinite number of
routes from where you are now to where you want to be. In practice your project will follow a
different route to the one shown in your plan, you don't know which one, but you will need
control to make sure it is a route that takes you to where you need to be, when you need to be
there, and at a cost you can afford.
The power of the plan is that it gives you a baseline against which you can compare actual
achievement, cost and time and determine the amount of deviation from plan and hence take
corrective action if required.
The essential requirement for control is to have a plan against which progress can be

monitored to provide the basis for stimulating management action if the plan is not being
followed.
Creating the right environment for control
The basic requirements for control are:
· a plan that is:
- realistic
- credible
- detailed enough to be executed
- acceptable to those who must execute it (Project Manager and Project Teams)
- approved by those who are accountable for its achievement (the SRO/ Project Board);
· a process for monitoring and managing progress and resource usage;
· a project management organisation of appropriately skilled people with sufficient
authority and time to plan, monitor, report, take decisions and deal with exceptions;
· a process to make minor corrections and adjustments to deal with minor deviations and
omissions from the plan;
· the commitment of those who will provide the resources indicated in the plan (SRO,
· Project Board, Stakeholders and resource ‘owners’ in the parent organisation and its
related agencies);
· explicit authority to proceed granted by those who are accountable for the
· project (i.e. the SRO/ Project Board).
If you do not have all these things there is little point proceeding with the project.
Breaking the project down into manageable stages
In all but the smallest or shortest projects you should think about how to break your project into
manageable ‘chunks’ called stages. Every project will have a minimum of two stages - the first

being Project Initiation. A large project may have a number of stages, each of which has its
own stage plan. When designing your project's stage structure look for points where the
SRO/Project Board should:
· review achievements to date and assess project viability
· take key decisions outside the level of authority of the Project Manager
· approve a more detailed plan for the next phase of work
· commit resources in accordance with the project or stage plan
· assess the impact of some significant external event that will influence the project (e.g.:
legislation, decision point in other project, review of business operation).
The Project Manager will also be able to identify stage boundaries by thinking about how far
ahead is it sensible to plan in the fine detail needed for day to day control. In practice, the
detailed plan for a stage will be produced towards the end of the preceding stage, when the
information needed for planning is available.
Project Controls
This section basically details how your project is going to be managed and controlled. The general idea is
to give your Business Stakeholder a warm fuzzy feeling that they aren't going suddenly get "surprised" at
a later stage and discover the project they have sponsored is badly behind schedule, over budget or with
an out of control scope. Well that's the theory anyway. Of course if one was able to simply fill in this
section and voila, projects would miraculously be delivered, then being a Project Manager would not be
such a complex and difficult job!
There are usually three Sections which need to be completed. These usually consist of:
Project Controls
1 MS Project Plan will be maintained for financial forecasting and PM control.
2 A weekly Highlight Report for the Corporate Programme Board and PMO;
3 A weekly presentation on key issues and risks to the Corporate Programme board and / or Business
Stakeholder;
4 Weekly project Team meetings;
5 Weekly supplier meetings;

6 A formally approved Quality Plan;
7 Existing Change Control processes will be followed;
8 A Risk Mitigation Plan, identifying project risks and plans for their mitigation;
9 An Issues Log;
10 Project tolerances will be followed, as documented in Section 11.3.;
11 Product reviews, as documented in the Quality Plan;
12 Exceptions to be escalated to the Corporate Programme Manager;
13 Budget Actuals and forecasts produced for each financial period.
Project Stages
1 Initiation
2 Requirements
3 Design
4 Development
5 Test
6 Project Launch and Close
Exception Process
This part you need to be careful on since it covers how much your Budget, Time and Project Scope can
increase without the project being forced to go into Exception. Believe me, having seen colleagues go
into Exception is not a pretty sight. It means the Project Manager has to fill in numerous reports, spend
time explaining why it has happened and then essentially beg for more time or money.
On top of which if it is agreed that the project can move into Exception, an Exception Plan will need to
be produced which will replace the versions of the project/stage plans which were in use before the
Exception. And on top of all this additional paperwork the Project Manger will also have to keep the
project moving forward and ensure their team are motivated!