Sliding to Disaster
February 14, 2012 | Author: PM Hut | Filed under: Performance Reporting
Sliding to Disaster
By Jed Simms
A tool gaining popularity is Rob Thomsett’s sliders.
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 up on one option must be met by a corresponding movement down on another.

The six sliders cover:
- 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 it to perform/work?
- Team satisfaction: Will you feel warm and fuzzy if the project team are happy at the end?
Now remember, any movement towards “Yes” must be countered by a corresponding movement towards “No”.
This is surely the ultimate substitution for project performance!
“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 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 dimension reflects the project team (team satisfaction). Within bounds, the business is not interested in ‘team satisfaction’. Did the team have a good time? Is not a business measure of success. (This is not to say that managing team morale and productivity is not important.)
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 measure of success is “Did the project deliver the agreed (hopefully optimized) business outcomes so as to enable the full realization of the associated benefits?” There is no sliding away from this measure.
Certainly there will need to be compromises at times — but these should be trade-offs in relation to the value the project is to deliver.
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 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 and alternative options. These six sliders are not alternatives, which is the fundamental problem with the model. Rather than compromise at the outset, let’s focus on delivering success and the realization of the business benefits.
Jed Simms is a former Regional IT strategist with The Boston Consulting Group who, for the past 15 years, has run his own consultancy. Capability Management, specializing in dramatically increasing the value generated by each and every project. The creator and author of a complete suite of value delivery management tools at http://www.valuedeliverymanagement.com/ he has published three books, several ebooks and over 100 articles.
Value Delivery Management is designed as a rich repository for all those involved in project delivery. It has a special focus on value delivery management — ie increasing the value realized by projects — plus a special emphasis on equipping the business to perform their role on projects so as to reap the benefits and make the project manager’s life easier.
No comments yet.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.











