When Trust Goes AWOL

we delivered on time). We also hoped that at the end of month six they would be in a position of "proving" the software works rather than trying to prove that it doesn't.

It was an offer we thought too good to refuse, and the new approach seemed to appeal to them-in principle. One of the biggest problems with the relationship was that my client had released product upgrades before all of the bugs were ironed out. Accordingly, the customer, which ran billions of dollars worth of financial transactions on the system, spent a small fortune and many months on acceptance testing each software upgrade before trusting it enough to be used. The saddest thing was that the situation turned nice people, with a mutual objective, into enemies. Each release had an unpleasant "them and us" feel about it, with each side focusing less on the mutual goal of delivering high-quality software, and more on shielding themselves from blame and proving the other side was wrong. The senior stakeholders on both sides lost a lot of sleep as the relationship continued to sour.

I'd like to report that we saw an instant transformation in the relationship-that our sturdy logic pushed the trust lever up to full strength-but it didn't. At best we saw a slight thaw, but we still had several years of broken promises behind us. All they had was yet another promise that things would get much better, much like the promises they had heard before from my client.

The thaw sped up a little once we stopped explaining ourselves and started listening to their questions and concerns. How would things work in practice? How would they know that we were keeping our promises? How would they know that the quality was as good as we said? Could they see the tests? Could they really start testing so soon? What if there were problems?

As a result of these questions we promised to give detailed, written reports daily and to have daily progress teleconferences. Although we were happy to give report daily, we would have preferred less detail. We also would have preferred to have several daily conversations rather than one formal teleconference. But both of these requests stemmed from starting with low levels of trust and also from having to rebuild trust.

Perhaps the best thing we did that day in terms of building trust was to insist that we got similar commitments from our customers regarding the levels of collaboration we needed from them in order to deliver to schedule. It was clear to both parties that we shared a mutual purpose-to deliver the project-and that the most cost-effective way of doing this was by working together. We also made it absolutely clear that without continuous collaboration we would have to re-plan the project and extend its schedule by several weeks by adding a "rework" phase at the end of the project. Most important was that working collaboratively would mean that we got to know each other better.

The best way to build-or rebuild-trust is to act in a trustworthy way. I only needed to see my mobile's alarm clock work properly once before I trusted it and thereafter I slept soundly, but it takes longer to build trust in people. Trust grew on my project as soon as our customers saw the automated acceptance-level tests, which we had created together as a team, running. They got as much of a thrill when they saw the pages of green tests as we did.

Trust grew more when we shipped working software-software that came complete with the