A tool gaining popularity is the concept of mutually exclusive ‘sliders’ as quality controls.
The idea is simple: there are six sliders/options that measure project success with a scale of 1 (low) to 5 (high).
At the outset of the project, the business is asked to rate the relative importance of each of the six options with the caveat being that any movement upon one option must be met by a corresponding movement down on another.
Sliding Into Disaster?
The six sliders cover (the explanations are mine):
- Stakeholder satisfaction — Do you want to be satisfied with the outcomes of the project?
- Deliver on time — Do you want to receive the project to schedule?
- Deliver on budget — Do you want to receive the project at the agreed cost?
- Deliver planned scope — Do you want to receive all that you said you wanted?
- Meet quality requirements — Do you want the solution to perform and work?
- Team satisfaction — Will you feel warm and fuzzy if the project team is happy at the end?
Now, remember, any movement towards an emphatic “Yes” must be countered by a corresponding movement towards “No” on another slider.
This is surely the ultimate tool to undermine project performance!
What this is saying is, “Mr/Ms. Business, we are about to take your $x and in return we want you to commit to being happy with a poor quality result that you agreed on upfront to be dissatisfied with. But know in return that the project team had a great time.”
Interestingly, project practitioners welcome this model but complain that only one dimension reflects the project team (team satisfaction). Within bounds, the business is not interested in ‘team satisfaction’. Whether or not the team has a good time is not a business measure of success. (This is not to say that managing team morale and productivity is not important.)
The Need To Refocus On Business Success
This model seems to me to be evidence of how far away we are getting from what projects are all about — delivering business outcomes and their benefits.
The business measure of success is “Did the project deliver the agreed (hopefully optimized) business outcomes to enable the full realization of the associated benefits and value?” There is no sliding away from this measure.
Certainly, there will need to be compromised at times — but these should be trade-offs vis-a-vis the business value the project is to deliver. For example:
- A time overrun impacts when benefits will be realized – that’s the trade-off.
- A cost overrun impacts the net value of the benefits – that’s the trade-off.
- A quality or scope compromise will reduce the business’ ability to realize the benefits in full – that’s the trade-off.
- A stakeholder satisfaction compromise may again impact the level of benefits realized.
Insofar as these decisions are necessary they need to be made with quantified numbers that spell out the value impacts of alternative options.
These six sliders are not alternatives, which is a fundamental problem with this model.
Rather than install a process to encourage compromise at the outset, let’s focus on optimising and then delivering the business results and returns to ensure the full realization of the business benefits.
Is that too much to ask?