My book, “Project Management for the Real World“, is now available in paperback and Kindle formats at
http://www.amazon.com/dp/B0B9S3D9MT
If you like this blog, you will benefit from reading this book.
Welcome!
The Project Management Institute (PMI) encourages its members to advance the profession. One of the ways to do this is by helping others increase their project management skills. The target audiences for this blog are professional PM’s early in their careers as well as those who manage projects but are not PM’s by title or trade. I will be posting every week or so, offering practical tips and tools on the full range of project management topics. I hope you will find this useful and help you advance your career.
Happy Thanksgiving!
Happy Thanksgiving to my USA followers. A new post will be published 11/28.
The Project Plan – Overview
There are many Project Managers and Stakeholders who refer to the Project Schedule (usually built in Microsoft Project or equivalent) as “The Project Plan”. This is not true. The schedule shows “who, what and when” but does not address “how”. A plan must address “how” or it is not a plan. I will address the Project Schedule in a separate series of posts.
The prerequisite to building a schedule is to identify all of the activities, and in order to do that you need a Project Plan. Activities will also be drawn from the Project Management Plan (refer to prior series of posts for more on this). This overview will list the main topics of the Project Plan and subsequent posts will do a deeper dive into each topic.
Here are the elements of the Project Plan:
- The Development Plan
- The Operations Plan
- The Organizational Change Management Plan
- The Test Plan
- The Migration Plan
- The Pilot Plan
- The Deployment Plan
- The Support Plan (post-implementation)
- The Support Plan (during the project and stabilization)
You will not necessarily need all of these plans for a given project. It is good practice to review each one for every project to see if they apply. Some of these topics will require multiple posts to give them the depth they deserve.
My book, “Project Management For The Real World”, is available in paperback and Kindle format at
The Project Management Plan – Project Close
When you are managing a long-running project, your sponsoring business partners may start to feel you are a permanent part of their team. Since many projects have enhancements to make after the initial project is done, it is easy to get endlessly drawn into managing these enhancements as if they were part of the original project.
Your defense against this is to define the conditions of project close in your Project Management Plan. Here is a sample list of typical conditions:
- The Project Objectives from the Project Charter have all been met
- Contracts have been fulfilled and closed.
- Lessons Learned have been documented and reviewed
- Project Documents have all been stored in the project document repository
- There are no critical open issues (there will always be some issues left over; as long as they are not critical, these can be handled by your post-implementation Support Model)
Be sure to include this section in your Project Management Plan and that your Project Sponsor is aware of and agrees to these conditions in advance.
My book, “Project Management For The Real World”, is available in paperback and Kindle formats at
The Project Management Plan – Procurement Management
In many projects you will need to procure or purchase something. It might be software, hardware, professional services, office space, furniture, resources, licenses, permits, etc. It is up to the Project Manager to determine what needs to be procured, who is providing the funding, who will sign the purchase orders or contracts, and the timing of when it is needed for the project. These actions need to be tracked and managed in order to stay on schedule and budget.
Many organizations have policies and procedures on procurement to ensure they are getting the best deal and there are no suspicious or illegal activities. Be sure to understand the relevant policies and procedures for your organization
The Procurement Management Plan addresses at least the following:
- Lists what to purchase or acquire and when and how
- Documents all products, services, and results requirements
- Identifies potential sellers
- Describes how sellers will be selected
- Describes how contracts will be negotiated, administered and closed. You can reference the Contract Management policies of your organization
My book, “Project Management For The Real World”, is available in both Kindle and paperback formats at
The Project Management Plan – Risk Management
Managing risk stands along with having a well-defined Project Charter as the two most important disciplines of Project Management. Having a documented plan for how you will manage risk will help enforce the practice.
In a future post I will describe the metrics that are used to measure the health of a project. One of these measures is Risk Management. The health of managing risk is “green” (which is good) if you have a sponsor-approved plan for managing risk and are adhering to it.
The Risk Management Plan addresses the following:
• Identify the template to be used as the Risk Register. Include column definitions and an example. In a future post, when I elaborate on Risk Management, I will identify the key components of a Risk Register
• Include the procedures you will use to identify, monitor and escalate risks. This includes identifying who will participate in Risk Management sessions.
• Identify standard checklists or historical risk information you can use for Risk identification
My book, “Project Management For The Real World”, is available in both paperback and Kindle formats at
The Project Management Plan – Communications Management
Managing communications on a project is one of the top real-world challenges, right up there with the battle for resources. Project crises are frequently created by miscommunication or lack of communication.
Communications must be managed on many levels:
- Communicating up to Executives and the Project Steering Committee
- Communicating sideways to your management peers
- Communicating down to the project team members (note the “up”, “sideways” and “down” designations refer to the typical project hierarchy chart and are not meant to be derogatory)
- Managing the lines of communication. There are potentially n(n-1)/2 lines where n = the number of people involved in the project. For example, a project with 10 people has 45 potential lines of communication!
Knowing how to tailor your communications to each audience is an important skill. Executive communication is typically brief and bottom-line (are we on schedule and budget? Do we have critical issues? How are high-exposure risks being managed?). Communication to management peers usually will include important project metrics (schedule, budget, scope, resources, issues, risks, task plans). Communications to project team members is focused on near-term task planning and upcoming milestones.
The Communications Management Plan specifically addresses the following:
- Identifies all of the stakeholders and determines their information and communications needs
- Identifies how and when the information will be distributed, including status reporting, progress measurement, and forecasting
- Identifies how stakeholders will be managed to satisfy their requirements and resolve issues. This includes defining the lines of communication and the mechanism for issue logging and visibility
- Identifies the project document repository and the folder names
My book “Project Management For The Real World” is available in paperback and Kindle formats at
The Project Management Plan – Staff Management
Staff management planning is important to prevent or minimize the battle for resources, which is the number one problem for most Project Managers. The Staff Management section of the Project Management Plan addresses the following:
• Identifies project roles, responsibilities, and reporting relationships
• Describes how the project team will be formed, developed, and managed. This includes procedures on releasing and adding team members
Identification of roles can occur even before you know the specific names that will fill those roles. It is based on the parameters and demands of the project. Examples of roles are “Executive Sponsor”, “Project Manager”, “Business Analyst”, “Tester”, “Contract Reviewer”, etc.
Defining the responsibilities of each role is important to minimize the chance of two unwanted outcomes: (1) two or more people are duplicating effort because they all think they own it; (2) key responsibilities are not taken on by anyone because they think it is owned by someone else.
Defining the reporting relationships is important as you will need to know who to go to for permissions and escalations.
Understanding how the project team will be formed is important to make sure you will have the roles filled on time, for the time needed, and with the skill sets required to meet the schedule.
The Project Manager also has a responsibility to develop the project team members soft and hard skills so they become more valuable to the organization and increase their personal job satisfaction. This development can take many forms. It can be formal training, coaching or show by example. You can discuss who will be targeted for development with the managers of the project team members and define what form it will take.
My Kindle book (now also available in paperback!), “Project Management For The Real World”, is available at
The Project Management Plan – Cost Management
Depending on the organization you work for and the project you are working on, the Project Manager may or may not be managing the project budget and costs. If you are tasked to do this, include Cost Management as part of your Project Management Plan.
The Cost Management Plan addresses the following:
• Defines what resources (human, hardware, software, services, facilities) will be considered part of the project costs and when it will be base-lined
• Defines how costs will be reported and who will approve invoices and internal costs
• Defines the magnitude of cost changes that will be subject to formal change management
• Includes a plan for change management: How change is requested, authorized, and documented
• Reference the Project Charter for the priority of Cost in the triple constraints
If cost is the highest priority in your project triple constraints, Cost Management becomes a critical activity. You want to not only record and track costs that have already been incurred, but you also must do new cost projections on a regular basis. As more is known about a project, cost projections will become more accurate.
A former manager of mine once told me that if your costs incurred + future projected costs exactly equals your budget, then you are not doing accurate cost projections. This is based purely on the laws of probability. The probability of your actual and projected costs EXACTLY matching a budget created before the project began is very low.
My Kindle book, “Project Management For The Real World”, is available at
http://www.amazon.com/dp/b089krddvn
Now available in paperback!
The Project Management Plan – Schedule Management
Before I dive into Schedule Management I want to note the difference between the schedule and what many refer to as “the project plan”. You will often hear the Microsoft Project artifact referred to as “the project plan”. In reality, it is only the project schedule. The Project Plan is the combination of the Project Management Plan (being discussed in this series of posts), the Project Activity Plan (or Work Breakdown), which will be discussed in future posts, and the Project Schedule. I encourage you to use this terminology correctly.
The Schedule Management Plan addresses the following:
• Indicates how the project schedule will be created (who will be the sources of start/end dates and effort), when it will be base lined and lists any scheduling constraints
• Describes the implementation approach (phased, iterative, pilot, etc)
• Defines what level of the schedule will be subject to change management (typically these are the high level milestones and major phase start/end; all other changes can be informally negotiated)
• Defines how schedule performance is monitored and reported (e.g., variance analysis)
• Defines the project schedule software to be used
• Includes a plan for change management: How a schedule change is requested, authorized, and documented
• Reference the Project Charter for the priority of Schedule in the triple constraints
Schedule Management is a critical part of project management and communication. In future posts I will show how to construct the schedule and monitor performance.
My Kindle book, “Project Management For The Real World”, is available at
http://www.amazon.com/dp/b089krddvn
Now available in paperback!
The Project Management Plan – Scope Management
The Project Management Plan defines how the project is executed, monitored, controlled and closed. The first component of the Project Management Plan is the Scope Management Plan.
The Scope Management Plan addresses the following:
• Defines how the Scope of Work will be created. This includes a roles/responsibilities matrix (who will create the scope, who will contribute to the scope, who will approve the scope)
• Defines what the Scope of Work will contain (Scope exclusions, process and physical scope, organizational scope, application scope, deliverables, Work Breakdown Structure aka WBS)
• Defines what constitutes the baseline Scope for change management purposes. This is not the actual Scope, it is the sources of Scope (e.g. “The deliverables as listed in section x of document z and the approved WBS”)
• Includes a plan for change management: How change is requested, authorized, and documented
• Describes the process for getting approval for completed deliverables
• References the Project Charter for the priority of Scope in the triple constraints
My Kindle book, “Project Management For The Real World”, is available at
http://www.amazon.com/dp/b089krddvn
Now available in paperback!
Practical Project Management Tips and Tools 