Openness, Trust, and Healthy Paranoia


Trust must be earned in any relationship; it is not automatic nor can it be assumed. You only learn how much you can trust someone over a period of time. The same principle rings true in project management. In this week's column, Peter Clark shares a valuable lesson for project managers and other management professionals, demonstrating that a healthy level of paranoia must precede openness. If openness is premature, one's trust could prove to be unfounded in the end.

A New Relationship Begins
Bob the project manager was excited--his new assignment was a real plum: he would manage the integration of his company's product with his customer's systems, as well as with systems provided by a large consulting company. He would also work with representatives from other divisions within his company to create an integrated plan. The project schedule was tight, and sales was aggressive when they priced the proposal.

Bob scheduled a series of risk management meetings with his team. They identified the top ten risks they wanted to monitor and established mitigation and recovery plans for each risk. They also developed metrics they could monitor that would indicate when a risk was turning into a problem. Bob then adjusted his schedule slack to accommodate risk exposure.

After meeting with the project managers from the other divisions within his company, Bob noticed that no one's schedule showed slack. He argued passionately with the other project managers to maintain a reservoir of slack before key dates in their schedules. He pointed out that schedules without slack were inevitably "best case scenarios," which have high possibilities of not meeting deadlines. In the end, only Bob's schedule showed any slack.

Developing Trust
Next, Bob went to a planning meeting with the customer and the other vendors. The goal of the meeting was to produce an integrated project schedule for the entire management team. Bob attempted to steer the planning session toward using some of the skills he picked up in his training.

The first exercise was in risk management. Bob proudly unveiled the risk management plan he and his team created, and suggested that the entire team use it as a template for managing project risk. Everyone took the risk management plan and agreed to a risk planning session at the next meeting.

Before the next session, Bob and his team reviewed the project risks based on the planning information they received at the first meeting. He came prepared to incorporate new risks into the overall plan. However, the session did not progress quite as he planned.

Two hours were scheduled for risk planning. The first hour and three-quarters was spent reviewing the risk plan Bob previously distributed. The customer expressed deep concern about some of the issues raised in the plan. She specifically focused on items identified as technical risks by Bob's team. She insisted they immediately implement the recovery plans they identified, and she wanted to schedule monthly technical review meetings to check progress.

After lunch, they went into the schedule review meeting. The customer said she integrated the schedules from Bob's company and the consulting firm. She removed the slack, advancing Bob's timeline by two months in a one-year project. Bob protested that the slack is needed to cover for unexpected problems. The customer replied that per the contract, all schedule slack belonged to her. She questioned why Bob couldn't accurately predict how long his tasks would take.

Trust, but Verify
Every project management guide promotes the importance of openness and trust in a successful project. However, trust can't be assumed--it has to be earned. Your customer has to learn how deeply they can trust you, and you have to learn how much you can trust them. This requires a balancing act between trust and a healthy level of paranoia. Your management of the two results in the degree of openness your project will enjoy.

Experienced project managers implicitly trust very little, especially when dealing with an unknown quantity. They typically will assume that the situation is worse than what you are describing. By trusting too much too soon, Bob triggered his customer's paranoia. She assumed that Bob was laying the groundwork to cover his company's butt later in the project.

How do you earn trust? You earn trust by being trustworthy--by making commitments and keeping them. Trust is earned by sharing experience. "Trust me!" is a cliché for untrustworthiness--precisely because there is no basis for trust.

Good communication requires a degree of openness and is required for successful projects. Premature openness can lead to its own set of problems, as Bob painfully learned. Use a healthy level of paranoia to ease into a trusting relationship. Don't try to force the relationship's maturity too fast. Like the Great Communicator Ronald Reagan said, "Trust, but verify."

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.