The Project Management Plan – Cost Management

Planning

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

Planning

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.

The Project Plan – Overview

Planning

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

Planning

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

Planning

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

Planning

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 post addresses 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.

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

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.