The Project Management Plan – Scope Management

Planning

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!

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.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

Now available in paperback!

Requirements Analysis Using Event/Response And Use Cases – Event Discovery Part 2

Planning

In the previous post I discussed how to use the Context Diagram for initial Event discovery. In this post I will present how to use the outputs from your Event List to discover more events.

The fifth column in your Event List (the one labeled “Which creates this…”) are the outputs of your business processes. You can use these outputs to discover more Events by asking the following questions for each output:

  • Does the output go to a “Customer”? (an entity outside of the center bubble in the Context Diagram). If yes, then that is where the output ends. If no, then that means it must be input to another event or the output has no purpose. Ask your SME’s (Subject Matter Experts) what other business processes use this data. For each identified business process, you can flesh out the Event List row for that process.
  • What are the “Create” Events for this output? These are the Events that result in the establishment of a new row (or rows) of data in the output in question. For example, the sale of a product creates a Sales Transaction record. Note there may be more than one Event that creates rows in this output.
  • What are the “Change” Events for this output? For this you may need to examine each data element in the output. For each element, ask the SME’s what business processes change this data. Use these answers to continue to build the Event List.
  • What are the “Delete” Events for this output? These are the Events that result in the logical or physical removal of a row in the output. For example, if the record retention requirement for the output is 5 years, then the time-based event “Record Retention Limit Reached” will be added to your Event List.

Now that you have added many more rows to your Event List, you will have more outputs to examine. Cycle back thru the Event List outputs and ask the same questions listed above. You will find your Event List grows very quickly!

In the next post I will continue to present additional techniques for Event Discovery.

Note: My Kindle book “Project Management For The Real World”, is available at

https://www.amazon.com/author/lettera

The Project Health Scorecard Part 1 – Project Schedule Health

Executing Monitoring and Controlling

Here is the suggested guidance for the status of the Project Schedule Health:

Your Schedule Health is Green if:

  • You have a schedule and…
  • It is actively managed and…
  • The forecast matches the published completion date

Your Schedule Health is Yellow if:

  • It is early in the project and you don’t have a schedule but are working towards one, or…
  • You have a schedule and the forecast has a greater “live date” than the current published date but corrective action is defined and probable, or…
  • The schedule is not being actively managed.

Your Schedule Health is Red if:

  • You don’t have a schedule, or…
  • You have one but the published live date cannot be met.
  • Note: Red can turn back to Green when a new schedule is approved and base-lined.

Note: Much more detail on the Project Health Scorecard can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera

Risk Management Deeper Dive Part 5 – Contingency Plans

Executing Monitoring and Controlling

In the prior post I discussed risk mitigation strategies, which can reduce the potential impact of risks that haven’t occurred yet. In contrast, risk contingency plans are meant to deal with risks after they have occurred. It is sometimes amusingly referred to as “Plan B” (and “C”, “D”, etc if necessary). Contingency plans answer the question “What will we do if …”.

It can be much easier to create contingency plans in advance because you are not under the stress of the risk having already occurred and you have more time to brainstorm the potential plans. Anticipating risks and having well vetted contingency plans keeps you in control of the project and minimizes “crisis mode”.

Here are a few examples:

  • If there is a risk of testing taking longer than planned, you can have a list of additional testing resources identified to join the effort if testing falls behind.
  • If there is a risk of inclement weather disrupting outdoor activities, you can have indoor activities lined up to keep the project moving.
  • If there is a risk of a key resource leaving the project, you can have a consultant resource procured in advance to step in if needed.

As with all elements of Risk Management, conditions may change over time, so the contingency plans should be revisited on a regular basis to ensure they are still viable.

Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera

Risk Management Deeper Dive Part 4 – Risk Mitigation Strategies

Executing Monitoring and Controlling

With your risks identified, prioritized and monitored, it is now time to develop strategies for managing the risks. The first type of strategy is “Risk Mitigation”. These are actions you can take before a risk occurs that can reduce the exposure to the risk. You should brainstorm these strategies with the members of the project team you identified in the Risk Management section of your “Project Management Plan” (refer to prior posts on this topic).

