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.

 

Requirements Elicitation Techniques Part 2 – Acceptance Criteria

Planning

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

Planning

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

Requirements Analysis Using Event/Response and Use Cases – Event Discovery Part 1

Planning

In prior posts I introduced the Context Diagram and the Event List. In this and the upcoming series of posts, I will define some techniques you can use to discover events and complete the Event List and Context Diagram.

The very first place to start defining events is the Context Diagram. Every input arrow on the diagram represents an event to which your “business” must respond. Remember, our definition of your “business” is the boundary of the business area under study. Inside of the business bubble on the Context Diagram, you have control over the business processes and data flows. Outside the boundary, you can negotiate the interfaces with the Suppliers and Customers but have little or no control over their business processes.

Let’s examine an example of how the Context Diagram can provide events. For this example, let us say the Supplier is an Employee and the input arrow is “Travel Expense Details”.

Our first column on the Event List is “When this happens”. In this example, you would state “Travel Expense Report Submitted”.

The second and third columns are “This Source” and “Gives us This”. In this example, the Source is “Employee”, and “Gives us This” is “Travel Expense Details”.

The fourth column is “Then we do this”. These are the labels of the business processes your “business” will execute upon receipt of the “Travel Expense Details”. You might have a list of processes that looks like this:

  • Verify expenses comply with business policy
  • Approve/Reject Expenses

The fifth column is “Which creates this”. These are the outputs of each business process. The outputs of the first process listed above might be “Valid Expenses” and “Invalid Expenses”. The outputs of the second process listed above might be “Approved Expenses” and “Rejected Expenses”.

The sixth column is “… and we give it to …”. These are the recipients of the outputs listed in the fifth column. In this case the recipient of the Valid and Invalid Expenses could be “Employee’s Manager”. The recipient of “Rejected Expenses” would be the Employee while the recipient of “Approved Expenses” could be the Travel Expense Data Repository.

In the next post, I will continue the discussion of Event Discovery and show how, once you have a few events listed, you can use these events to discover more events and get the complete scope of the project.