The Project Management Plan – Overview

There are two main types of high level planning for a project: (1) The Project Management Plan; (2) The Project Activity Plan (aka The Project Plan). The Project Management Plan describes the approach and processes for managing the project. The Project Activity Plan describes the work to be done to achieve the project objectives. This series of posts address the Project Management Plan.

The Project Management Plan defines how the project is executed, monitored, controlled and closed. It addresses the management of scope, schedule, cost, quality, staffing, communications, risk, and procurement. Whenever matters of project procedure are in question, this document shall be the first source consulted.

This is a dynamic document and reflects the current thinking regarding the project approach based on what is known at this time. It is expected to be updated with new information as the project unfolds. Original and revised versions should be distributed to the entire project team.

The components of the Project Management Plan are:

Scope Management
Schedule Management
Budget Management
Staff Management
Communications Management
Risk Management
Procurement Management
Project Close Definition
Post-Project Audit Plan

In subsequent posts I will elaborate on each of these sections.

For large projects I highly recommend creating a Project Management Plan and sharing it with your sponsor and key stakeholders. This plan describes the “rules of engagement” for the project and will minimize assumptions and misunderstandings regarding project process. I have also found this to be very helpful if you are new to an organization. It is a way to document your understanding of the project management practices of that organization.

There is a good reason the Project Management Institute (PMI) includes these plans in their best practices. Once I obtained my Project Management Professional (PMP) certification, I included a formal Project Management Plan on all of my large projects.

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 – Cost Management

February 10, 2020October 27, 2019 Professor of Project Management Project Planning Planning, Project Management Plan

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.

The Project Management Plan – Overview

January 20, 2020October 6, 2019 Professor of Project Management Project Planning Planning, Project Management Plan

The components of the Project Management Plan are:

Scope Management
Schedule Management
Budget Management
Staff Management
Communications Management
Risk Management
Procurement Management
Project Close Definition
Post-Project Audit Plan

In subsequent posts I will elaborate on each of these sections.

The Project Plan – Overview

July 31, 2017March 20, 2017 Professor of Project Management Project Planning Planning, Project Plan

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)

Some of these topics will require multiple posts to give them the depth they deserve.

The Project Management Plan – Procurement Management

July 17, 2017March 6, 2017 Professor of Project Management Project Planning Planning, Procurement

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. Be sure to understand the relevant policies and procedures for your organization

The Procurement Management Plan addresses 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

The Project Management Plan – Schedule Management

June 5, 2017June 5, 2017 Professor of Project Management Project Planning Planning, Project Management Plan

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.

The Project Management Plan – Overview

May 15, 2017January 9, 2017 Professor of Project Management Project Planning Planning, Project Management Plan

The components of the Project Management Plan are:

Scope Management
Schedule Management
Budget Management
Staff Management
Communications Management
Risk Management
Procurement Management
Project Close Definition
Post-Project Audit Plan

In subsequent posts I will elaborate on each of these sections.

In my experience I have rarely seen other PM’s create a formal Project Management Plan. I believe this is a mistake. There is a good reason the Project Management Institute (PMI) includes these plans in their best practices. Once I obtained my Project Management Professional (PMP) certification, I included a formal Project Management Plan on all of my large projects.

Requirements Elicitation Techniques Part 7 – Interviews

March 14, 2016November 24, 2015 Professor of Project Management Project Planning, Requirements Analysis Planning, Requirements, Scope

Planning

Interviewing is a systematic approach to eliciting requirements. You can interview an individual or a group of people, in a formal or informal setting. You ask questions relevant to the project and document the responses.

Interviewing should not be the only technique you use to elicit requirements. You will not know all the questions you need to ask. That is why I am a big fan of the Event/Response method. The flow of that methodology creates the questions you will need to ask to ferret out all of the requirements.

In a structured interview, you have a predefined set of questions. These will be based on how much you already know about the area under study. Here are some sample interview questions:

What are the business objectives for this project?
What are your biggest challenges?
What worries you about this project?
Who is impacted (good or bad) by this project?
How are they impacted?
Are their known changes or projects that impact this one?
What business processes are impacted?

When interviewing, avoid “yes or no” questions and pay careful attention to the answers. They usually will led to follow up questions that are not on your script. Be prepared to deviate from the script if necessary.