There are four mitigation strategies you can employ:

  1. Risk avoidance – this is the most expensive of the risk options. You can spend money or resources to eliminate the risk. An example would be if you have a lesser skilled resource assigned to a task, which raises a risks of on-time completion and/or deliverable quality, you can spend more money for a resource skilled enough to eliminate those risks.
  2. Risk limitation – this is the most common strategy. You take some action to reduce the probability and/or impact of the risk. One example would be if you are concerned about server downtime or performance during peak loads, you can implement redundancy and load-balancing to mitigate this risk.
  3. Risk transference – involves handing off the risk to another (willing) party. Examples are buying insurance, or outsourcing services.
  4. Risk acceptance – if the cost of mitigating the risk outweigh the cost of the risk itself, you may choose to just accept the risk with no mitigation actions. This strategy is typically employed for risks with low probability and/or low impact.

Documenting your mitigation strategies puts you in control of the project. You can manage your risks or they will surely manage you.

Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera

Risk Management Deeper Dive Part 3 – Risk Triggers

Executing Monitoring and Controlling

In this series Part 1, I addressed Risk Identification. In Part 2, I addressed Risk Probability, Impact and Exposure. In this entry I will discuss the concept of the “Risk Trigger”.

An important aspect of Risk Management is knowing and detecting that the risk has occurred. This is know as a “Risk Trigger”. In some cases it may be obvious. An example of this would be a risk such as “If the project team loses key resource “A”, then the task estimates assigned to “A” will need to be extended which may impact key milestone commitments”. In most cases the PM will know when they have lost a key resource. However, in the case of very large project teams, the key resource may be embedded deep in the project hierarchy, hiding the loss unless there is a communication plan to notify the PM

Your risk triggers must define the method you will use to monitor the risk. For example, if there is a possible change to a government regulation that will impact your project, you can engage your Legal team to monitor the status of this regulation on a regular basis and report any changes directly to the PM.

Here is another example: if there is a risk your server capacity is insufficient to meet peak demand, you might direct your technical team to establish monitors for CPU and disk usage and raise a flag if they are approaching the safe limits.

The lesson here is don’t assume you will just know when a risk has occurred. Define Risk Triggers (even the obvious ones) for all of your risks.

Now that you know your risks, exposures, and when they occur, the next step is to manage them with mitigation and contingency plans. I will tackle these topics in the upcoming posts.

Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera

Risk Management Deeper Dive Part 2 – Risk Prioritization

Executing Monitoring and Controlling

After you have identified your risks, the next step is to prioritize them. We do that by assigning a probability rating and an impact rating, then combining the two to determine your exposure (i.e. priority).

The Risk Probability is a measure of the likelihood of the risk occurring. In most cases it is difficult to assign an exact probability. It usually will be sufficient to define probabilities as “High”, “Medium”, and “Low” and define these probabilities as ranges. Here is an example of the ranges I typically use:

  • High = 70% or greater probability
  • Medium = between 40 – 69 % probability
  • Low = less than 40% probability

You can use whatever definition you choose as long as all of the parties helping you assign probability are aware of the defined ranges.

The Risk Impact is a measure of the effect of the Risk occurrence on the schedule, scope, budget and quality of the project. Again, since in most cases this may be difficult to quantify, using ranges represented by “High”, “Medium” and “Low” will suffice. Here is an example of range definitions for Risk Impact:

  • High = greater than 10% impact on one or more of schedule, scope, budget and quality
  • Medium = 5-10% impact on one or more of schedule, scope, budget and quality
  • Low = less than 5% impact on one or more of schedule, scope, budget and quality

The Risk Exposure is a product of both the Risk Probability and the Risk Impact. It is also measured as “High”, “Medium” and “Low” if that is the way you defined the probability and impact. Here is how the Risk Exposure can be determined:

  •  Probability (High) + Impact (High) = Exposure (High)
  •  Probability (High) + Impact (Medium) = Exposure (High)
  •  Probability (High) + Impact (Low) = Exposure (Low)
  •  Probability (Medium) + Impact (High) = Exposure (High)
  •  Probability (Medium) + Impact (Medium) = Exposure (Medium)
  •  Probability (Medium) + Impact (Low) = Exposure (Low)
  •  Probability (Low) + Impact (High) = Exposure (Medium – but watch closely due to impact)
  •  Probability (Low) + Impact (Medium) = Exposure (Medium)
  •  Probability (Low) + Impact (Low) = Exposure (Low)

Now that you have your Risk Exposure determined you should monitor and act on them in order of exposure, with the ones rated “High” given the most attention. This will help you allocate your risk management resources appropriately.

Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera

