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.