• Increase font size
  • Default font size
  • Decrease font size
E-mail Print PDF

TrustWho Do You Trust?

The first ingredient in recovering any project is trust. The team must trust the recovery manager, the customer must trust the supplier, team members must trust each other, and so on, until all permutations are exhausted. Without trust, all is for naught. Therefore, to have a successful recovery, or project for that matter, it is a requirement to thoroughly understand trust and how to foster it.

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:

  1. Make a list of the people you trust and think about why.
  2. Make a second list of the people you distrust and why.
  3. 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

Delicious Delicious
Add to Technorati Favorites

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.

Tags: , , , ,

Previous Blog Next Blog


0 # Guest 2010-03-08 03:19
Blame is indeed the emotion du jour, but how do you manage it, once the finger pointing has started?

Blame and retribution need to be separated from the task of recovery as quickly as possible, or risk becoming major obstacles. Recovery managers simultaneously need to uncover what went wrong and why. Balancing the two needs is not always easy.

Avoiding the perception of partiality is necessary, but I’ve been in positions where it was definitely a challenge. Managers need solid support from project sponsors and owners to manage well and the stronger the commitment the better their chances are of success. Sometimes I had that support and sometimes I did not. No prizes for guessing which projects turned out best.
0 # Josef Pfister 2010-03-10 09:41
Wonderful insight. I enjoyed the exercise. It really helped me think about why I distrust some people. I came up with these three reasons for my distrust that I thought was worth sharing.

1. Inconsistency: When promises were made and not kept, the first violation was disregarded, the second caught my attention, the thrid raised my concern, after that the trust just dwindled with each inconsistency.
2. Insincerity: Expression made that lacked something that I just cannot put my finger on but send chivers down my spine especially when the actions are showy, public displays.
3. Exhorbitant self-interest: The issue is always about them and even if it involves someone else there is always a payoff for prime party. Very little is done solely for the benefit of someone else.

Thank you Todd for this article. As usual very well written.
0 # Guest 2010-03-13 08:53
An excellent thought provoking article. Thank you for sharing. We work in an environment where it is about the relationship and how that relationship can be developed. Once trust is broken or betrayed, it is much harder to come back to relationship building. It is better to work with the relationship in mind, instead of the quick win with long term damage.
0 # Guest 2010-03-13 10:51
Thanks so much for this Todd! I'm a huge advocate of understanding trust before setting forth on a project. Trust is so easily damaged, and a project manager has to build and continue to develop trust with stakeholders, team members, vendors, and so many other disparate groups. A project manager who doesn't address the issue of trust adeptly ultimately will experience a lot of difficulty getting his project done.

I have a little keynote of my thoughts on trust here:
Why I'd Rather You Go Play in the Traffic

Thanks again, Todd!
0 # Guest 2010-03-14 14:27
Todd, this is excellent! I could only think of one person I seriously distrust, and when I read #3, before even going on, I thought to myself, “There is NOTHING this person could say or do that would allow me to trust him again.” This, of course, is a major point of your post, and an excellent message and reminder for us all!

Thanks so much for sharing!
0 # Guest 2010-09-05 01:06
I enjoyed reading your blog. Keep it that way.

Currently comment rights have been restricted to registered users only. Please try registering and logging on.

Who's Listening To Us...

Fortune/CNN Money logo
Forefront's logo
Logo Oregonian/OregonLive
Enterprising CIO's logo
Slashdot's logo
The CEO Magazine's logo

Read and Hear More...

Visualize Your Future

Change how you do business.

Project Failure Insight:

The following blogs regularly have articles on project failure, recovery and good management practices.
Chris Curran
CIO Dashboard
Michiko Diby
Preventing Project Failure
John Estrella
Dr. John A. Estrella's Blog
Mike Krigsman
IT Project Failures on ZDNet
John F. Moore
Random Thoughts of a Boston-based CTO
Roger Sessions
Simple Architectures for Complex Enterprises

Looking to buy the internationally acclaimed Rescue the Problem Project?

Image of RPP

For a signed and personalized copy in the US visit the book's website.

Not in the US? Try one of these book stores worldwide

Amazon logo
Book or Kindle
Flag of the United States
United States

Flag of Canada

Flag of the United Kingdom Flag of Ireland
United Kingdom

Flag of Germany

Flag of France

Flag of Italy

Flag of the PRC
Flag of Japan
Barnes and Noble Logo
Book or Nook
Sony Reader Store logo
Sony Reader
Worldwide: Many other
book sellers worldwide.

Recent and Upcoming Events

Suggested Books

Many of these books have reviews in the "Books to Read" section of this site.

Agile Project Management: Creating Innovative Products
by Jim Highsmith