What’s Your Software Guarantee? (And Why On Earth Do You Believe It?)
What’s your software guarantee?
We get this one all of the time.
“Can you guarantee me the quality, the cost and the time it will take to create something that’s never been built before?”
Sales people love to offer such guarantees because they can quickly calculate their commissions and excuse themselves from the responsibility of execution. Software companies like to fabricate similar fantasies “to stay competitive.”
But you know who loses with this dysfunction? The client, the developers and the product because the first thing to become invisible is the quality.
The guarantee of both the client experience and the product is seriously cheapened when you guarantee the wrong thing. The developer team performs mad late-night dashes near the end of a project (and away from their families, by the way) and the client receives a product (perhaps delivered on time) with compromised quality that starts the technical debt ball rolling. The focus has moved from the product to “the deal.”
Antagonistic relationships form quickly around the adopted contractual practices of the construction industry (have they ever been on time/budget?) And while project dysfunction is even higher in that industry, entrepreneurs, business owners and managers still insist on using that model because they are familiar with how that game is played and oddly more comfortable with the waste it guarantees.
The game itself goes something like this…
Can you give me a fixed bid based on this vauge mound of paperwork I’m giving you?
It could range from a PowerPoint presentation sales pitch to a ton of paperwork that institutes painful change to all parties. Both assume that paperwork can explicitly describe an entire project and that no further learning or human contact need be established in order to deliver an estimate. And yet learning and human contact is at the very heart of creating software. Daily.
This need to treat software development as a pure engineering discipline is misguided, because the non-deterministic nature of both people and technology is involved. Nevertheless, we skirt that issue and demand time, cost and quality with the mantra “I have to know how much to budget.”
So invariably a Sales guy, Software Company or even IT department pulls some figure together from dubious metrics and incomplete information – sometimes without even consulting the developers. They double it, triple it, add the Salesman’s commission and present it to the client (who is also oddly enough aware of this game) and the incessant (and relationship damaging) haggling begins.
At this point, software development has crossed the threshold into a task driven commodity. Clients seek multiple bids and the predictable age-old dysfunction of selecting the middle “guess” is used and we all imagine that a “sensible” decision has been made… We propagate the cycle, expecting different results without employing any feedback loop to measure the waste and maybe change our ways.
Do you engage your clients every step of the way? Do you incorporate daily communication and feedback so that all parties are on the same page of the process? Is the feedback loop continuous and does it work both ways? What guarantees do you think are realistic for clients to ask for?
And the most important question of all…….
Is the product you are generating something that EVERYONE can be proud of?
Well said, Brett. We are seeking to apply these same quality principles to our IT Managed Services practice. Thanks for articulating clear, transferable principles.
Great post, Brett. A failed project will normally provide plenty of warning signs up front, and one of the most common warning signs is improper customer expectations. A client that asks for a guarantee is expecting to transfer responsibility for the project from themselves to a 3rd party. If the project involves agile practices, the customer cannot simply hand off the project to a vendor. Their participation and commitment will be required, and that is too often overlooked during the sales process.
Pingback: It’s Time To Call BS On The RFP Process | SilverFern Software