The Three P’s of a Quality Management System

A Quality Management System, sometimes referred to as a Total Quality Management (TQM) System, is a simple concept that will dramatically improve software production quality over time.

Companies that don’t have a quality system are commonly reacting to production and support issues due to omissive events.

A simple rule of thumb is to ask yourself how many fires your development team has put out this month.  If any come to mind, then chances are you don’t have a proper quality management system in place, and should read on…

I remember early in my career I struggled to get my employees to follow our procedures.  Whenever we’d encounter a production problem with our software, it would inevitably be a result of someone not having completely followed an established procedure.

We would have a big discussion about what should have happened, and about how “we can’t forget to do that next time,” yet we’d experience the same omission later.

I would get frustrated because I could never seem to find a way to get my team accountable for following our established procedures–until I discovered the “Quality Management System.”

A Quality Management System has the following three elements (the Three P’s!):

  1. Process (documented–most of us have processes or procedures we are supposed to follow.)
  2. Proof (a separate checklist, or “receipt” that the process was followed for each software release.)
  3. Process-Improvement (a discussion, and then an addition or adjustment to the documented process.)

Most companies have an established–and hopefully documented–software development process.  (If you don’t you can download one from my website for Waterfall, or Agile here.)  This is the first ‘P’ and should be in place at every established development shop.

A great question to ask the team is “How do you know the process was followed for each release?”  This is where you may get the deer in the headlights response.  This is the second ‘P’ and is the piece missing from most software development shops.

Think of this ‘Proof’ document as a checklist accompanying each software release.  The checklist would include every major step in the documented process, names of team members performing specific functions, and locations of final source code, test scripts, install files, etc.  The checklist would also require a series of quality checks.  Ie: Were requirements signed off by the customer, stakeholder, tester, and developer?  Was the help file updated with the new release number and appropriate functionality?  Was the source code checked in?  Where is it located?

As problems occur, the checklist would be added to so that the product would be protected against a similar failure in the future.

The governing driver considered here is that one particular problem might broadside the development team once, but after the process is improved, that problem should never occur again.

For example, you might have a stored procedure that goes into production without a “Go” statement at the end.  After the error is discovered, and fixed in production, your team should have a discussion and conclude that a checkbox needs to be added to the quality document stating “All Stored Procedures Confirmed to have ‘Go’ at the end.”

From that point on, whenever a stored procedure is moved into production, the developer presenting it must check for ‘Go’ statements at the end and then sign their name at the bottom of the checklist.

This is the difference between process improvement, and hope.  Many companies view process improvement as a discussion and some verbal affirmations.  What they are really doing is “hoping.”

Actually, the “act” of process improvement is physically altering a written process or procedure.  This is the real definition of process improvement–the third ‘P.’

The final endpoint of a quality management system is to achieve excellence.  I’ve heard excellence defined once as “Crisp execution of established procedures.”

You can’t have excellence without procedures, proof, and process-improvement.

Mike J. Berry

The Bat-Phone

Do you have one of those executives that harasses you with status updates to projects, yet never attends the status update meetings?

Perhaps they call you, email you, stop in to your office, and want to know what the latest on project X is?

Is the behavior efficient?  What suggestions do you have about how to convey project status communication within your organization?

Mike J. Berry


I was sitting in a KFC eating lunch, reading the slogans painted on the wall.  This particular KFC is supposedly the first KFC in America.  Yes, it’s in Utah.  Along with some chicken legs and a drink, you can enjoy a small exhibit showing Colonel Sander’s original briefcase, white suite, shoes, etc.

One mural read, “Somehow we’ll do it, by the principles of thrift, honor, integrity, and charity.”

I thought for a moment.  Some of the financial service companies I’ve worked with would fail if they valued charity.  Then I thought about how trust is a wonderful interpersonal dynamic, but the companies I’ve worked with in the medical field allow no latitude for trust.  Everything must be written down and authorized by a credentialed physician.  Walk into a pharmacy and you’ll need a signature on piece of paper to get a prescription filled.

Hmmm, just like charity is an anti-value in the financial services industry, trust is an anti-value in the medical industry.

I spent the day thinking about this new concept.  I owe the title of ‘Anti-Value’ to the Discovery-Channel documentary about Anti-Matter I was watching the night before.  I  guess I’m coining the phrase here, but it makes a lot of sense to me.  Normally, a value is something our society charishs, yet in a particular situation, or line of business–it becomes the wrong thing to do.

I started seeing how this concept can be applied all over to help clarify the decision making process.

I remembered taking third place instead of second in a Maryland school-district programming competition in high school because I let the guy from our rival high school cut in line in front of me to turn in his test.  When the results were announced we had both scored the same grade, but because he handed his paper in first, he won second place and I won third. (I beat him in the State programming competition the following month.)

I’ve never forgotten this experience, and actually now that I think about it, offering your competitor any leeway is an anti-value.

Some business meetings I’ve been involved in are a collage of participants cutting other participants off mid-sentence to make their point known.  Rude? Yes.  But, in fact, politeness may be considered an anti-value in these types of situations.

I think the concept is fascinating.  Just as a good value system should be in place to help an organization, department, team, or individual govern their decisions, an anti-value system can compliment a value-system by providing additional clarity for the decision making process.

One example of this is the U.S. government’s policy on dealing with terrorists.  The government values having a “no negotiating with terrorists” policy.  As a disincentive to future terrorism, they have an additional policy to provide or produce exactly the opposite of what the terrorists are demanding.  The notion–to give them what they want–really becomes an anti-value, and is an additional input to the decision-making process.  So, in fact, their policy is set by values, and anti-values.

I hope you find this concept as fascinating as I do.  It was the best $7.79 I’ve spent on lunch in a while.

Mike J. Berry