How many times have you experienced scope creep? You know the drill—you elicit and document the requirements. You receive sign off. You continue to see changes to the requirements. Many projects experience 10, 20, 25-percent change in requirements over the life of the project. Let's explore how to manage project scope.
You cannot manage what you do not understand. Let's get our arms around the concept of scope. The Project Management Body of Knowledge (PMBOK) defines scope as the sum of the products, services, or results.
When we use the word "scope", it is helpful to specify the type of scope—product scope or project scope. The product scope are the features and functions of the product, service, or result. The project scope is the work to deliver the product, service, or result.
Imagine that you plan to have a painter paint your living room. Here are some product scope questions:
What are the tools and equipment that are needed? What work will be done to deliver the product? Here are some project scope questions:
Want more clarification on product and project scope? Read this article from Villanova University.
When it comes to requirements, I wish I could read my user's minds. Unfortunately, collecting requirements is challenging. Project managers should consider engaging an effective business analyst for large projects.
A critical part of projects is defining and managing the project requirements. Requirements are the capabilities or conditions needed in the product, service, or result. They are specifications of what should be developed or implemented.
Like the word scope, it is helpful to use an adjective when talking about requirements. There are different types of requirements. Check with your organization to see if there are standard definitions for different types of requirements.
I typically use the following terms. Notice the cascading levels of requirements. We begin with high-level requirements and progressively elaborate the requirements into greater detail.
How do you eat an elephant? One bite at time. We all know the saying. Project managers can use this principle for any size project. Use the Work Breakdown Structure (WBS) to break your projects into bite-sized pieces.
The WBS is a hierarchical decomposition of the work to be performed in order to meet the project goals and create the deliverables. The lowest levels of the WBS are the work products and deliverables used for scheduling, estimating, monitoring, and controlling the project. Learn how to build a WBS.
“Any goal can be achieved if you break it down into enough small parts.” -Brian Tracy
Do not make the mistake of waiting until the end of a project to unveil the product, service, or result to your stakeholders. Periodically show the prototypes or deliverables to the customer(s) and the sponsor. When the deliverables are mature, seek formal acceptance. These steps can greatly reduce the risk of rework.
Project managers should meet with their teams on a regular basis to compare the work completed to the project scope baseline (the defined deliverables, assumptions, and constraints). If there is variance, determine whether corrective or preventive action is required.
Many project managers think their job is ensure that no changes occur. Make no mistake about it—change happens. Expect it!
Our job as project managers is not to stop all the changes but to ensure the necessary changes occur in an organized and agreed-upon manner. Don't get me—project managers should not just add anything that is requested. Requested changes should support and align with the overall goals of the project.
Take changes through a change control process. Analyze and report the impact to the project sponsor. Seek approval when necessary before proceeding.
Project managers face a multitude of scope risks. Be diligent up front in your project to develop a scope management plan. Seek to understand your user's needs. Engage appropriate stakeholders on an ongoing basis. Regularly compare your work against your plan and make needed corrections.
Have you ever had someone torpedo your project? Did this individual have a motive to undermine your efforts? Or, did you make some stakeholder mistakes that gave rise to this event?
Either way, it's hindering your progress. Things are not going as planned. What can we do to manage stakeholder risks better?
I once observed a junior project manager who was knighted to manage a project with a fixed regulatory deadline. Software changes were needed. The project sponsor told the project manager that it was critical that the project be delivered on time. No exceptions!
The project manager formed a project team. Within days, the project team started making programming changes. The team worked evenings and weekends.
This is a guest article by Elizabeth Harrin from GirlsGuideToPM.com.
Much of the time, risk management at the beginning of a project looks like getting the team in a room to review the whole project and work out what might be coming that could affect how the project proceeds.
The project manager writes up the discussion in the risk register along with what the team is going to do to avoid or amplify (in the case of positive risk) the risks. As the project progresses, more risks are identified, dutifully added and managed.
What’s happening here is that we’re looking at the work and impacts on the work. This approach to risk management is very task driven. We ask questions like:
These are all valid questions. But they miss one crucial area that massively affects everything on the project every day. Us. The project team.
Our skills, ability to work together as a team, or lack thereof, present the biggest chance of success for the project and also the biggest risk.
Here are some examples of how the people on your team make your project inherently more risky.
Why is project quality often neglected? Well, it's hard to manage things we don't understand. And quality seems to be an esoteric concept to many people. Therefore, let's define quality and discuss some practical ways to manage project quality.
1. Make quality management pragmatic. Many people do not invest appropriate effort towards quality because they do not understand it. The Project Management Institute defines quality as “conformance to requirements and fitness of use.” According to this definition, quality comes through clearly defining and meeting the requirements of the users and stakeholders.
Changes in project risks are inevitable. As a project progresses, the probability and impact of current risks change, new risks emerge, and residual risks may increase or decrease. What tools and techniques can project managers use for controlling risks and getting the results they are looking for?
Allow me to introduce you to two project managers—Tom and Susan. Tom started his project with a risk identification exercise with several stakeholders resulting in a list of 77 risks. He entered these risks into an Excel spreadsheet and stored the file in his project repository (and never looked at it again).
Susan, on the other hand, facilitated an early risk identification workshop. She periodically met with her team to review current risks and used additional techniques to identify new risks. In these risk review sessions, the team discussed the effectiveness of the risk responses and the risk management processes.
Which team do you think had the greatest chance of meeting their project objectives? Yes, Susan’s team wins the day, hands down.
Let’s look at six tools and techniques recommended in the Project Management Body of Knowledge (PMBOK) 5th Edition for controlling risks.
PMBOK 6th Edition
The PMBOK 6th Edition changed the process name of "Control Risks" to "Monitor Risks."
"Monitor Risks is the process of monitoring the implementation of agreed-upon risk response plans, tracking identified risks, identifying and analyzing new risks, and evaluating risk process effectiveness throughout the project."
Read my articles:
Risk reassessments involve the following activities:
Project teams may have defined risk responses. The question is—“Are the responses effective?” Project managers facilitate risk audits to examine the effectiveness of the risk responses and to determine whether changes are required. The team also examines the processes to identify, evaluate, respond to, and control risks.
As with many control processes, we now look for variances between the schedule and cost baselines and the actual results. When we the variances are increasing, there is increased uncertainty and risk. Watch the trends and respond before the situation gets out of hand.
Imagine that you are working on a software development project and that the functional requirements have been developed. You’ve planned to deliver functions at a point in time—at the end of the fourth sprint, at the end of phase 1, or a milestone. The technical performance measurement is a measurement of the technical accomplishments.
During the cost planning, the contingency and management reserves are added to the project budget as needed. As risks occur, the reserves may decrease. Depending on how your organization handles reserves and your risk management plan, project managers may request more reserves when inadequate.
Project managers should be deliberate risk managers. Engage your team members and appropriate stakeholders in meetings to facilitate the risk management processes. For these meetings, be sure to:
Don’t be like Tom who started his risk management with a bang and quickly fizzled. The best project managers identify, evaluate, and respond to risks. And they regularly perform the control activities to keep the project healthy.
Hey, before you go, keep in mind—you can't control risks until you first identify risks. Click here to discover 7 ways to identify project risks.
Have you ever endured a project meeting where you spent hours evaluating risks? Afterward, team members walked down the hall saying, “What a waste of time! Now I can get back to the real work.” Today, let's discuss the use of qualitative risk analysis to get you back on track.
What causes this frustration? First, the evaluation process may not fit the project – too complex for simple projects or deficient for large, complex projects. Second, the process may not fit the maturity level of the project team. Third, team members view the process as burdensome with little value.
Risk evaluation is the process to determine the significance of each risk. There are two ways to evaluate risks:
You cannot respond to all risks, neither should you. Prioritization is a way to deal with competing demands. This aids in determining where you will spend your limited time and effort.
We evaluate in order:
Do you find yourself working overtime, trying to deal with unexpected disruptions? Some negative events that you thought might happen has now occurred. And it's costing you more time and energy than you thought possible. Overwhelmed? Well, let's talk about project risks and issues, the differences, and why it's so important to manage risks.
The Project Management Body of Knowledge (PMBOK) defines risk as, “An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.”
Let's examine a risk statement and underscore some key attributes of risks. Here's a risk statement:
Because the project team failed to review the requirements with the users, the project team may not meet the user's needs, resulting in unsatisfied users.
Notice the risk: project team may not meet the user's needs. Think of risk as events or conditions that might happen in the future.
So, how does an issue differ from a risk? Where a risk might happen, an issue has happened. When a threat occurs, it becomes an issue or problem. By the way, when an opportunity occurs, it becomes a benefit.
Are we splitting hairs? The distinction between risks and issues matters for a few reasons.
Risk vs. Issue Debate
Some project managers and risk managers are not convinced that the differentiation between risk and issue adds any value. Even though the risk has occurred (i.e. it is now an issue in terms of the differentiation) there is still uncertainty regarding the impact and the objectives that will be impacted.
While we are on this topic, let's clarify two other terms—assumptions and constraints.
Do you have problems? Projects running behind schedule? Cycle time for a business process increasing? Sales down? People continuing to live in silos? Let's discuss a simple but powerful tool for solving problems - the Cause and Effect Diagram (alias Fishbone Diagram).
“A problem well-defined is a problem half-solved.” -Anonymous
Are you behind schedule on one of your projects? Develop a cause and effect diagram to identify the causes. And then determine which of the causes had the greatest impact. Don't stop there. Determine how you will minimize the probability and impact of those causes going forward.
Some Project Management Offices (PMOs) never get off the ground. I've seen others that are started and a year or so later die a slow painful death. So, how can you build a PMO you can be proud of, one that thrives?
No one intends to build an impotent PMO, but it happens. The PMO lacks power and effectiveness. Therefore, people see the PMO as a hindrance, not an enabler.
Let's look at five ways we can improve vitality and provide value to our organization.
"There is only one way to avoid criticism: do nothing, say nothing, and be nothing." –Aristotle
1. PMO Sponsorship. Without a strong, influential sponsor, the PMO is doomed. Don’t have a sponsor? Then don’t create a PMO. Because you will be fighting an uphill battle, one that you will likely lose.
2. Clarity. Define specific, measurable goals. How will you measure the success of the PMO? What are the Key Performance Indicators?
The PMO leader should also be clear about the type of PMO being implemented. The Project Management Body of Knowledge (PMBOK) describes three types of PMOs:
Since clarity is essential to success, you must continuously cast the vision of where you are going, how you get there, and why you are going there.
3. Alignment. Define a process to ensure projects align with the organization’s mission and goals. What criteria will be used to select projects?
For example, the project selection criterion might include:
Kill non-value added projects. Transfer resources to value-added projects. Certainly, resource management across the project portfolio is a critical success factor.
Some organizations also use a gate review process. At certain stages of each project, the project is reviewed to ensure continuous alignment.
4. Execution. Teach project managers to use a scalable project management framework or methodology. Provide templates to aid project managers in their execution. Another tip, offer to mentor and support project managers during the execution of their projects.
5. Continuous Improvement. Evaluate the framework, tools, techniques, templates, as well as the projects. Develop and maintain lessons learned.
Thinking about starting a PMO? I recommend that you develop a project charter with your project sponsor and key stakeholders. Define the problems you wish to overcome, goals, deliverables, assumptions, constraints, and top risks to a successful implementation. You can build a PMO that you are proud of through early collaboration with your stakeholders, persistent leadership, and staying focused on delivering value to your organization. Best wishes!
A life well lived life involves looking backward as well as thinking forward. The same is true of projects.
In this article, we will look at how to conduct a risk audit to evaluate the effectiveness of your risk management. Additionally, we'll also talk about how to be more forward thinking through risk reviews.
“Good Risk Management fosters vigilance in times of calm and instills discipline in times of crisis.” -Dr. Michael Ong
The project manager, the project manager and team, or a risk audit team may perform risk audits. What is the focus of the audit? It is a retrospective review where we ask “How did we do?”
Wonder if risk audits can really help you and your team. You bet!
And it doesn’t have to be difficult or require lots of time.
The output of the risk audit is the lessons learned that enable the project manager and the team to increase the likelihood and impact of positive events and decrease the likelihood and impact of negative events.
The size of the risk audit team and the time invested should be commensurate with the size and complexity of the projects. I’ve completed small risk audits with me and a couple of team members in an hour or less.
Sounds great, but how does it really work?
Tom was asked to manage a project to implement an insurance company claims customer service center that would house 100 employees. He decided to have a risk audit performed when the team had completed 40% of the project. Things were going fairly well, but Tom was concerned about an increasing number of issues, particularly with two risk owners.
Tom asked an internal risk audit group — comprised of one company project manager, one IT employee, and one claims manager — to conduct the audit. The team completed the audit in two weeks and discovered the following:
The findings were shared with Tom and the project sponsor. The following changes were made:
“Risk is like fire: If controlled it will help you; if uncontrolled it will rise up and destroy you.” -Theodore Roosevelt
How can project managers make better decisions and get better results in the future? Try a risk review.
Remember, the audit team focuses on "How did we do?" Were the risk management processes effective? We are looking backward.
In contrast, risk reviews are prospective and forward-looking. We ask, "How will we do?" We modify our risk response plans and risk management processes to improve our chances in the future.
Project managers and their teams periodically review their project risks for the following:
For more helpful questions, check out my post 12 Questions For Monitoring Project Risks.
Pick one of your worst project, where things have been crazy. Look backward with a risk audit and forward with a risk review. You will likely gain insights and perspective as you see things with fresh eyes. Best wishes!