Risk Management Deeper Dive Part 1 – Risk Identification

Executing Monitoring and Controlling

The first step in managing risk is to identify the risks you need to manage. This is the most important step in risk management and something new project managers tend to struggle with. I will present some techniques that have over the years have worked well for me.

  1. What worries you? – You can ask this question to your project team members and stakeholders. Do this first individually, then in groups. Many do not understand the term “risk” as it applies to projects and may come up with a blank if you ask them about risks. Everyone can relate to the term “worry” and I have found this helpful. You may get answers such as “I don’t have enough resources” or “the timeline is too tight” or “I don’t have enough expertise on my team in this area”. These types of answers are a great start in risk identification.
  2. The “Pre-Mortem” – We are familiar with doing “lessons learned” and “post-mortems” on projects. Doing a “Pre-Mortem” can help identify risks. You ask the project team and stakeholders  “It’s 9 months from now, the project is over and it was a disaster. What are the reasons?”. Your mind works better at identifying risk when looking backwards so this technique can be very effective. You may get responses like “The Sponsor wasn’t involved in decision making” or “We didn’t train the staff on the new tools”. These types of answers are risks that need to be managed. You can also ask the opposite question: “It’s 9 months from now, the project is over and it was wildly successful. Why?”. Responses like “Mary Jones was assigned as the technical lead” or “The Steering Committee made prompt decisions” will help you identify risks and mitigate them.
  3. Risk Breakdown Structure(RBS) – if you Google this term you will find many examples. An RBS is simply a hierarchy of areas in which risks can occur. You would present each of these areas to the team and brainstorm potential risks for each area. Here is a sample RBS:
  • Technical
  • Technology
  • Complexity of Interfaces
  • Performance and Reliability
  • Quality
  • External
  • Vendors
  • Regulatory
  • Market
  • Customer
  • Weather
  • Environmental
  • Government
  • Internal
  • Dependencies on other projects
  • Resources
  • Funding
  • Requirements
  • Resistance to change
  • Inexperience
  • Schedule
  • Equipment
  • Quality
  • Customer Satisfaction
  • Project Management
  • Estimates
  • Plans
  • Controls
  • Communications
  • Scope

You should state your risks in a consistent manner. A common way to phrase your identified risks are: “If (risk event occurs), then (impact to project in terms of scope, schedule, cost, quality)”

Here is an example: “If the vendor is late delivering Component X, then we may not be able to meet the project milestone for the first build”. Note that I stated “may” not “won’t”. Remember, risks are probabilities, not certainties. If it is a certainty, it is an issue, not a risk.

Note: Much more detail on Risk Management can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera

The Project Schedule Part 7 – Schedule Adjustments

Planning

After you have created your initial cut of the schedule, you will often find that this schedule will not meet the target date. Adjusting the schedule and adapting to changing circumstance is where Project Managers earn their money.

Here are some of the actions you can take:

  • Focus on the tasks that are on the Critical Path
  • Revisit the estimates – do some of the estimates have more safety time built in than is needed? Where can you reduce estimates and not take on more risk?
  • Fast-Tracking – look at activities that you have scheduled in sequence due to assumed dependencies. Can you do some of these in parallel or at least have some overlap? For example, you might have “Solution Construction” following “Design” but in reality you can start building some of the solution after some (but not all) of the design is completed. Fast-tracking is a very common practice and you will use this on most large projects.
  • Crashing the schedule – this is where you throw additional resources at critical path tasks without regard to efficiency or budget. If meeting the target date is imperative, this is a useful tactic. It is best to plan for this contingency when you are doing your Risk Management Plan in order to have contingency funds in the budget that you can draw on in case the schedule risk is triggered.
  • Obtain stronger resources – you can examine the critical path task assignments and look for opportunities where more experienced and knowledgeable resources would allow you to substantially reduce the task estimates.
  • Reduce Scope – review the ranked requirements and obtain Sponsor approval to remove or delay requirements that are not essential for the initial go-live date.
  • Sacrifice Quality – you can ask the Sponsor for approval to reduce test time for functions that are used rarely or are not business critical.

You are likely to use some or all of the tactics listed above in any project of significant size. It is a critical skill for Project Managers.

Note: Much more detail on creating a Project Schedule can be found in my Kindle book “Project Management For The Real World”, available at

https://www.amazon.com/author/lettera