Projects don’t manage themselves. Professional project management requires the development of a plan that outlines how it will be managed. According to the Project Management Body of Knowledge (section 4.2), the project management plan fulfills this purpose. Although it includes any and all items that define the management of the project, there are certain standard items. These are the components that provide the core regardless of industry or type of project.
Components
The primary components of a project management plan are:
- Scope Statement
- Critical Success Factors
- Deliverables
- Work Breakdown Structure
- Schedule
- Budget
- Quality
- Human Resources Plan
- Stakeholder List
- Communication
- Risk Register
- Procurement Plan
Scope Statement
Every tool purchase, equipment rental, employee wage, cup of coffee or any item of expense must be defined as either a part of the project, or not a part of the project. This is one of the fundamental responsibilities of a project manager, to know and maintain the boundaries of the project. In fact, scope definition issues are the number one cause of project distress, which is why the scope statement is one of the most important parts of a project management plan (and why I include it first).
Of course you will never know all of the finest details of what is included within the project at the outset, nor how much effort / expense is really required to accomplish the project’s objectives. But the point is that there is no substitute to spending a bit of extra time at the beginning to define the project’s boundaries. This is probably the number one thing you can do to ensure successful projects over the long term.
Scope statements should be SMART:
- Specific. The more specific the better.
- Measurable. If you can’t measure it, you have no way of knowing if it was achieved. Sometimes the best criteria is qualitative, but use quantitative descriptions whenever possible.
- Achievable. It’s surprisingly easy to commit to something you don’t have the expertise to complete.
- Relevant. The scope should focus on completing the goals of the client/owner, and avoid tasks that do not add value.
- Time Bound. A project is by definition temporary and thus has a time limit. I would consider this optional but it certainly doesn’t hurt in a scope statement.
Examples
Here are a few examples of what I would consider good scope statements:
- This project involves building a fence between the house at 10 ABC Boulevard and 12 ABC Boulevard. The fence will consist of steel posts founded on concrete-filled holes. The fence will be built out of cedar and it will be 8 feet tall. This is to keep the dog at 10 ABC Boulevard contained within the yard. The fence will be located as close to the property line as possible, and start at the garage on the west side ending at the house on the north side.
- This project is for the creation of a construction safety app for cell phones. There will be an app for iPhones as well as Android based systems. The user interface will be designed as part of the project but will contain, as a minimum, the ability to create and edit tailgate meetings, field level hazard assessments, safety inspections, and audits. Each of these will have a built-in checklist for typical projects in typical industries. There will be a corresponding web application whereby anyone using the app can log in to view and print the reports. The app must include a tutorial to make it easy to get started.
Critical Success Factors
There isn’t one specific criteria that defines success for all projects. Thus, you need to make sure you define success for yours.
Since a project is defined as a temporary endeavor, time and cost are usually high on the success criteria list. Obviously someone wants to receive the deliverables at a certain date, and they want to pay a certain cost for them. Other items that can define project success are:
- Deadlines (time)
- Budget (cost)
- Quality standards
- End user benefits
- Minimal change orders
- Low rate of product rejections
- Employee satisfaction
Examples
Here are some examples of critical success factors:
- The project will be completed by December 31.
- The app will accomplish the required tasks with the least amount of clicks/taps.
- The project team will obtain new skills in the area of database management which the larger organization will benefit from.
Deliverables
Deliverables are the products, services, or results that the project is commissioned to produce. The project “delivers” them to the project sponsor who commissioned the project. Thus, all projects have deliverables which should be spelled out in detail within the project management plan. Also, details about quality, size, length, or other standards can provide important context.
Examples
Here are some example project deliverables:
- An 8 foot high fence
- A cell phone app
- A training course
- Accurate weather forecasts
Work Breakdown Structure
The foundation of the effective management of projects starts with the creation of a WBS, which is a logical subdivision of the project into tasks. Management of the project is then done on a task by task basis.
It can be as simple as a list of tasks:
| ID | Task | Dependencies |
|---|---|---|
| 110 | Excavation | |
| 120 | Build Forms | 110 |
| 130 | Place Rebar | 110 |
| 210 | Pour Concrete | 120,130 |
| 310 | Setting & Curing | 210 |
| 320 | Strip Forms | 210 |
Task ID’s can be in any format (1, 1.1, 1.1.1. or A, A1). For larger projects you could also produce something more applicable to their size:
Schedule
Since projects have a defined beginning and end, the schedule is usually an important piece of the puzzle. Often external stakeholders are involved in the determination of the deadline dates. Likewise, changes in the schedule mid-project are usually issues that require active management.
Developing a project schedule does not have to be a major undertaking involving expensive project management software. Whatever accomplishes the goal of communicating the project milestones and deadlines to the applicable stakeholders is good enough.
For small projects, the WBS can simply be expanded to include the deadline dates:
| ID | Task | Dependencies | Start | End |
|---|---|---|---|---|
| 110 | Excavation | May 1 | May 10 | |
| 120 | Build Forms | 110 | May 10 | May 15 |
| 130 | Place Rebar | 110 | May 10 | May 17 |
| 210 | Pour Concrete | 120,130 | May 18 | May 18 |
| 310 | Setting & Curing | 210 | May 18 | May 20 |
| 320 | Strip Forms | 210 | May 20 | May 22 |
For larger projects a graphical schedule could be more appropriate:
If your project’s budget and/or timelines permit you could purchase project management software and learn to produce professional looking schedules. Microsoft Project is widely used across all industries. There are also many industry-specific project management software products such as Primavera P6 which is popular in the construction industry. Also, there are some internet based scheduling tools like Tom’s Planner which are easily accessible at any time.
Budget
The temporary nature of a project requires that a well defined budget is in place and that it is actively managed to keep it from sprouting roots and growing like an obnoxious weed.
Just like the schedule, for small projects the budget can be added to the WBS:
| ID | Task | Dependencies | Start | End | Budget |
|---|---|---|---|---|---|
| 110 | Excavation | May 1 | May 10 | $1,800 | |
| 120 | Build Forms | 110 | May 10 | May 15 | $100 |
| 130 | Place Rebar | 110 | May 10 | May 17 | $800 |
| 210 | Pour Concrete | 120,130 | May 18 | May 18 | $690 |
| 310 | Setting & Curing | 210 | May 18 | May 20 | $250 |
| 320 | Strip Forms | 210 | May 20 | May 22 | $0 |
| TOTAL | $3,640 | ||||
If you’re using the earned value method to track and manage the project, this budget column would be called “Budget at Completion,” or BAC for short.
Quality
When a project produces a deliverable there are always quality standards in play. For example, if the fence-building project produces a fence that is not straight the neighbor will complain and probably want a new fence (if it’s bad enough).
What are the quality standards for your project? These should be itemized and listed. Every industry has standard quality success criteria which can be looked up and specified for the project with relative ease, like ASTM, IEEE, or ISO-9001. These organizations are in the business of developing quality standards, thus they are fantastic sources for ensuring project quality.
Also, there are several aspects to quality management:
- Determining quality standards
- Developing a strategy to meet the standards (quality assurance)
- Measuring quality (quality control)
Each of these items should be addressed within the quality section of the project management plan. Quality control results should be actively documented throughout the project, and changes in strategy should be updated within the project management plan.
Human Resources Plan
The project team members are often one of the most critical components in the chain of successful projects. They are also usually very time consuming for the project manager – whether hiring new workers or obtaining them from the larger organization, they must be trained and their productivity needs to be actively managed.
The human resources portion of the project management should contain the following items:
- Resource Requirements. A list of project team positions, job descriptions, and so forth.
- Project Team Acquisition. How the project team will be acquired. Lists of positions which are already occupied from the larger organization, how much time each person will devote to the project, where the project team will come from, and so forth.
- Training and Development. How you will ensure that the project team has the ability to successfully carry out the project.
- Management. Motivational activities, performance assessments, staff reassignment procedures, and any other item that is relevant to the successful management of the project team.
Stakeholder List
In my industry there tend to be so many stakeholders it can make your head spin. The government client (owner) wants to spend the least amount of money but the government regulator (from the same department) wants to invest in environmental mitigation. The adjacent landowner wants to get rich, the power line needs to be moved, the gas line requires meticulous contracts, and the railway company throws out all your deadlines because it can’t be bothered with your project. I can only imagine that I’m not alone in this problem.
In fact, since I’ve been keeping stakeholder lists I’ve found that they have grown throughout the project, almost without exception. In other words, it’s easy to forget a few small ones and it’s inevitable that those small stakeholders will have a disproportionately large influence on the project outcome.
For that reason, the stakeholder list should be developed and stored within the project management plan and consulted regularly. A proper stakeholder analysis includes a classification of the stakeholders power to influence the project as well as their level of interest in it.
Example
| Stakeholder | Power | Interest | Concerns |
|---|---|---|---|
| State of Blue Sky (Owner) |
High | High |
|
| Landowner | Medium | Low |
|
| Gas Utility | High | Low |
|
Notice that the owner is a stakeholder in this table, although technically they occupy a special role. They commissioned the project and the project sponsor works for them. The project deliverables are produced for them. But including this special stakeholder in the project stakeholder list ensures that their needs are considered regularly just like everyone else’s, therefore I advocate for this practice.
Communication
The biggest source of project issues tend to be the project scope, deadlines and budgets. But poor communication makes it worse, and often the lack of communication is the only reason an issue arises. That’s why communication is one of the most important aspects of the project management plan.
Obviously the project manager should contact stakeholders when an issue arises that concerns their interest in the project. In that case the project manager must simply pick up the phone. I don’t have any earth-shattering wisdom except to let them know early that things are not going according to plan and keep them informed throughout. It’s human nature to want to avoid telling the bad news but this is when contact is the most important. Avoiding it will only create an environment whereby issues will arise much quicker in the future. Although this is the most important type of communication of all, there is usually nothing specific that can be entered into the project management plan.
However, every project has regular communication needs that should be addressed within the project management plan. These include things like project updates, investor circulars, progress reports, and so forth.
The project management plan should contain a list of formal communication that are core to the project.
Example
| Name | Recipient(s) | Frequency | Medium | Contents |
|---|---|---|---|---|
| Progress Report | All stakeholders | Monthly (last day of the month) | pdf via email | CV and SV, discussion of last months tasks |
| Investor Circular | Project investors | Monthly (first day of the month) | Cost Variance (CV), discussion of cost status |
Risk Register
Above everything else a project manager is a leader, and one of the most important traits of leadership is to prepare for the unexpected. Taking fast, decisive action when things go wrong is one of the most important traits of a leader, and therefore a skill you need to learn if you want to be a top notch project manager.
The proper way to manage risk is through the creation of a risk register. This fancy-sounding word simply means a listing of the most important risks to the successful completion of the project. Remember the critical success factors, above? Any item that can negatively influence the success of the project is considered a risk.
Clearly it is not feasible to attempt to identify all risks to a project – Maybe a plane will crash into your office. But the importance of a risk is defined by two factors:
- Probability
- Impact
Obviously, a plane crashing into your office has a high impact (severity) but a probability so low as to eliminate it from consideration in your risk register.
Analysis of risk is a complex field with many books written about it, but for most projects a simplified process works very well. The risk register contains the following fields:
- Description of risk. The final list of risks is determined via brainstorming, subject matter experts, analysis of previous projects, and so forth. A maximum of 20 risks should be used as a guide, but usually you will want to quit at about 10 because they get pretty remote.
- Probability. A scale of 1-10, A-E, or similar will classify the risk sufficiently.
- Impact. A scale of 1-10, A-E, or similar will classify the risk sufficiently.
- Priority. The Probability is multiplied by the Impact to determine the overall priority. But re-classifying them into a 1-10 scale usually makes sense. The list is then sorted by priority.
- Triggers. The actions or events that define the occurrence of the risk are identified. For example, if you’re building a fence and the risk is that it starts to rain, how much rain makes you have to stop? What defines the risk as having occurred?
- Response plan. This is where you develop a plan to deal with the risk. What are the action steps that will be followed when the trigger is deemed to have occurred? Who will perform those actions, and who are all the stakeholders that need to be notified?
The last two items are often too big for the table but should be itemized separately to ensure all of the requisite information is present.
Example
| Risk | Probability (1-10) |
Impact (1-10) |
Priority (1-10) |
Triggers | Response Plan |
|---|---|---|---|---|---|
| Rain delay | 7 | 4 | 7 | Small drizzle, too muddy to work | Wait for rain to stop |
| People are re-deployed off the project | 8 | 7 | 9 | Manager calls employee back | See separate response plan |
Procurement Plan
Many projects have sub-consultants, sub-contractors, and suppliers. The project management plan should identify the following things:
- What outside products and services are required.
- How they will be procured.
- How their progress and quality will be monitored.
Outside contractors usually don’t have the same focus on quality and timeliness that the performing organization does, thus management becomes a more important issue.
Generally speaking, the procurement process goes like this:
- Develop a Statement of Work (SOW). The SOW has many synynoms, like Terms of Reference, scope statement, Request for Proposal (RFP), and others. But it is simply statement of what work the outside contractor must perform. Usually the technical details are kept separate from the contractual stuff (bidding procedures, insurance requirements, etc.) because an engineer will write the technical part and a lawyer will write the contractual part. Because of this the terminology has also become separated. The technical details are called the SOW or the Terms of Reference, and the contractual stuff is called Request for Proposal, Request for Quotation, Invitation to Tender, and the like.
- Perform the Procurement. Once the Request for Proposal (RFP), which includes the Statement of Work (SOW) is finalized, it is sent to the bidders to perform the procurement. Once the bids are in, a winning bidder must be chosen. Always make sure you write into the tender and/or SOW that you are free to pick any bidder rather than just the lowest, because if you don’t you will be forced to pick the lowest (in most jurisdictions).
- Progress Payments. Normally contractors are paid based on the amount of work completed per month (or some other time period). There might be some documentation required but the invoice is sent, the progress is verified and the bills get paid.
Notice that the when it is written, the statement of work tends to be perceived as a document that describes the work to be done, not necessarily the boundaries of the project. But establishing effective boundaries is extremely important. Every word will be scrutinized when the contractors are preparing their bids. It is remarkably easy to leave a little bit of room for interpretation, which results in the potential for an unscrupulous contractor to win the job with a lower price and then make a claim for more money when a certain work item is “out of scope.” This dance takes place every day on large construction projects.
The SOW continues to be scrutinized word by word throughout the project. Any little piece of work that was not envisioned at the outset can result in a change order, that is, additional cost, if the relationship is not strong. Thus, it is an important component that must be reviewed and analyzed in detail before it is released.
Example
| Item | SOW | RFP | Advertising Date |
Award Date | Completion Date |
|---|---|---|---|---|---|
| Geotechnical Engineering | geotech_tor.pdf | geotech_rfp.pdf | Jan. 15 | Jan. 30 | May 30 |
| Surveying | N/A | email to Joe Surveyor | N/A | Feb. 10 | Feb. 25 |
Other details such as management methods, progress measurements, change procedures, and dispute resolution mechanisms can be detailed separately from the table.
Mastering these 12 core components will ensure that your project will get as close as possible to “managing itself.” Once the project management plan is in place, ensuring the project sticks to the plan is the domain of earned value management. If you’d like to learn more about project management, please try our project management tutorial.
Good luck on your project management plans, and definitely leave us a comment to let us know if you have any other ideas or experiences to share.
