The Setup
You’re hired to deliver an add-on to an existing CRM system that was developed in-house. About half-way through the project, you realize you have to make a decision: you can deliver something on-time or you can deliver something that will delight the customer.
Which do you choose?
Scenario 1: Six months after your project’s delivery date, a customer service representative opens the front-end application add-on built by you and your team. The CSR’s reaction is, “Wow, this software was on-time!”
Scenario 2: Six months after your project’s delivery date, a customer service representative opens the front-end application add-on built by you and your team. The CSR’s reaction is, “Wow, this software rocks!”
Which of these scenarios is likely to occur?
Conclusion
Deliver quality late, no one remembers. Deliver junk on time, no one forgets.
:{> Andy
So where’s part 1?
Lol, will repeat that, just not within earshot of any clients !
Wish that was true, but unfortunately I think that both of them are "no-one forgets" scenarios.
This possibly applies more as an external consultant than internal resource, but if you believe that the client has unreasonable expectations they need to know that, and agree that either ;
a) The project that you are going to deliver has different (at least 1 of 3 !) aims, timescales or budgets. or
b) You won’t be working together on it.
I appreciate your post is essentially humorous, but as a solution consultant I meet a lot of very sceptical business people who have been burned before !
Andy,
While I totally agree with you, the problem is often how we’re incented. Deliver junk on-time, meet on-time goal, get better raise/bonus. Deliver quality late, miss on-time goal, get worse raise/bonus and lots of intrinsic value from the praise.
The problem is that most managers don’t know how to measure us on quality, or they don’t want to invest the extra effort it would take to do so.
I would love to know what your experience has been with measuring quality…
Thanks!
I wish I lived in a "quality" counts world…
Unfortunately reality is "Git er done!’ or someone else will be used next time..
I remember reading one of the O’Reilly Perl books and laughing at the truth of one observation in it that went something along the lines of "the challenge of a skilled technologist is to strive to go in the direction you know is correct without getting fired".
A lot of times in IT we KNOW what the right course of action is, but it is difficult to impossible to explain it to others. In a world where we sometimes have to bill every other six minutes to a specific client bucket, long term thinking – let alone stretching to achieve quality – can be a daunting risk.
thanks for the valuable information, this blog is really informative.
The real problem is that You can loose LOTS of money without quality. If You want examples let me know
"Deliver quality late, no one remembers. Deliver junk on time, no one forgets."
Sad (?) but true.