Devolution of project scope and quality
Let’s just create something!
Beware the “devolution” of your project scope and quality.
Time is running short and the bottom of the project piggy bank is showing. We have to have something to show for all this time and effort and money spent! Now the bright ideas start. Let’s remove this scope, remove these features. We should still get some benefits, right?
When projects run into difficulties, the sense that something must be accomplished, something must be created, we have to have something tangible at the end of the project overtakes all common sense related to the original justification of the project.
Devolution of project scope and quality has its roots in the quality review methods and product approvals needed.
If a product does not pass the quality review method (testing, inspection, etc) and cannot be fixed within the tolerances given then an issue needs to be raised. In PRINCE2 this is called an Off-Spec, short for Off Specification. In the Issue and Change procedure, this situation will be examined and options will be considered.
During the analysis, a common question comes up: What if we don’t fix this and just accept the product as is? This is a double edged sword. It is absolutely an option to consider, however in my experience this is often done in an effort to maintain the existing schedule and not spend any more budget while neglecting the considerations or effects on the rest of the products in the project or more importantly, the effect on the organizations ability to generate benefits.
For example – imagine that an organization runs a test for their help desk employees to see if they are competent in a certain topic.
Criteria1: Exam pass mark is 80% because they feel that the help desk employees should know at least 80% of the topic in order to provide the required level of service to those who call in.
Criteria 2: At least 75% of the employees who take the test to achieve the minimum mark.
After the company has trained 100 people, they notice that less than 50% of the employees are receiving the required marks (80%).
OPTION 1: Change the training programs.
OPTION 2: Make the test easier.
OPTION 3: Lower the passing grade requirement (lower than 80%).
OPTION 4: Lower the pass rate for (lower than 75%)
The criteria has been set to enable the organization to have a help desk that meets the customer satisfaction levels of those who call the help desk. If they cannot meet the criteria set, there is a risk of lower customer satisfaction which is likely to result in lower revenues, lower reputation etc. If the company chooses to change the criteria to lower the required marks, then the downstream effects will not be materialized
A similar thing happens when creating physical products that are supposed to have a certain set of functionality. If there are failures in testing, or issues relating to the length of time or cost it is taking to create all the functionality, often a decision gets made to reduce the functionality so that something gets created.
On occasion, this devolution happens right at the beginning of the project. There is a business need, reasons why this project is needed, the anticipated benefits and a sense of what needs to be created. Once the initiation stage work is underway, it may become apparent that the time/cost required to fulfill this need and create the required products is considerably different that first thought in the outline business case.
But the project has been initiated!!! We have preliminary approval to spend the money described in the project brief!!!! What can we build for this money? Once again, the consideration for the original business need, reasons and benefits is put on the back burner.
Needless to say, if project management worked as it should, this would never happen. Unfortunately, not everyone (other than the PM of course) understands good project management and proper project justification review.