Projects come at you fast – is your organization ready?

The commercials are a little goofy; some regular person, just minding their own business, suddenly finds their life altered by a spectacular auto accident. Yes, auto accidents happen and yes they can have devastating effects. I especially do not recommend the ones where you are the pedestrian and they are an SUV. However, a similar thing happens just about every day in our projects, and unlike an auto accident we do have the opportunity to build up the capability to deal with the issues before they arise.

Now, in standard “project management” methods I would be talking about the ideas of risk management, issue management, and sometimes human resource management. We would address sudden crisis though the execution of existing plans or by assembling an elite task force of highly trained gender-neutral rodents to eliminate the problem. We might even “escalate the issue” to “the appropriate level of management”, which usually amounts to telling our boss he is about to get hit in the face with a large, smelly carp.

Oddly enough that's not what I'm talking about. Recently I've been toying around with the idea of the project manager's project organization. By this I do not mean the PMOs of the world, lovely as they are. Rather I'm thinking about the carefully orchestrated network of communications and activity radiating outward from the project manager though organizational boundaries and into far-flung customer and service groups.

This later organization is generally cultivated though the delivery of successful projects. When a project manager first starts with a company he knows very few people and relies on formal methods to achieve his ends. Over time he develops connections though successful (and unsuccessful) experiences with people at all levels in the company. Eventually these connections create an organization into and of themselves, a group organized by the project manager to achieve specific ends.

When a situation arises, it is this organizations strength (not that of the formal organization) which must prove sufficient to both mitigate the immediate issue and address the fundamental problem. When a site is down and you need customers to agree with developers to agree with infrastructure people, nothing helps like being able to pickup the phone and call the five people you always work with to get these things squared away. The formal organization will just have to keep up, if it can. Most likely it cannot, though the managers will like to be “in the loop” so they know what happened.

Going back to a point I made a long time ago, this is part of why project managers just don't transplant well. In an environment a project manager knows he's magic. Problems which could wipe the company off the face of the earth vanish in a puff of logic. Outside of that environment he's a glorified book-keeper, struggling to keep control of time while events race ahead of his ability to exert cross-functional controls.

Hummm...something else to think about. If the project organization conflicts with the formal organization, who wins? No one? Everyone? Anyone?