In my post, “The Five Variables of Project Management”:http://www.magpiebrain.com/blog/2006/06/25/the-five-variables-of-project-management/, both “Marty”:http://www.magpiebrain.com/blog/2006/06/25/the-five-variables-of-project-management/#comment-1790 and “Richard”:http://www.magpiebrain.com/blog/2006/06/25/the-five-variables-of-project-management/#comment-1800 used the term ‘quality’ rather than my prefered term ‘process’. I didn’t do a good job of justifying the term process in the post, so felt a follow-up was in order.
I felt that an example would help explain my thinking. To use a not-that-theoretical situation, let us imagine a project, where the average piece of functionality takes one day to implement, and 1/2 a day to create a user-interface test. Let us also say that on average, each piece of functionality introduces 1/8 a day worth of bug. The QAs believe that too much time is being spent on automated testing, as they end up checking everyhting maually anyway to pick up problems with the automated tests. The team decides to try not creating automated acceptance tests which drive the UI, and instead create functional tests which drive the domain model rinstead, which is quicker. As a result development is faster, and the increased speed of delivery outweighs the increased bugs picked up during manual testing.
What we’ve done is is change the _process_ to increase delivery speed. What we haven’t necessarily done is decrease the final quality of the product.
Let’s pick another example. We spend a month or so gathering requirements. Then we spend a month or two developing requirements, only to find the customer has changed their mind – business priorities have changed. We then have to spend time undoing what we’ve done. We decide to change our _process_ by spending only a week gathering requirements followed by two weeks of development. This means we reduce the chance of being affected by our customers changing their mind, and if they do we only have a a couple of weeks work that could be affected, rather than a couple of months. The net result is that we deliver faster – we’ve changed our process to increase delivery speed, but we haven’t changed the quality of the final product.
Changing process _can_ affect quality, but changing process is about more that _just_ changing quality.
magpiebrain 
One Response to “‘process’ rather than ‘quality’”
Thanks for clarifying this Sam.
I had thought of “quality” slightly differently, being defined by questions like the following:
“do we make sure this web site runs in an obscure web browser that 0.05% of people use?”
“do we ensure all the dialog boxes in the application have buttons that are the same size and neatly aligned?”
“does it matter if the application fails in the unlikely event that 5000 people use it at the same time when it is usually used by 50?”
The answers to these questions will depend on the people using your application. For an application used by a small number of technical people, having buttons neatly aligned might not be necessary and the development time would be better spent adding an extra feature.
I agree that changing the process can improve quality without compromising the other variables. If our process includes checks to ensure everyone uses standard features of HTML, then our application will work in our obscure browser. If our process uses standard templates to build dialog boxes, then the buttons might be neatly aligned. If our process insists on good exception handling, our database might be able to fail gracefully and recover under a high load. Changing the process can also increase the amount that is in scope, reduce development times, reduce the numbers of people necessary and reduce risk.