In an unstructured interview, topics are discussed in an open-ended way. You don’t have a script, so the answers are used to spring-board into subsequent questions.

If possible, you should establish in advance a trust and rapport with the interviewee. This will make them more comfortable to be open and honest with you.

Requirements Elicitation Techniques Part 2 – Acceptance Criteria

February 7, 2016November 3, 2015 Professor of Project Management Project Planning, Requirements Analysis Acceptance Criteria, Planning, Requirements, Scope

If you search the Internet for “Acceptance Criteria” you will see definitions like this: “Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer or external system.” There are no shades of grey, the condition either satisfies the criteria or not. There are no “90% satisfies”.

Acceptance Criteria should be established before development begins. The reason for this is that the criteria needs to guide the development. If you write them during or after the development, you will just be verifying what was built and not the customer intent.

Like all good business requirements, the criteria should be “what” not “how”. For example, you might state “Upon submission of the completed application a notification is sent to the Director”. You don’t want to state “Upon clicking ‘Submit’ an email is sent to the Director”. Avoiding implementation specifics opens up new possibilities for a design solution.

In many ways, the “Event/Response method” (see my prior posts on this topic) and “Acceptance Criteria” are very similar. With Event/Response, we document a triggering event, the data sent and who sends it, what we do with it, the outputs and who receives them. With Acceptance Criteria, many use the format “Given some precondition, when I do some action, I expect some result”. These are essentially the same things although Acceptance Criteria can be at a lower level (the Use Case and Functional Requirements level).

You do not approach your user or customer and ask “What are your acceptance criteria?”. This will mostly elicit blank stares. You will want to use other elicitation methods such as Event/Response and Use Cases, and the derive the Acceptance Criteria from there. You can do this by prioritizing your requirements (e.g. “priority 1 = must have or cannot go live, priority 2 = can go live without it but must have within 1 month of go live, priority 3 = nice to have if it fits within the budget and schedule”). In this case, priority 1 requirements are the acceptance criteria for go live and priority 2 requirements are the acceptance criteria for project completion.

Some examples of Acceptance Criteria:

If I am a System Administrator, I can add, update or delete accounts.
I can search for users by last name and can enter a partial string and receive the results of all that qualify
I can filter my staff by availability for a given shift

Requirements Elicitation Techniques Part 1 – Overview

February 1, 2016October 13, 2015 Professor of Project Management Project Planning, Requirements Analysis Planning, Requirements, Scope

In the previous series of posts I introduced my favorite requirements elicitation technique, “Business Event/Response”. Of course there are many other techniques which can act either as complementary to or in place of “Business Event/Response”. The techniques you choose depend on many factors including the knowledge depth of the Subject Matter Experts (SME), the availability of documentation, time constraints, etc.

A skilled Project Manager that is also a seasoned Business Analyst is a very valuable commodity. I encourage all PM’s to increase their BA ability by reading books, attending webinars and seminars, and putting their new knowledge to practice. There is no substitute for actual work experience in this realm.

Here are the topics I will address in the series:

Part 1 – Overview
Part 2 – Acceptance Criteria
Part 3 – Benchmarking
Part 4 – Business Rules Analysis
Part 5 – Data Modeling
Part 6 – Document Analysis
Part 7 – Interviews
Part 8 – Non-functional Requirements
Part 9 – Observation
Part 10 – Prototyping
Part 11 – Root Cause Analysis
Part 12 – Surveys and Questionairres
Part 13 – SWOT Analysis
Part 14 – Summary

	Steve Robinson on The Project Plan Part 3c…
	soullessgothic on Decision Making Process Part 5…
	Professor of Project… on I Would Like To Hear From…
	Les Marshall on I Would Like To Hear From…
	Establishing a Proje… on Establishing a Project Managem…

Practical Project Management Tips and Tools

A blog from the Professor of Practical Project Management

Planning

The Project Management Plan – Overview

The Project Management Plan – Cost Management

The Project Management Plan – Overview

The Project Plan – Overview

The Project Management Plan – Procurement Management

The Project Management Plan – Schedule Management

The Project Management Plan – Overview

Requirements Elicitation Techniques Part 7 – Interviews

Requirements Elicitation Techniques Part 2 – Acceptance Criteria

Requirements Elicitation Techniques Part 1 – Overview

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: