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?
Project management is "the application of knowledge, skills, tools, and techniques to project activities to meet the project objectives" (PMBOK®—6th Edition). So, how does project risk management fit in the world of project management?
Project risk management fits in project management like a hand in glove. Project managers can use it to achieve their project objectives and goals. How?
Good risk management always starts with clear project objectives and goals. That is to say, project managers who manage risks without project objectives as the basis are simply playing games. There is an appearance of risk management but these individuals are simply going through the motions.
Good risk management always starts with clear project objectives and goals. —Harry Hall
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.
What would you do if all hell breaks loose in a critical company project that you are managing? You lose two of your best team members. Your budget is shot. A key stakeholder is breathing down your neck. Behind schedule by four weeks. You haven't slept well in two weeks. And you feel like throwing in the towel.
Some projects are more risky than others. A project sponsor sees an opportunity. It's a stretch and he knows it, but he wants to try anyway. So, the project charter is completed and the top risks are recognized.
The Project Board approves the project. Why? Because there will be tremendous gains if the project is implemented successfully.
And guess what? You've been asked to manage this project. Lucky you.
As you are engaged in the project, you begin to understand just how challenging the project is going to be. How will you approach the uncertainty that lies before you? What can you do to recognize and plan for the events and conditions that may have negative effects on your project objectives?
When is risk exposure greatest in a project? In the beginning, in the middle, or at the end of the project? It's actually highest in the beginning. Let's look at how to reduce risk exposure early in your projects.
So, why is your risk exposure greatest in the beginning? Project managers have the least amount of information. Uncertainty is the greatest. We know very little about the:
Here are five activities that you can undertake to reduce the risk exposure early.
Operational risk includes people risk, technology risk, external event risk, and process risk. In this article, let's talk about process risk and how to reduce these risks through process mapping.
When employees leave organizations, these entities may loose daily operational knowledge. You know. The people that know how to get things done are now gone. And these organizations often lack process documentation. Furthermore, they fail to cross train other employees adequately.
So, who is impacted? Employees for sure. But most importantly, the customer is adversely impacted.
IF. Have you thought about the use of this two-letter conjunction in risk management lately? Let's look at how to use the power of If-Then risk statements. IF is a simple word that can open up new doors to writing clear risk statements.
Once you've identified your project risks, you will need to write opportunity and threat statements.
Opportunities are events and conditions, that if they occur, have a positive impact on your project objectives (e.g., schedule, scope, budget, quality). Here are examples of how you might start these risk statements: