Project Management

Is project management a language rather than a discipline?


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?

3 comments
dccd
dccd

Personally, I think being a project manager blows chunks. It's a dead-end opportunity to play good cop and bad cop with the software world's overly-privileged and weenified masses.

threew
threew

What you describe so well is a project... not a language issue. We all struggle to understand and meet the needs of different stakeholders in the process of initiating and planning a project. Our goal is neither to force the stakeholders into one mold nor to change their internal accounting practices. The fact that different deparments within an organization have differing needs (accounting, budget, QA, and the like) is a challenge to planning and managing projects. However, that is one of the reasons for "the discipline." One critical aspect of the PM role is the ability to, at least for a time, bring all the differing needs to the table and meet them within the project model. Language can be a tool in this process but it is the discipline that gets the job done. The expectation that all our stakeholders speak the same language or follow the same internal processes is neither pratical nor realistic. Hence the need for project managers and project management discipline.

meryllogue
meryllogue

We sit between the parties and make sure everyone's needs are met. Sometimes that requires us to translate between groups; other times we have to negotiate between groups. But regardless, it is on our heads--and in our own best interests--to do both rather than fight the tide. We cannot change systems; we can only work within them. If we can get some groups to bend slightly to accommodate others' needs, yahoo. That is a bonus. IMHO.

Editor's Picks