Quality Is Not an Accident
In project management, as with most things in life, quality is planned in, not inspected for after the fact. 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 world 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?
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 the project manager have to define all the business details that'll make them happy when the project is complete.
All metrics, such as thorough, data consistency, speed, and vague terms like reliable, good, super-duper good, and so on, must be defined in hard terms. 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 whether her project will pass the quality policy of her company. In some organizations 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 organizations subscribe to quality programs like Six Sigma, Lean Manufacturing, Kaizen Technologies, and ISO 9000 or 10000 programs. In these systems the project manager must follow the quality expectations of the organization to show improvements, measurements, and satisfaction.
All of this 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 organization as a whole. QA is prevention-driven and it's sort of like a giant quality umbrella that all project managers must operate under. All project managers must map to previously determined QA specifications throughout the project. Remember, QA is an ongoing process that helps the project meet expectations.
QA and Knuckleheads
You're thinking, “:But doesn't QA cost cash?” You betcha. We call this the “:Cost of Quality.” The Cost of Quality is the expense that a project or organization must incur to make sure 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, but yet this is the crew that will be the database administrators for a massive billion-dollar project that could either 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 of the costs 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 definitely 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 the project deliverables are accepted by the customer.
When a project manager cuts corners and doesn't allow for all of the necessary costs of quality then the project, or organization, will have to pay the cost of non-conformance. The cost of non-conformance are the monies spent to redo work, buy replacement materials for those that were wasted, refund customers their money, eat the loss of customers and sales, pay fines, and take care of all the other negative things that can happen to an organization when quality is not delivered. It's no fun. (Uh, at least that's what I've heard.)