Openness, Trust, and Healthy Paranoia

[article]
Summary:

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

About the author

Peter Clark's picture Peter Clark

Peter Clark has twenty years of experience in industrial automation. He currently manages teams working in materials handling, especially baggagehandling systems. A regular columnist on StickyMinds.com, Peter can be reached at pclark@jerviswebb.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Oct 12
Nov 09
Nov 09