Quality Management | By Joseph Phillips | minute read
Have you had any great customer service lately? No? Me either.
Customer service, or the lack thereof, is unbelievable - especially in restaurants. My favourite watering hole, well it's hardly a favourite, but it's a safe distance from home, has some horrible service. It seems that the waiters, waitresses, bartenders, are more interested in their pub drama than in getting me my reuben sandwich and frosty brew.
So why do I go? Other than it being close to home, their food is tasty, the beer is always cold, and it's priced right. I know what to expect and they usually deliver. When I visit, I can expect to be ignored, overlooked, looked over, and then eventually served. I can expect a fair price for a decent meal. I can expect the same end result every time. All in all, they meet my expectations.
I'm sure you have similar restaurants, stores, and services where you live: you aren't overly impressed, but they deliver to your level of expectation. So what would you do if you went to a four-star, high-dollar schmancy restaurant and got the level of service from local pub? Expectations would not be met and you'd be disappointed, right?
Quality is Meeting Expectations
The point I'm making is that when expectations are met quality is met. That's right. When you expect a level of service, a predefined level of satisfaction, and then those expectations are met, quality has been fulfilled. If you've ever had the opportunity to read The Guide to the Project Management Body of Knowledge (PMBOK) you have my condolences. This book, in my opinion, reads like a toaster manual. Having said that, the PMBOK is often referred to as the Bible when it comes to project management. According the to PMBOK quality is defined as "the totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs."
Whoop-tee-do. Did they get an attorney to write that?
In English, when it comes to project management, quality is the ability of the project to meet all of the project scope requirements - and the implied needs of the project scope. Let me give you an example: you and I are building a brick house and we've approved all of the blueprints, the design documents, the landscaping, and everything else down to the type of door knobs and bathtub drains.
The builder builds the foundation, frames the house, and has the mason lay the bricks. On our first inspection, however, we notice that the mason has done something terrible. Each brick, on one side, is embossed with "Chicago Brick Company." Our mason has consistently laid the bricks with the text "Chicago Brick Company" facing out. Our beautiful brick house looks great from a distance, but up close we're one big ad for the Chicago Brick Company. Say it with me: Greeaaat.
Of course we object, but the mason and the architect counter-object because we never stated that the text should face inward, not outward. Besides, they have built the house exactly to our design documents and blue prints down to the doorknobs and bathtub drains, so what's the problem?
The problem is that the house, while it satisfied stated objectives, did not meet implied objectives. Who wants to look at "Chicago Brick Company" a few million times? Now attorneys have to get involved and I'd rather eat worms than deal with attorneys. (Wow! two cracks on attorneys in one article - here come the lawsuits!)
Quality Is Not an Accident
In project management, as with most things in life, quality is planned in, not inspected in. Quality, and the expectations for acceptance, must be defined up front. I know, I know, this sounds great on paper. Let's have a real word moment, shall we? Here's a discussion I've had with stakeholders:
- Me: Hello, stakeholders, what do you want?
- Stakeholders: We want our software to do this, this, this, and this. And we need it to be really, really fast. And we need it yesterday around noon. And we've got $23.45 to pay for it, okay?
- Me: (after pulling my hair out, completing eighteen rounds of negotiations, and getting the stakeholders to define exactly what "this, this, and this" means): Now about this $23.45…
- Stakeholders: It's all the cash we have unless the lottery hits tonight.
- Me: The lottery isn't until tomorrow night, but even still, you've created a scope that's this big (I stretch my arms far apart like a Michael Jordan basketball pose) but your budget is only this big (I bring my index fingers close together like when I report on the puny size of my brother Sam's fish).
- Stakeholders: Hey, that's how big your brother Sam's fish was. Can we trim some of the scope to match a budget of $250,000?
- Me: Yes.
And then we discuss all of the objectives, design documents, and expectations for acceptance that'll make the customer happy. In short, we've got to know everything before we begin. The stakeholders and me, the project manager, have to define all the business that'll make them happy when the project is complete.
All metrics, such as throughout, data consistency, speed, and vague terms like reliable, good, super-duper good, and so on must be defined in hard metrics. We know what'll happen if we don't nail this stuff down, right? You'll get to the end of the project and the stakeholder will say, "Well, this is only super-good, we specifically said this had to be super-duper good. Sorry."
In addition to defining all of the project objectives the project manager has to determine how her project will live under the quality policy of her organisations. In some organisations the quality policy may be nice and vague, like "Quality is job done." Or "The customer is always right if they pay on time."
Other organisations subscribe to quality programs like Six Sigma, Lean Manufacturing, Kaizen Technologies, and ISO 9000 or 10000 programmes. In these systems the project manager must follow the quality expectations of the organisation to show improvements, measurements, and satisfaction.
All of the planning and prevention is really Quality Assurance (QA). QA is a management process that is focused on preventing a lack of quality from entering into projects, operations, and the organisation as a whole. QA is prevention-driven. It's a giant quality umbrella that all project managers must operate under. All project managers must map to QA specifications throughout the project. QA is an ongoing process that helps the project meet expectations.
QA and Knuckleheads
But doesn't QA cost cash? You betcha. We call this the "Cost of Quality." The Cost of Quality is the expense a project, or organisation, must incur to ensure that quality will exist within projects. Imagine that you're a project manager of an Oracle project. You've been assigned a team of knuckleheads that know nothing about Oracle. This crew will be your database administrators for this massive billion-dollar project that could make your career or send you back to the mailroom. Your project team, the knuckleheads, can't even spell DBA let alone contribute to your project. What should you do?
Train the knuckleheads.
Training is one cost of quality; if you don't train the project team then they won't be able to complete the work in the project. Okay, I admit, this is an extreme example, but I wanted you to see that lack of education can cause your project to fail.
Other costs of quality? Safety issues, OSHA issues, union compliance, adherence to regulations and standards, meeting project objectives, and any other expense the project must eat to ensure that project deliverables are accepted by the customer.
When a project cuts corners and doesn't pay for the cost of quality then the project, or organisation, will have to pay the cost of non-conformance. The cost of non-conformance are the monies spent to redo work, buy new materials for those that were wasted, refund customers their money, the loss of customers and sales, fines, and all the other negative things that can happen to an organisation when quality is not delivered. It's no fun. (Uh, I've heard).
Quality Control is Inspection
Alright, so all this planning is good, and it's even better when it all works, but how does a project manager know that project is meeting the quality expectations? You could wait until the very end of the project and see what the customer says, but that's a risky as blow drying your hair in the shower. What you need, what you must have, is quality control (QC).
QC is inspection-driven. QC requires the project manager and the project team to inspect the work that's been done to determine if the work results are in alignment with the stated and implied objectives of the project scope. And if they're not? Fix the freakin' problem.
QC is all about keeping mistakes out of the customers' hands. You and the project team must work diligently to ensure that all of the work is accurate, on-scope, and meets the objectives that customer has defined. And do it quickly. But QC takes time. It takes time to inspect the work. It takes time to redo the work. It takes time to check the work that's been redone. And time is rarely on the project manager's side.
And who's paying for all these inspections? Usually your project is. If we revisit our discussion on planning, the project manager must plan for time to inspect the work and monies for the inspection of the work. If all goes well (and when does all go well?) then there won't be a need for additional funds and time. When projects are under tight time and cost constraints it becomes paramount for the project team to do the work right the first time.
Have you ever wondered why there is always enough time to do the work right the second time? To me, there's nothing more aggravating than barking dogs while I'm trying to write articles (that's for my neighbour behind me - shut your dog up, please). I also find it aggravating, in the project management world, when we've got a fantastic plan on how to do the project work, we've got a fantastic plan on how to meet the quality objectives, and we've got a fantastic plan on how we'll follow-through with all of our promises - and then somebody chokes and turns in slop.
Now everybody wants to quote Steinbeck:
The best laid plans of mice and men often go astray. Don't you just love that? Well, take me out to the field and shoot me.
Now we're redoing work, spending more cash, wasting more time, and arguing about the literary consequences of writers that did or didn't drink too much. All-in-all, lack of quality hurts a project in more ways than one: time, cost, team morale, confidence from the customer, and on, and on.
Sometimes lack of quality causes a domino effect. Have you ever had quality issues that consumed the project team's time to correct? Of course you have. And then what happens? Your project team feels rushed to completed other assignments to make up for lost time, which usually creates more quality problems, which starts the process all over again.
It's always more cost effective, more time effective, and just more fun, to do the project work right the first time. Fun? What I am thinking? This is project management; there ain't no stinkin' fun.
There are plenty of tools a project manager can use to assist with quality control. Here are three for now:
- Ishikawa Diagrams: these are also known as cause-and-effect diagrams and fishbones, but Ishikawa sounds brainier. The point of these diagrams, regardless of the nomenclature, is to facilitate a conversation on why causes and contributing to a problem.
- Pareto Chart: ever hear that 80 percent of your income comes from 20 percent of your customers? Or that 80 percent of your help desk problems come from 20 percent of your employees? That's the 80/20 Principle and the Pareto chart shows the categories of failure within a system. Then we use 80 percent of our effort to attack the largest identified problems.
- Control Charts: A control chart really shows normal distribution and allows us to track trends and adjust our mean when we reach goals and need to set new quality goals. The point of a control chart is that we can track trends over time.
Verify the Scope and Cash the Cheque
QA and QC activities happen throughout the project. Remember QA is a management process that is prevention-driven, while QC is a project manager process that is inspection-driven. Now all of this is really good on paper and theory, but in the real world it comes down to the one person that matters most in any project: the customer.
Throughout the project the customer must participate in scope verification. Scope verification is the same process of QC: inspection. However, the difference is that QC is done before the customer, and scope verification is done with the customer. QC wants to keep mistakes out of the customers' hands, while scope verification allows the customer to say things like, "Yep, looks good." Or "I don't know what I'm looking at, but I believe you." Or, "You're standing too close and your breath smells like onions."
Project deliverables need to be inspected throughout the project - not just at the project's end. As projects move through phases, at major milestones, and finally at project completion scope verification must be performed to ensure that work is of quality and the project is in alignment with the customer's vision.
Quality, like it or not, must be planned, must be inspected, and then must meet the customer's objectives. Now, if you'll excuse me, I'm off to my local pub for a Reuben sandwich and a beer. Hopefully.
Joseph Phillips is the author of five books on project management and is a PMI Project Management Professional, a CompTIA certified Project Professional, and a Certified Technical Trainer. Joseph has taught for the Project Management Institute, the US Military, Fortune 50 companies, and has spoken at international conferences on project management. Please visit Joseph's website Instructing.com