1. Project Charter .This document initiates the project and authorizes the project manager.

It
documents the business need for the project as well as assumptions and constraints the
project must live under. It generally includes high level scope and quality information. It is
issued by the project sponsor and represents the organizational authorization for the
project.

i. Scope statement
A general scope statement which identifies the vision the organization has for the project.
For example, the construction of a new commercial building might require a certain number
of offices, design to a certain standard, etc. Although it is a good idea to identify the key
deliverables with which the project has been conceived, it is not the function of the project
charter to identify all deliverables. A scope statement will be developed for the project during
the planning phase, but the project charter can (and should) identify the scope of the project
as it relates to why the project is being created.
ii. Milestones
The major milestones should be identified in the project charter, although it is not the role of
the project charter to list all milestones. A project charter should contain a description of the
key milestones to aid in communicating the organization’s vision for the project.
iii. Business case
A description of why the organization is undertaking the project is helpful to put everyone on
the same page from the beginning. Business metrics such as expected profit or revenue, or
required Return on Investment (ROI) can make it clear to the project management team what
the expected benefit will be. Maybe there is a single problem that is being solved. Stating
this explicitly can guide in decision making during the project.
iv. Funding amount
Most projects start out with a funding level approved by the organization. Stating the amount
in the project charter ensures that everyone is envisioning the same project. Also, potential
funding changes have a massive impact on project success, therefore issues like potential
loss of funding to competing projects, and year-by-year carryover implications can be
identified.
v. Funding status
Funding always comes with conditions, even when a pot of money has been approved by
the board. I’ve seen projects that have a certain funding level approved but run into funding
issues later on, for example,
a. Money moves to a future fiscal year and ends up on other projects.
b. There are no contingencies available when the cost escalates.
 c. The money was always programmed for a future fiscal year.
vi. Success Criteria
Every project contains written or unwritten criteria for its success and the organization
performing the project should identify these on a level “outside” the project, like the project
charter. There are usually primary success factors, like a smooth road for a paving project,
or adequate load times for a website development project. But it’s the secondary success
factors that are usually overlooked and present the bigger risk to the project. These might
include providing the right asphalt mix to minimize future maintenance, or providing the best
data types in underlying database.
vii. Stakeholders
Although it is not the responsibility of the project charter to identify all stakeholders, the
project charter should identify the primary stakeholders who are integral to the project and
under whose auspices the project was created. For the paving project, the land developer is
the project sponsor and the city (local government) is a stakeholder who is so integral to the
project that they should be addressed within the project charter. The primary objectives of
each party should be identified so it is clear why the project has been created. Stakeholders
can be supporters of the project, or opposed to the project, and they can flip from one to the
other if their expectations are not well managed.

2. Project Management Plan. This is the project managers road map and guiding
document. It is probably the single most important document for the project manager. It
outlines how the project will be managed, and includes the project schedule, budget, quality
standards, project team requirements, project control, and anything else that is necessary to
communicate how the project will be managed. It should be approved by the project
sponsor and changes made according to the official change control procedures specified
within.

i. Introduction

Provide an overview of the project. Identify what the project is intended to accomplish, who
the stakeholders are, and the success factors. Be as quantitative as possible with success
factors. i.e. Is there a specific quality standard that can be attached? Is there a date that
must be met? If there is a project charter, this is a good reference for what to include in this
section.The critical success factors should be identified. In other words, what is the definition
of project success? Deadlines and budgets are normally part of it, but don’t miss things like
project sponsor approval, minimal change orders, low rate of rejections, etc.
 ii. Scope Statement

State what tasks and activities are part of the project and what are not. If the scope is not
well defined in any area, this is probably a good time to define it, keeping in mind that the
biggest cause of failed projects is confusion related to the project scope. Extra tasks cost
money, and the stakeholders generally interpret any undefined areas in the scope in their
own favor. For example, if the project scope for an interchange project does not define land
purchasing, the owner will assume it is part of the project, and the engineer will probably
assume it isn’t. Not that that would ever happen…

iii. Deliverables

All projects must have deliverables. These are the products or services that the project
produces and “delivers” to the customer or client. They should be spelled out in detail within
the project management plan, together with applicable details about their quality, length,
size, or any other standards that apply.

iv. Project Schedule

Since projects have a defined beginning and end, the schedule is extremely important. The
project should be broken down into tasks (aka activities) to an appropriate level of detail. For
small projects, this could be as simple as identifying deadline dates. Software could be
used, such Microsoft Project. Sufficient allowances need to made for contingencies, and all
stakeholders should be aware of the timelines involved. The Project Manager should be
aware of the critical path at all times throughout the project, to be able to respond when
critical issues arise. This is also a good place to identify the dates for the key project
deliverables. The schedule itself can be placed in an appendix.

v. Budget

Each task in the activity list should have an assigned budget. The total budgets should be
rolled up into a total project budget. This allows for accurate project cost tracking, and
earned value analysis to determine the status at any time. Potential for changes and
adequate reasons can also be documented.

