[Copyright (c) 1995, 2007 by Bruce F. Webster. All rights reserved. Last updated: [date]]
CATEGORIES: political
There is an oft-cited dictum in technology development groups: “It is easier to beg forgiveness than ask permission.†It is often true and sometimes crucial to circumvent bureaucratic foot-dragging and politics. But it is not always the best course, and the danger of following it is commensurate with the technical, financial, and political risks involved. And all three risks abound when an organization is moving to object-oriented development for the first time.
Nevertheless, it is not uncommon for a development group to make the switch to a new technology or methodology (the “TOM”) with only minimal involvement and education of upper management. Indeed, management may not care very much or may even be supportive — having read an article about the wonders of the TOM in a weekly business magazine.
And that is where the pitfall lies. For unless the project comes in within acceptable time and budget limits, upper management will suddenly be asking hard questions reflecting reasonable or unreasonable expectations, given what they know or were told.
Symptoms
Apparent lack of knowledge or overly positive expectations or both on the part of management about the TOM and its role in the relevant projects. Sudden distancing or self-protecting (CYA) activities if problems crop up.
Consequences
Lack of support and possibly active hostility from upper management if problems arise or if their expectations aren’t met. Finding yourself twisting in the wind. Career damage, lack of promotion, demotion, loss of job.
Detection
Sit down with upper management and find out how much they understand about the TOM and how it’s being applied in the relevant project(s). Have them detail their expectations. Find out their level of enthusiasm or concern for the use of the TOM.
Extraction
There’s little to do except start the education and enrollment process much later than it should have been. It may be really tough, depending on how current expectations compare to reality, and the truth is, there’s no good reason for not having done this before things got started.
Prevention
From the pitfall itself, it’s obvious that there are two separate (if related) tasks: educating and enlisting. The first comprises letting management know exactly what the TOM entails, which means that you had better know yourself, and you’d better know it well enough to explain it to nontechnical people. Work to contain your own enthusiasm for the TOM; remember that it is safer to underpromise and overdeliver.
Second, and this is probably tougher, you need to enlist key people: those who can affect your budget and resources, and those who can affect the scope and direction of your project. If you can, prove yourself with small projects to establish credibility and to give your sponsors a track record to point to (and take credit for).
Contributor/References
Webster, from Pitfalls (1995).
