"Delivering uncommon results in software culture"

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?  

About the Author
I’ve had the good fortune to travel and work internationally. I’ve also had the good fortune to have grown up in New Zealand and have lived the American “immigrant experience” for more than half of my life. I’ve also had an unorthodox musical journey that led me to and kept me in Kansas City. Music, IT and travel became partners along the way helping me appreciate multiple worldviews and the concepts of cross-disciplinary approaches to life and work. My non-conventional experiences reflect my meanderings about this interesting occupational field. The beauty of having been in IT for 30 years is that our solutions become predictably cyclic while our problems remain the same. Culture is a topic I’m rather obsessive about. I firmly believe that it will help to usher in a renaissance in American business – oddly enough in the hands of IT.
  1. Tom Crimm Reply

    Well said, Brett. We are seeking to apply these same quality principles to our IT Managed Services practice. Thanks for articulating clear, transferable principles.

  2. Ron Montgomery Reply

    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.

  3. Pingback: It’s Time To Call BS On The RFP Process | SilverFern Software

Leave a Reply