Three ways project managers give in to threat

We live in a corporate environment (and indeed a social one) where the fear of personal, financial, or political harm counts for more than the honest calculation of risk. Economists are slowly starting to key onto this with their calculations of “perceived risk”; priests, theologians, and mothers everywhere probably realized this somewhere around the time humans started to speak. As project managers, we have to deal not only with the threat we face ourselves, but also the threats an organization’s management react to and the threats which press down upon our project resources.

All of these threats wear down our enthusiasm and determination. They also prevent us from doing what’s right rather than what will shield us from fear. We worry more about doing what our bosses want, what our executives might want, and what ever will keep people’s eyes off of our project than honestly trying to get the job done on time, under budget, and within the requirements.

In our role as project managers we give in to threat in a variety of ways. The most prominent of these is to misreport data about misalignments in resources, time, or function requests from the project. We can also obscure the work we do behind layers and layers of data, hide issues as they occur, and place ourselves in a situation where we control all of the inflowing information, thereby shaping our perception of reality so that it no longer matches with what is really going on.

Misreporting happens all the time. Most of us can do simple calculations or look at a calendar and tell when things fall behind. We know from personal experience that we do not have enough time or that our resources are stretched too thin. Yet we say nothing. We become afraid that the project will be canceled or our contracts terminated if we do not do exactly what we are told when we are told it. It happens often enough, in fact, that the threat has some teeth in it.

Another failure, one that I’ve fallen into from time to time myself, involves generating too much reporting data. On one hand it looks like we’ve accomplished something. Hundreds of reports showing that we’ve done something with our time, certainly look better than an entire day spent on the phone talking with people and having nothing tangible to show for it. Just as importantly, the volume of the information shared insures that we can control the conversations around it. We direct people to the “important” parts, and subtly shade the rest to support what we want to say.

Hiding issues is another favorite failing of mine. It’s easy to talk about how all issues should be escalated to management. It’s simple to say “Why yes, we should have talked about this earlier”. But we also know that people want projects to be quiet and perfect. Perturbations along the project path do nothing to endear a project manager to his managers. Indeed, they are usually seen as failures on the part of the project manager, and can become grounds for dismissal when the inevitable witch-hunt begins.

The last failing is probably the most insidious. As project managers it is our responsibility to report project status. When people want answers about a project, they come to us. It’s easy to make all information flow up to us first, for vetting and perception management, before it reaches anyone else. Logical, even. Unfortunately this kind of activity actively leads those who report to us to taint the truth. They tell us what we want to hear or what they think will make us happy rather than what we really need to know. We then pass on the bad information in total confidence, now unaware of events in our own project environment.

I don’t have any easy answers for dealing with threat. We don’t talk much about the importance of feelings in business or how vital a role our emotions play in our decision making processes.