We had the premier project for the organization and we were determined to finally get a product out on-time and with good quality. We did it, and in doing so highlighted how many of our rules were not really helping us to complete a quality project.
Our first major milestone was to pass the criteria to start fully integrated system test. The normal procedure was to start “testing the water” of how well the product was doing at about six weeks prior to the point we had to pass the quality criteria. We had changed that time period significantly with an improved schedule by having observed that previously the six week period actually ran something like twelve weeks. Since we had set a realistic overall schedule, we had the time to put in a period of twelve weeks for the duration of getting all the development integration issues worked out without impacting the overall schedule.
This period of time leading up to this system test readiness milestone was always one of the most intense times in any project. It was always a mess and we always, yes always, never passed the quality criteria for starting system test. Instead, we continually “reinterpreted” the criteria or limited the evaluation period to some arbitrary time where we would have few enough defects that, for the moment, we could pass the criteria.
This time however, while it was still very challenging, we passed just about all the criteria with a fair amount of breathing room. To do this we had to stop the teams from applying all the “interpreted and compromised” criteria. I, as the project guy — who supposedly benefited from modified criteria — had to insist that nothing be waived or interpreted and that we apply the full criteria to the full period. Even the test and quality folks were shocked at my request. These folks were usually the advocates of using the full criteria while we — the product and the development teams — were usually the “we want an easier interpretation to meet our schedule” demanders.
We passed the system test readiness criteria. This was the first time any project passed the criteria on the first try. My boss who had been doing these kind of projects for many years and had all the premier projects in the company said it was the best results he had ever seen at this point in a product’s development.
The point to all of this, without going into the details of the quality checklists, was that once we did away with the real problem — the unrealistic six week schedule in this case — many of the quality review checklist items that had been built up over the years became irrelevant. They tested all sorts of criteria to ensure that the product was ready to move forward, but in fact these checks were just in response to a compressed schedule and everything that could go wrong from such compression. We can break any process, and we did most of them, by just scheduling too little time. These checklists ultimately made no real impact in helping us to combat the root cause. Instead, a culture of “adjustment” arose around them and negotiations and political arm twisting were the key activities during this period, and not how we could improve the quality of the product (i.e., we argued about the checklists and their meanings and not the defects).
If our reaction to problems in our projects is to add more rules and more people to look over the shoulders of those doing the work, then we are probably not dealing with the root causes of the problems. If the problems seem centered in “people just keep making mistakes” then we need to take another look at the overall process and see what is really causing all these capable folks to make mistakes. Fixing the root cause will reduce the mistakes and also lessen the number of people and rules we employ to try and fix these activities.
Do all your project management and quality rules add real value?