vi. Quality Management Plan

The quality success criteria of each phase of the project should be identified and specified to
ensure compliance during project execution. Every industry has standard quality success
criteria which can be looked up and specified for the project, like ASTM, IEEE, or ISO-9001.
 Provide a description of the processes that will be used to ensure that the quality of the
product(s) meet the requirements.

vii. Human Resources Plan

The project participants should be identified and it should be ensured that these individuals
have the time and capability to carry out the tasks required of them.

viii. Communication

Define what major communications will be made at what phases of the project, such as
project review meetings. Define the communication strategy with key stakeholders,
especially those inevitable stakeholders that have a minor financial interest but
disproportionate impact on the project outcome (like the adjacent landowner mentioned
above).

ix. Risk Management Plan

This is the place to identify and prioritize the risks to a successful project. The plan should
list, in table form (or similar) each risk, the mitigation strategy, and the plan of action should
that risk occur. Optionally each risk can also be prioritized and ranked for probability and
severity (Risk = Probability x Severity). There is nothing more comforting than having a well
thought out plan when something bad happens, therefore taking the extra time to be
comprehensive is very important. PMI reports that this is one of the most underrated
sections of the project management plan.

x. Procurement Management Plan.

Many projects have sub-consultants, sub-contractors, and suppliers. The project

management plan should identify at the outset what outside products and services are
required, how they will be procured, and how their progress and quality will be monitored.

3. Change Requests. When a stakeholder wishes that the project manager make changes to
the project, a change request form is filled out and filed within the project management plan.

4. Work Performance Reports of 50% of the work done (you are allowed to make
assumptions on this.) In order to communicate the project performance to the relevant
stakeholders, the project manager or their delegate produces regular performance reports.
These include earned value reports, memos, justifications, recommendations and the like.
To get started, Earned Value Management requires that the project be broken down into tasks
(a work breakdown structure), and each task requires the following pieces of data:

1. Start and end dates

2. A task budget.
Most projects already have these defined. If you don’t, you can define them and measure against
that. If you only have an overall project budget, you can still itemize each task budget on a
percentage basis and track against that. But you need a baseline to track against.

For each task, the following definitions are required:

 Budgeted Cost of Work Scheduled (BCWS): At any point in time, the amount of the task that
is supposed to have been completed, in dollar terms. A linear interpolation works as good as
any. Also known as Planned Value (PV).
 Budgeted Cost of Work Performed (BCWP): At any point in time, the amount of the task that
is actually completed, in dollar terms. Also known as Earned Value (EV).
 Actual Cost of Work Performed (ACWP): The actual cost to the organization of the work that
has been performed.
To calculate Earned Value, perform the following tasks:

1. Estimate the expected percent complete based on the schedule. For example if the start and
end dates of the task are Dec. 1 and Dec. 10, respectively, and it’s Dec. 3 today, the expected
percent complete is 30%.
2. Convert this to a monetary value by multiplying by the task budget. This is called the Planned
Value (PV), also known as the Budgeted Cost of Work Scheduled (BCWS).
3. Estimate for the actual percent complete of each task, based on the number of hours of work
left to complete it.
4. Convert this to a monetary value by multiplying by the task budget. This is called the Earned
Value (EV), also known as the Budgeted Cost of Work Performed (BCWP).
5. Calculate EV – PV (or BCWP – BCWS), which is called the schedule variance.
6. Graph the results.
 There is software out there for entering your project
schedule and generating an Earned Value graph, but this is the procedure they use. In the absence
of software, you can generate an excel spreadsheet and simply update the numbers every week (or
whatever time period works for you), like I said, in 10 minutes or less.

A major assumption of this method is that the task gets completed at a constant rate. If you have a
task that requires a major expenditure at some intermediate point you may need to make the
necessary adjustments (in #1 above).

How to Analyze the Results

What does it mean? The results of the exercise will give you a number called Schedule Variance,
and a graph of the schedule variance over time. The important things to note are:

i. Negative schedule variance (i.e. the PV is higher than EV on the graph). The project is
behind schedule. The amount tells you something too. If you can compare the negative
schedule variance to your estimated cash burn, say the number of people currently working
on the project, you can get a quick idea of how bad it is. For example, if you’ve got 3 people
working on the project and you’re burning $5,000/week, and a schedule variance of -$4,000,
these are bad numbers. You’ve got almost a full week of work to get back on track.
ii. Increasingly negative schedule variance (i.e. the gap between the PV and EV on the
graph is getting bigger) this is an even bigger cause for concern. The project is getting
further behind. There is probably some sort of disconnect between the baseline (schedule)
developed by the project manager and the work being done on the project. The project
completion deadline could be in jeopardy.

5. Change Log .The project management plan contains a record of all changes made, to
ensure that the project is tracked and lessons learned are gleaned from the changes.