As described for us by Brian in The Delicate Balance, every project must balance the requirements of cost, schedule and quality. He explained that these three attributes of a project should be prioritized and adhered to throughout the lifecycle of the project.

Although rarely admitted quality is most often not the highest priority during application development. If it was then the project would have an un-restricted budget and the application "would be ready when it was ready". This does not mean that quality is not important to a project. The project should be of the highest quality given the constraints of the budget and delivery schedule. If I have $20K to spend on a new car I'm not buying a brand new BMW, I'm shopping at the VW dealership.

This understanding requires project management to consistently build the highest quality into the deliverable - without exceeding the budget or the delivery date. This can be difficult based on situations that develop during the project lifecycle. Unexpected technology restraints, design failures, team member availability, and errors during Integration Testing are examples of situations that will impact estimates of time and resource requirements. Depending on the ability to acquire more financial resources and the luxury of additional time, these events may cause project management to lower the amount of quality that is achievable for a project deliverable.

Given this possibility, on every project it is imperative to structure the project life cycle to not have an obvious shift away from quality. Depending on if cost or schedule is the driving priority, the project must be driven with a level of quality to meet the restrictions of the true highest priority without sacrificing quality when delays occur in the project.

Consequences of disregarding this reality cause the injection of additional risk into a project. It is possible to emphasize too much quality at the beginning of the project and therefore be unable to deliver the application due to the end of available resources. Inversely, the quality of the project may be diminished to a point that delivery is achieved but the product is unusable.

Obviously both of these scenarios must be avoided. The best way to avoid these issues near the end of the project lifecycle is to agree on the level of quality that will be maintained throughout the project. This level can then be built into the project estimates to ensure the needed resources have been allocated to the project. It is imperative to also build this level of quality into issue resolutions that cause unexpected delays. Of the three attributes, quality is the most illusive to quantify and therefore is the most susceptible to be diminished during the final stages of the project lifecycle. Consequently the best way to avoid diminishing quality of the product is to agree on a quantifiable approach to quality during project estimation. This approach can then be applied to each deliverable item and risk assessment and hopefully help the project avoid the loss of quality in the final weeks prior to delivery.