Project Management Weblog

My thoughts and stories on project management on a regular and perpetual basis

3/28/2005

PANIC AND POLITICS

Since I've been dealing with project mangement problems with clients and reading a lot about project failures lately, I decided to write a few things about another major risk facing projects - office/organizational politics and the ensuing panic on the part of the project manager and project team.

Office politics, like change, is inevitable and must be dealt with properly and in a timely fashion. Folks we work with who proclaim "I don't do office politics" or similar utterances do so at their own peril and are deluding themselves that their strategy will keep them employed and professionally viable. Those I've known in my career who have done that have generally been ignored, not promoted, or worse, among the first victims of staff cutbacks. It's not possible (or advisable) to "keep your head down" all of the time at work and expect to advance or have any real effect on the outcome of your work. This is particularly true of project managers. As I tell my students in PM courses: "If you want to sit in your cube all day staring at a screen, don't like attending meetings, can't or won't communicate well, or play the political game at work, project management is not the job for you!"

Of course, how one specifically plays office politics has effects on project outcomes, but I'll leave that for another article. My point here is that politics played the wrong way can drive an emotion that can kill projects: panic. The effects of panic behavior, both short- and long-term, can be devastating to projects and those involved with them.

The main effects of panic on a project involves what I'll simply call "corner cutting." PMs and project teams in panic mode usually thrash about looking for any possible way to compress time and tasks to fit the situation that caused the panic attack. Perhaps the project wasn't well-managed to begin with, and its near time to deliver and we find that we're not in any sort of position to do so. Or a massive scope change changes the project deliverables drastically with little time for the team to assimilate the changes. Or a 'Just Do It" (JDI) sponsor or major stakeholder is demanding change without compensating for time, budget, or resource impacts.

Panic situations have dramatic effects on outcomes for projects managed in with traditional, process-oriented methodologies, but projects managed with extreme or agile methods are not immune either. In my experience, what normally happens when panic sets in is as a part of the "corner cutting," the project management methodology involved is either cast aside (throwing out the baby as well as the bathwater) or so significantly altered, truncated, or abused that the project has little hope of succeeding regardless of what the follow-on decisions or tasks are. The essence of this is a shift from a disciplined, focused approach to a flying-by-seat-of-your-pants / managing-in-the-moment strategy that increases the risk of failure.

There is another insidious and sad side-effect of allowing panic to dictate within a project: it trashes organizational project management methodology and the benefits of it. Why? Because if a project is allowed to operate in panic mode for any length of time (particularly at the end of the execution phase), the organization is sending a very clear signal about project management in that its OK to use PM techniques until the situation gets desperate, then anything goes. PM has little chance of long-term success in such cases because people such as Crisis Junkies seize the opportunity to avoid disciplined techniques and can lurch their work forward in the moment without planning or much in the way of accountibility. Worse, some CJs are very adept at artificially creating a project crisis (or more often, crises) that they can overreact to repeatedly to keep that "high" they crave in the work environment.

The next time things on a project "hit the fan" and you're tempted to correct course by making split-second decisions that have a half-life of ten minutes before you're making the next one to replace the ones you've already made, stop, take a deep breath, and pull out your risk management plan. Map the crisis to the plan, and take the remedial actions specified while modifying the project plan accordingly.

You do have a risk management plan for your projects, don't you?

0 Comments:

Post a Comment

<< Home