An Exercise In Understanding Trust
Not too long ago, I was at a Portland SIM CIO Summit where a keynote speaker spent all of five minutes talking about trust. However, these five minutes left me with a very different view of the subject. Rather than defining trust, he wanted the audience to leave thinking about it.
He gave us a three-step assignment. I suggest you try it, too. He asked us to do the following, pausing a few seconds between each:
- Make a list of the people you trust and think about why.
- Make a second list of the people you distrust and why.
- Write down what it will take someone on the second list to regain your trust.
Being that the last question was rhetorical, he answered it for us, "Nothing, they never regain complete trust." In closing, he threw in the kicker, "So, whose trust list are you on?" He let the latter sit in for a few seconds and went on to his next topic.
The Components of Trust
Trust requires that we expose some part of ourselves, creating vulnerability. At first, one might think that this would make us uncomfortable. However, trusting someone does just the opposite. In fact, turning over trust is huge part of falling in love.
Project managers leave themselves exposed by allowing others to define and monitor their progress or self-assess their capabilities to perform a task. Executive management trusts that the recovery manager will fix the project in a manner amenable to all parties. The person giving the trust is exposed to negative consequences if the trustee fails. Without trust, one person has to do everything and the project stops.
Every act in a project requires trust. Simply to start the project, the customer must trust the integrator and the vendors. Without that, the project will not succeed.
However, trust has bounds. You may trust the teenager next door to baby sit your children, but not to keep track of your investments. For this reason, projects have people that specialize in various portions of the business. It is up to the trusting party to perform the due diligence to establish the appropriate level of trust.
Destroying Trust
Trust can vanish in an instant. Not following through with commitments, failing to provide all the information required, or laying blame can destroy trust that has existed for years. The first two can be forgiven, since they can be honest mistakes. The latter, blame, can be the death knell of trust. In failing projects, blame is the emotion de jour. It not only destroys progress on the project, it thwarts any attempts at recovery.
When looking at the aggregation of failed projects, vendors, customers, and integrators share culpability. Commencing a recovery (or a project, for that matter) with anything but an objective view of the genesis of failures, or their corrective actions, is counterproductive. Every project is different and, in the course of recovering a number of them, no single party has come out the winner for contributing to failure. To be sure, as many projects fail for customer ineptness, arrogance or any other problem, as there are that fail for the same reasons in vendors and integrators. Starting any action with blame only breeds mistrust.
Hence, blame serves no purpose. Corrective actions solve issues; trust is required for the corrective action to work. None of the parties in a project is more prone to contribute to failures than any other. Assigning blaming will only escalate the blame-game when another group generates the next failure. Resolutions are found quicker when fault is shared and each party works to identify and resolve the problems.
What To Do
To move forward on a failing project, trust must be regained. An honest and objective recovery manager is required. It starts when people back away from finding blame and replace that with looking for solutions. Open communication, trust, and assuming positive intent is the attitude to build lasting relationships and successful projects. By accepting the responsibility to objectively analyze the issues and correct problems that are under their control, the project will once again be successful.