Last week, I talked about How to Develop a Quality Management Plan. Today, I’d like to share common quality management mistakes. Being aware of these failure points can help you and your project teams to identify and manage quality risks.
Quality Management Mistakes
1. Failure to Define Quality
Quality means different things to different people. One person may say that they own a high-quality diamond ring. A builder describes his quality homes.
What does quality mean to a project manager and the project team? Quality is the degree to which a project meets the requirements. This implies that the requirements are known and that the needs may be met partially or fully.
Improve buy-in and support for your project budgets
Do you ever feel like the Lone Ranger when trying to improve cost estimates? You’re not alone. Actually, you have a team.
Many project managers are left to their own devices when estimating projects. This can be rather challenging. So, how can we improve our cost estimates?
I’d like to suggest something different — engage your project team and key stakeholders. Not only will you improve your cost estimates, but you’ll also get better buy-in and support in keeping the project within budget.
What kinds of projects would benefit from this approach? Large complex projects. And alien projects that are different projects than previously undertaken.
Think about it for a minute – what have you done in the last six months to improve your cost management?
Review the projects you’ve completed in the last year. How many of those projects came in over budget?
Consider John, a savvy project manager, who was asked to manage a project to replace a dated network system. The project sponsor told him that he had $100,000 for the project. When John asked the project sponsor how the $100,000 was estimated, but he never got a clear answer.
As John started the project, he checked the historical records of similar projects as well as some other companies. His early estimate — an analogous estimate — was $125,000 with a range of accuracy between -25 percent to +50 percent. John shared the estimate with the sponsor and said that he would provide a more detailed estimate after completing a work breakdown structure (WBS) with the project team.
The team used the WBS to complete a bottom-up estimate, estimating each project activity and rolling the individual estimates up to higher levels and ultimately to a project total. John reported the revised estimate of $120,000 with a range of accuracy of -5 percent to +10 percent. The sponsor increased the budget to $110,000.
John worked with the sponsor and the team to find ways to further decrease cost. What could be excluded? How could the team get discounts when purchasing the equipment, software, and wiring?
Cost management is rarely a straight shot. We zigzag, don’t we? We give and we take, and we attempt to find ways to deal with the budget constraints we face each day. (If you have a spouse and children, you probably already understand these principles, huh?) Let’s look at some ways to improve your cost management.
The Problems with Crashing, Fast Tracking, and other Schedule Compression Techniques
How do project managers unintentionally create schedule risks? As a result, perhaps you feel a cloud of uncertainty about your schedule.
Image courtesy of Adobe Stock.
Many times, it starts with pressure from a sponsor to deliver the goods early. For sure, project managers have a responsibility to work with their sponsors to understand the requirements and to complete the projects within the sponsor-imposed deadlines. Rather than wasting our time complaining about the deadlines, how can we work with our sponsors and team members to find solutions to schedule issues?
As we work to develop and compress our schedules, let’s be aware of the common causes of risk. We will be in a better position to manage the risk and deliver our projects on schedule.
5 Causes of Schedule Risk
Crashing the schedule. It’s always been funny to me that the Project Management Body of Knowledge uses the word “crashing” as a schedule compression technique. The term makes me think of an uninvited guest crashing a party, but with schedule management, the individuals are actually invited to the party. Project managers use crashing to shorten the schedule for the least incremental cost by adding resources, typically to the critical path. It can be a great technique — just be aware — crashing may increase your risk. Too many cooks in the kitchen spoil the broth.
Fast tracking. Here’s a technique to shorten the schedule by performing activities in parallel for at least a portion of their duration. For example, we might start work on a software design while the team is working on the requirements. Consequently, this technique may increase your risk and requires good communication and coordination; otherwise, it may be anything but fast.
Assigning the wrong resources. You ask a manager for a resource for your project. In return, you get the person who is least busy, not the skilled resource you need. Rather, Susan, an experienced project manager describes specific skills needed and uses her influencing skills to persuade the manager, greatly improving her chance for securing the queen resource. What’s a project manager to do when resources are preassigned?
Making sequence mistakes. John, an inexperienced project manager, failed to work with his team to sequence the project activities properly, resulting in issues which were discovered after the schedule was approved. As a result, John has learned to engage his team members when identifying and sequencing future project activities.
Failure to baseline your schedules. The project manager and team did a great job in breaking down the project, identifying activities, and creating the project schedule. However, the project manager failed to get approval for the schedule. What happened? Yes, the schedule changed. The team did not have a baseline for comparison resulting in significant uncertainty about the health of the project. Like building a house without a plumb line, who knows if the walls are straight?
Question: What other ways have you seen project managers unintentionally create schedule risks?
What tips do you have for breaking down your project into deliverables and activities?
I asked this question on LinkedIn: What tips do you have for breaking down your project into deliverables and activities? Bill Duncan responded with the following tips (which I thought were great):
Recognize that “work packages” are only the lowest level of the WBS from the buyer’s perspective in a contracting environment.
Recognize that any deliverable can be described as an activity (by adding a verb) and any activity can be described as a deliverable (by removing a verb). Don’t worry about the distinction until you have the decomposition done.
Decomposition happens phase-by-phase. You can’t develop a complete WBS for a non-trivial project at the start.
When you are confident that you can estimate cost and duration, you have enough detail.
Every lower level must be both necessary and sufficient for the item above it.
Steven Pressfield said, “A great trick that I learned having worked as a screenwriter for many years, the way screenwriters work, is they break the project down into three-act structure: Act 1, Act 2, Act 3. I think that is a great way to break down any project, whether it’s a new business or anything at all.”
Image courtesy of Adobe Stock
Whether we are creating a Pixar movie, a building, a highway, or a service center, wise project managers break down their projects into pieces. As we do, we create a structure for the project that helps stakeholders understand the project.
Some people struggle with the challenges of creating large, complex systems, highways, and companies. How can we do this? The answer: one bite at a time. Breaking projects into pieces makes the impossible possible. In addition, the break down creates the vision.
Some project managers struggle to identify scope risks. Why?
Image courtesy of Adobe Stock
First, individuals may lack a concrete understanding of scope; scope seems to be a nebulous concept. WHAT exactly is scope?
Second, individuals may not know HOW to identify scope risks.
Either way, the failure to identify (and manage) scope risks can be costly. It’s like an overdrawn bank account. There are all kinds of penalties and fees if you know what I mean.
What are Scope Risks?
Risks are uncertain events or conditions, that if they occur, will have a positive or negative effect on the project objectives. What are some examples of scope-related risks?
Individuals may add features to the product that were not approved.
The project team may not identify all the deliverables, requiring changes later.
Scope changes may not be processed through the change control process.
Requirements may not be properly analyzed and understood.
Requirements may change and affect the deliverables.
Requirements may not be properly prioritized.
The design may be simplified resulting in less effort and cost.
Traceability structure may not be developed resulting in requirements not being managed through the design, development, and testing processes.
The project team may fail to identify all the activities required to create the deliverables.
Keep in mind that scope is the sum of the products, services, and results to be delivered through the project. Product scope includes the features and functions of the products, services, and results. Project scope is the work required to create the deliverables.
Why is scope management so difficult? What enemies cause us scope issues?
Let’s first consider the essence of scope management: “to ensure that the project includes all the work required, and only the work required, to complete the project successfully,” according to the Project Management Body of Knowledge (PMBOK). Let’s take a look at each part of this statement.
Enemy #1 – Not Including All the Work
Some project managers have a bad habit – they create their project plans with little input from the stakeholders. What’s the result? The project manager may miss key deliverables. They do not have ALL the work required in their project plan.
In his book — Just Enough Requirements Management — Alan Davis shares, “Various studies suggest that errors introduced during requirements activities account for 40 to 50 percent of all defects found in a software product.”
Photo courtesy of Adobe Stock
What are Project Requirements?
Project managers talk about this topic a lot. Stakeholders hear the term “requirements” but interpret the meaning in different ways. Before we can manage anything, it’s critical that we have a working definition.
Requirement: something that is needed or that must be done. –Merriam-Webster Dictionary
The Project Management Body of Knowledge defines requirement as “a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.”
Karl Wiegers — author of Software Requirements — shared this definition: “Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute.”