In this article, I will share three primary issues in scope management–not including all the work, gold plating, and poor alignment with objectives and goals. And, we'll look at solutions for each. First, let's examine what scope management includes.
"Project Scope Management includes the processes to ensure that the project includes all the work required, and only the work required, to complete the project successfully." PMBOK® Guide–Sixth Edition, page 129
Let's break this statement down and examine each element and the potential issues.
If you wish to be a successful project manager, you must manage scope risks. In this article, let's define scope risks, look at some examples, and explore eight ways to identify scope risks.
Risk is "an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives" (PMBOK® Guide—6th Edition, Page 720). Scope risks are uncertain events or conditions that are related to the project scope.
What do we mean when we say something is out of scope? It should not be included in the project. Things have a way of sneaking in, don't they?
Keep in mind, product scope includes the features and functions of the products, services, and results. And project scope is the work required to create the deliverables.
In this post I'm going to show you how to develop a project charter.
In fact, these are the exact techniques that I used to create charters for small-budget to multi-million dollar projects.
Let's kick things off by defining the project charter.
A project charter is a "document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities" (PMBOK® Guide—Sixth Edition. Page 715).
Entering projects with little consideration of quality can be costly in numerous ways. Let's look at the cost of having no quality management plan. Then, we will explore how to develop a practical quality management plan.
So, in what ways is poor quality costly?
First, we may not meet the customer's needs and expectations.
Second, the cost of corrective action and defect repair may be higher than expected.
Third, the cost of quality after the project may be higher and may decrease customer confidence.
Fourth, project communication may be more challenging since people expect different things.
Fifth, your team's morale may suffer. Nobody likes missing deadlines due to rework. This is often a result of poor quality requirements.
Let's first define quality. For project management, quality is "the degree to which a set of inherent characteristics fulfills requirements" (PMBOK Guide, Page 718). Project managers and teams focus on meeting the customer's needs.
The quality management plan "is a component of the project management plan that describes how applicable policies, procedures, and guidelines will be implemented to achieve the quality objectives. It describes the activities and resources necessary for the project management team to achieve the quality objectives set for the project" (PMBOK® Guide—6th Edition, Page 286).
Management develops, publishes, and communicates quality policies. Why? To support the achievement of the organization's objectives and values.
For example, Nestle has a Quality Policy which includes: "Strive for zero defects and no waste by constantly looking for opportunities to apply our continuous improvement approach to deliver competitive advantage."
What if your organization has no formal quality policy?
Nevertheless, wise project managers define the quality requirements. The quality management plan may be a simple one-page plan for small projects and a more robust plan for larger projects. Furthermore, project managers work with their sponsor, team, and key stakeholders to determine what's needed.
Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction, and skillful execution; it represents the wise choice of many alternatives. —William A. Foster
This is determined by the type of project that is being undertaken. A nuclear power plant team will be decidedly different from those helping with the development of an accounts receivable software package. For instance, here are some candidates:
The Quality Management Plan should be fitting to each project. Only include the elements that are necessary and nothing more. The plan may include but not be limited to:
It's a good idea to look at prior lessons learned. Additionally, engage your stakeholders in the process to get their input and buy-in.
Susie, a project manager, was asked to manage a software development project. She invited her sponsor, the Quality Assurance manager, the lead developer, and business analyst to a meeting. The purpose was to develop the quality management plan.
Susie asked the business analyst to share his recommended approach for developing and managing the requirements. Next, she asked the lead developer about the designs, unit testing, function testing, and integration testing.
Susie invited the QA manager to help determine the testing plans including the individuals who would perform the tests, the order of the tests, the test environments, and the tracking of defects.
Lastly, Susie described a traceability matrix to trace the requirements through each phase of the project. All of this information was captured in a simple quality management plan.
In your next project, think about your approach to quality management. What are one or two steps that you will take to further improve quality?
Bad project managers create project cultures filled with stress, confusion, and little progress. Unfortunately, many of these individuals are not aware of their behaviors.
Let's run through a list of eight behaviors that all bad project managers have in common. Furthermore, let's talk about how to remedy these behaviors.
Some project managers keep their team members in meeting prison, and often, the meetings are things that could have been handled in other ways. This behavior leads to frustrated team members who are busy trying to get their project work completed.
Things to do: Eliminate recurring meetings when possible. Eliminate status meetings - gather status information and share through status reports. Always ask yourself: Is there another way to handle something that does not involve a lengthy meeting? A quick conference call. An email. Instant messenger. A quick stand-up meeting.
Project managers crave successful software projects. They dream of crossing the finish line with a win. Project managers want to help their company and advance their career. Let's look at three powerful questions to help you identify lessons learned.
Unfortunately, some project managers fall into a rut and fail to make progress. These individuals do the same things from one project to another project and expect a different result. They take the wrong actions, pursue the wrong things and operate under wrong assumptions.
"Insanity is doing the same thing over and over and expecting different results." —Albert Einstein
Just because you've been a project manager since the days of "Gilligan's Island" is no guarantee that you are an effective project manager.
As a matter of fact, you may be still trying to get off your island. Even the Skipper and the Professor can't seem to help...encouraging...huh?
So, how can we produce intended or desired results in our projects? Here are 10 tips. Forming habits requires time and effort, but let's decide first which of these would be most helpful.
The term "risk" means different things to different people. Some individuals think risks are negative events (i.e., threats); others include positive events (i.e., opportunities). Whether you are starting a project or a program, be clear about what you mean by the term risk.
Many project managers and project teams approach their projects with no idea of how they plan to identify risks, assess risks, define risk response plans, implement response plans, or monitor risks. Don't make this mistake. Define a risk management plan and reach agreement with your team as to the approach and the amount of rigor you plan to use.
How often have you elicited items such as problems, solutions, or implementation ideas from meeting participants? This sounds simple, but often, participants disagree. The meeting can turn into quicksand. Let's look at the Nominal Group Technique (NGT), a powerful technique for reaching consensus.
Imagine that you are planning to facilitate a session to identify the strengths of your organization. What technique would you use to capture their ideas? How would you prioritize the list?
The nominal group technique is a structured method for group brainstorming that allows every participant to have an equal voice. It is a particularly effective tool for larger groups. The technique saves time, engages participants, and improves the probability of agreement.
There may be inherent risks when we make project assumptions. We assume certain things to be true when in fact, they may not be. Consequently, we fail to challenge assumptions and continue planning and executing based on false notions. This can be costly.
So, how does this happen? In her book—Thinking in Bets—author Annie Duke shares an illustration:
Suppose someone says, "I flipped a coin and it landed heads four times in a row. How likely is that to occur?" It feels like that should be a pretty easy question to answer. Once we do the math on the probability of heads on four consecutive 50-50 flips, we can determine that would happen 6.25% of the time (.50 x .50 x .50 x.50).
The problem is that we came to this answer without knowing anything about the coin or the person flipping it. Is it a two-sided coin or three-sided coin or four? If it is two-sided, is it a two-headed coin? Is the flipper a magician who is capable of influencing how the coin lands?
In our projects, we may be guilty of this type of thinking. We may assume the world is flat when indeed, it is not. Assumption analysis can help us discover the facts or supporting information when identifying project risks and later when evaluating risks.
So, what are project risk owners and how should project managers identify and assign them? Let's talk.
Imagine that you are the project manager of a two-year, multi-million dollar project. During the execution of your project, you take a beach vacation.
One of your team members calls upset that a major risk has occurred. You cooly reply, "No problem." You text the risk owner and discover that the risk response plan is being executed and everything is fine.
Is this scenario possible? One thing is for sure. If we don't identify and recruit risk owners, this will never happen. Your project will be at greater risk.
The PMBOK 6th Edition says a risk owner is "the person responsible for monitoring the risks and for selecting and implementing an appropriate risk response strategy." Furthermore, these individuals may aid in evaluating their risks in performing qualitative risk analysis and the quantitative risk analysis.