Quality Management

I have seen that many people often struggle with quality management on big development projects. The reason they often have a hard time in this area is not because they don't know how to manage for quality, or what quality is, rather the problem is that they have to define quality so early in the process.

Sorry for being quiet for so long. I have been traveling around the country teaching both state and Indian Tribe users as well as internal government people how to use my new application. I find it hard to write when I'm on the road like that. I need to be in my routine to get it. I feel like I'm now back in my routine, at least for a little while, I have some additional travel coming up, but nothing like the last few weeks.

Anyway, quality management. Remember, I'm approaching this from the perspective of a government PM, so most of the development work is performed by the contractor. When we award that contract we want to have the vendor be a part of the process defining quality. That is a terrible mistake because their version of quality may be different from your version of quality. And if you discover that difference after the contract has been awarded, guess what? You can have your version of quality, but we'll need a change order and a cost adjustment.

The reason so many good people fall down on quality management is because you have to define it to a fairly high level of granularity very early in the process. In fact, you have to define it and set it in stone before you even start working on requirements. What I mean is that you need to define quality in your Statement of Work, and you need to be very deliberate about it. Here is how I do it.

I develop a section of the SOW called "Performance Standards". This is a common section in a performance-based contract. Also remember that most of my contracts are Firm Fixed Price as well. That means that only 5 of the 6 dimensions of Project Management are in play for my projects, Quality, Schedule, Satisfaction, Risk and Scope. I don't have to worry about Cost in FFP. Additionally, I manage risk discretely. So I literally create a table with each area of service and make Quality, Schedule, Satisfaction and Scope the column headers. It looks like this:

Requirements Gathering Sessions
Quality - Stakeholder comments are implemented and functions need not be revisited.
Timeliness - RAP materials are available at least 2 days before the RGS. Meeting minutes are available no more than 2 days after. RGS are held on the day indicated in the project plan.
Satisfaction - Stakeholders are able to achieve consensus with the consistent process.
Scope - By the end of RGS, Activity Diagrams, Use Cases and a Requirements Baseline has been agreed to by consensus of the stakeholders.

I then have a Deliverables Table in the following section that describes the Quality, Timeliness, Satisfaction and Scope of each deliverable. I go through each of the service areas like this and objectively define them so that offerors are able to assemble a high-precision bid and everyone is on the same page in terms of expectations.

The reason this is difficult for some people is because you must define it so early in the process. Do not shy away from it though. You need to do it this way if you want to avoid problems later.