Managing Project Quality and Quantity

A lot of software projects are confronted with quality issues sometime in the project lifecycle. Worst is the case when escalation comes from the customer.

My experience so far reveals that when a customer raises a quality escalation, typical approach of a project manager is to initiate rigorous checks and not release the application until each and every bug is identified and resolved. Luc Richard, in his article “The Separation of Church and State” (membership required) at GanttHead.com calls this “Project Mangler” approach. The downside of this approach is that while clients want quality, they would definitely not compromise on the timeline and features required. In the event of a quality related escalation, customer gets extra defensive and seek continuous feedbacks. Features (quantity) have to be delivered, timelines have to be met and quality has to be consistent. How can this be prevented in project planning phase?

Luc Richards suggests that we treat quality and quantity separately by virtue of the types of releases we provide to the clients.

Quantity can be dealt with in major/minor releases – where we provide tested features. That means Release 1.1 would have some more features added in Release 1.0 and so on. Major/Minor releases essentially deal with delivery of tested functionalities in incremental fashion.

Quality can be dealt with in maintenance releases – or “patches” which deal with bug fixes and providing intermediate releases. So, release 1.1 can have multiple maintenance releases in form of 1.1.0, 1.1.1 etc. (This does not mean that Major/Minor releases would not deal with quality – however as we know zero-defect release is a myth and defects coming from client can be dealt with by planning maintenance releases in the project plan)

The challenge is in planning the major/minor releases and the maintenance releases in the project planning phase. While quantity and quality are separated, planning for both happens together. The plan should also be revisited as the project progresses to add more maintenance releases as required during the course of the project. Planning can also specify what elements each of these releases would comprise of.

This strategy clubbed with right expectation management and communication can prove to be very effective. When each release is done, client expectations have to be set. Following parameters can be considered when making a release.

1. Release Details (Major/Minor release, Maintenance Release etc.)
2. Release Coverage (What all functionalities, features, issues, change requests are incorporated in this release – what all is not included)
3. Known Issues in the release (open issues that are being worked upon)
4. Dependencies/Deviations/Constraints
5. Expectations (what client can expect and what is the purpose of release. E.g. an in-development release provided to the client for status update, a major release provided for UAT etc.)

Addressing the above parameters during a release sets the clients expectations and they know what to expect in the release at hand. I have experienced that a lot of post-delivery escalations can be effectively avoided with the strategy above.

Any ideas to take this one step further?