Project management is, in theory at least, a common language spoken by facilities, IT, operations, and the company’s management group. This common language allows individuals with very different experiences of the same business to communicate logically about expected outcomes and activities. Like all languages it relies heavily on metaphors, shared understandings, and specific rituals of intonation which signify meaning and measure.
Unfortunately things do not quite work out that way. Very few of us are really “project managers.” We are development project managers, infrastructure project managers, QA project managers, facilities project managers, operations project managers, clinical project managers, or ice cream sundae project managers. Even if we manager to speak the language of project management, we do so with an accent which makes it impossible for our brothers and sisters to understand us. Our unique “accent” in how we fill out our artifacts can make them neigh onto useless for those who work in different fields.
Just to give an example: the other week I plodded away on a basic process project. Like most such projects, it had languished untouched for months before I came on board and will probably fall back into obscurity after I get busy again. Within the process several groups (two different development, some pure management, and several IT) need to coordinate their activities for a few months.
Things only got interesting when we started to discuss how communications should flow. Everyone agreed to use the change management system. That’s what its for, after all. However, each group got into a practical conflict when we started to explore what information we actually needed to share and what our dates were. For some, the process started months (even years) before others. Some needed to coordinate the activity within the context of year-long budgets; others could simply treat any additional effort required as ad hoc project resource requests. One even had an existing manual process, untouched by the various waves of process improvement, still running in the background. If it’s not broke, don’t fix it and all that.
Naturally, every group’s particular interpretation was the “right” way to think about it. The date they requested fit in specifically with their needs. The timing, functions, and budget constraints they required met with their parts of the overall business context. Changing these inputs, or even the outputs, would require changing the part of the business the various groups interacted with.
They were not, however, normalized in any appreciable way. This would cause fits to those who regard project management as a tone-deaf language, as a set of actions rather than rules of grammar. Those people would have tried to force a normalized schedule and data set down onto the project regardless of the eventual results.
Fortunately, I’m either too lazy or too tired to force everyone to my way of thinking. Instead I built a quick data map, threw together some linking artifacts to clean up the worst of the confusion, and went on my merry way. It’s not really important to me that facilities likes things one way and the three development teams use different approaches to QA so long as the work gets done when it’s supposed to. My job, the job of everyone who wants to see things work, is to work out these interfaces so things proceed in a regular, if not orderly, fashion.
Is that good enough? Or do we have to accept the rule of the accountants, in which every process must meet specific normalized targets and our profession is little more than the creation of trials for auditors?
No comments:
Post a Comment