Producing Trust

Last time (in the context of being trusted, and what a business must do to re-establish trust), I talked briefly about vendors who announce software years before they plan to ship it, including firms that never ship what they’ve announced and taken payment for.

On occasion, early announcements are a legal requirement for some businesses. IBM and the terms of their consent decree, for example.

Delivery problems can be made worse by substantial changes in market conditions that can make the announced product irrelevant. In some cases, a failure to deliver is irrelevant because the product is so late that it no longer matters. The totally rewritten Netscape is one such example.

Sometimes the product doesn’t meet the expectations it originally set for potential customers even if market conditions havenâ??t changed. On very rare occasions, a failure to deliver is intentional/fraudulent but that’s for legal blogs to discuss.

How do delivery problems happen?

Delivery problems are frequently born months or even years before they reveal themselves. They happen because the firm involved has internal development (yes, management) problems.

While hidden, these problems can lull a business into taking advance payment for a product that they cannot dream of delivering in the short term – even though their intention is to do just that.

Symptoms of a software business with development problems can include:

  • Inability to deliver a consistently high quality product.
  • They can’t name a date and deliver on that date occasionally, much less time after time.
  • They don’t know with any confidence if they will ship on a particular date until that date is too close to do anything about their ability to reach it.
  • They fail to design to a detailed enough level of granularity and get surprised during the development process, finding that something allocated to two days or two weeks instead requires four months of work.
  • They fail to focus on the task at hand and occasionally find themselves chasing a “bright shiny object” that has at best a tangential relationship to their announced product goals.
  • They work in a vacuum (insulated from their industry and/or their client base) and because of a substantial design/strategic product miscalculation, it is months or years before they discover it.
  • If they accept customization work requests for their core products, it tends to appear “duct taped” on, rather than designed-in.

Businesses that experience one or more of these issues simply haven’t decided to do enough enough to ensure compelling levels of consistency in the product they produce. They haven’t decided (or don’t realize they need) to focus only on the things that ensure an on-time delivery of a quality product. In some cases, they may not even be sure what “on-time” will be.

These things are not “just how it is”. They are decided.

Trust that upgrade?

Think about the one software package you use more than any other. Doesnâ??t matter whether itâ??s a development tool (like XCode or Visual Studio), an accounting package (QuickBooks?) or a firmware upgrade for your CNC machine.

  • Will you install the next upgrade without first checking to see if someone else has done the bleeding for you?
  • Are you confident that you can install the next upgrade right away, or do you wait a few days or weeks to see what the fallout is?
  • Do you install new upgrades right away with strong confidence that itâ??ll be solid?
  • Do you install and then spend a pile of time testing obvious things to make sure they still work?
  • Do you routinely wait for someone else to â??do the bleedingâ? for you before you decide to install or not?
  • Is it common to have to “back off” an upgrade because it broke too many things?

Put that hat on your customers.

What do they do?

Do they install what you ship on the day you ship it? Or do they put off updates until they have no choice – such as when industry specification and/or governmental rule changes require use of the upgraded version.

That’s an indicator of their trust in your development and testing process. In YOU.

Problems like this aren’t just about software businesses and aren’t about upscale quality. It’s about management consistently doing the things that create trust. This kind of trust applies to plumbers, coffee roasters, political candidates and construction companies – and many others.

You trust that even the cheapest generic milk from the store won’t have hair or bug body parts floating in it. You trust that when you flip a wall switch, the power will come on.

To produce high levels of trust in your work requires a decision: “We will do what it takes to become (or remain) the trusted party.”