TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPass
Home  >  Detail: Openness, Trust, and Healthy Paranoia



A StickyMinds.com Original
Article Picture
Openness, Trust, and Healthy Paranoia

By Peter Clark

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

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.


McCabe Software
 

 
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

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

Back to Top
 
 


Member Comments
Add Your CommentExpand Comments
 
Comment:    
by George Giles 7/20/2005

The fundamental tenet of any project plan is a meaningful work breakdown structure based upon previous experiences from successful practitioners, as what has worked in the past, is likely to work in the future. This requires requirements gathering, analysis and design, also known as hardwork. This requires a committment from management to support the results of the hardwork in the face of criticism from many quarters. It also requires the committment to execute according to plan, subject to reasonable risk constraints and changes from derived requirements. This is the basis of the trust contract between customer and supplier, for the...Read On

 
 
Comment:    
by Gene Fellner 7/19/2005

Americans are just dismally poor at time management. We're clueless and optimistic with project estimates, then we make matters worse by not effectively controlling schedules and letting them slip even when nothing's really going wrong. When something finally does go wrong, it's hopeless. So we expect everybody to start putting in extra time, without realizing that they already have been, just to meet the original schedule, and there's nothing more to give. The only way to deal with us is to decompose the slack and factor a little of it into every single task so we don't see it. Of course it would help a lot if Tom DeMarco had chosen a more...Read On

Author's Response:
7/19/2005    
I am afraid that I agree with your assessment of the cluelessness of most organizations to managing project schedules, as well as their ability to estimate. I disagree with your prescription, however. The problem that I see with expanding the duration of tasks is that there is a propensity for work to expand the time available. This can make problem worse, not better. I have found it better to roll up the slack into a task prior to key delivery dates, and make the durations somewhat aggressive but do-able. What I aim for is a 40% probability of hitting the date for a task. I then track progress on the task by regular one-on-one communication with my staff where we go over "inch-stone" deliverables for the task. I also agree that mandatory overtime to solve scheduling problems is a sign of a sick project management culture. For an extended rant on this topic (along with my prescription), please see the Better Software article "Saving a Sinking Project" (February, 2004)

 
 
Comment:    
by Francis Fish 7/19/2005

Interesting this. When I worked at (no names, but big company that has delivered a lot of projects over the years) we always worked on the basis of a 4 day week, particularly on long projects. A lot of our customers tried to tell us not to do this but we had contractual control over our resources. It was always true. Another was "testing takes 40% of development time" - I've never seen it otherwise in a waterfall-style project. We didn't "trust" our clients in the naive way you give here - we just told them when things would be ready, and stuck to it. Then they believed us next time.

Author's Response:
7/20/2005    
Hi Francis - You bring up a very good point concerning converting estimates to schedules. It is foolish to think that an individual will be 100% available to work on a project. Other distractions arise - lost time due to illness or vacation, emergencies on other projects, or support of previously installed projects. This needs to be factored into the schedule some way. In your example, a forty hour task wouldn't take a week, it would take a little over six days of calendar time. I am somewhat unclear what you mean by "testing takes 40% of development time". Are you referring to calendar time or budget? By development time, are you referring to the duration it takes for construction, or for requirements / design / construction? We estimate testing as a separate task based on the volume of changes required to be made. Development of the test plan, test cases, test scripts and test environment proceed in parallel with the remainder of the development effort. Execution of the test plan typically takes about six to ten weeks, for a project that we have spent the previous year on.

 
Back to Top


Marketplace

RESOLVE SUPPORT ISSUES from your Desktop!
Minimize downtime with a remote support solution that lets you resolve issues right from the desktop

See how EASY REMOTE SUPPORT can be. Try WebEx FREE!
DELIVER SUPPORT MORE EFFICIENTLY. Remotely Control Applications. Leap Securely through Firewalls!

SOLVE SUPPORT ISSUES on the First Call!
REMOTELY CONTROL AND CONFIGURE SYSTEMS. Easily install applications, updates. All from your Desktop!

IMPROVE YOUR SUPPORT EFFICIENCY
WebEx lets you remotely control, configure and install applications and updates more efficiently.

Census: Web-based Bug Tracking and Defect Tracking
Track software bugs, defects, enhancements, support calls, and more. Issue tracking software that is scaleable, fully customizable and integrated with VSS. Includes e-mail notifications, role-based workflow, change history, and Crystal reporting.

Get your product or service listed here.
Subscribe to Better Software Magazine
Subscribe to Better Software Magazine

First Name:

Last Name:

Email Address:


Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2008 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


Software Quality Engineering

McCabe Software



Better Software Conference & EXPO 2008