Last week, I talked about some of the reasons why large organizations often reject the best solutions for a troubled IT project: fear, pride, budget, and the ever-present internal politics. This week, as promised, I will talk about what it takes to champion the right solution. I can’t guarantee that you’ll succeed, but you will have a better shot at it.

Go read the rest of the column. And I promise some original postings here this coming week. ..bruce..

Categories: political

Face it: technology adoption is a gamble, and one often made at gunpoint. External market forces lead internal political forces to demand advances — often unrealistic ones — in information technology. Those who adopt too soon come to understand the cliché “bleeding edge”. Those who adopt too late lose opportunities and possibly market share. And so you find yourself looking a dozen new technologies and trying to decide which to adopt, knowing that only two or three are likely to succeed: that is, deliver what you need and grow with your ever-increasing demands. A winner is always easier to pick in retrospect, but you seldom have that luxury. Instead, you need to decide between adopting a “safe” technology — which may not, in the end, really meet your needs — or leading out with a newer technology and thus run the risk of finding yourself in a dead end with a non-standard or even unsupported solution or approach.

But that’s why they pay you the big bucks, right?

Just as a personal note, I spent five years (1990-95) and $7 million in venture capital as part of a software start-up that developed and shipped a design-oriented desktop publishing system for . . . the NeXTstep operating system. As I tell people, it seemed like a good idea at the time. It was a great operating system (still is — go look at Mac OS X) and certainly better than anything else out in 1990. And we were in good company at the time, with firms such as WordPerfect, Ashton-Tate, and Adobe all developing for NeXTstep as well.

But it was the wrong horse.

Symptoms

Peers and managers above you start questioning your choice of technologies. The number of other organizations adopting the technology in question doesn’t seem to be growing much, or is even shrinking. Developers experienced with the technology are hard to find.

Consequences

Your system and/or development effort struggles due to the lack of developers and third-party tools for the technologies in question. If you’re developing a commercial product, you may find a very limited market, assuming you find one at all. If you’re developing an in-house system, you may end up deploying it, but the system may be difficult to maintain and keep in production for its original hoped-for lifetime. And if you were the champion for adopting that particular technology, you may find yourself losing influence, missing out on promotions, and possibly even out of a job.

Detection

Track down and talk frequently with other firms adopting the same technology. Fact-check, as best you can, claims by the technology’s vendor regarding adoption and market share. Pay particular attention to the products or systems based on this technology that are actually deployed into real-world use.

Extraction

If you think you’ve picked the wrong horse, then start to find the right one, quickly. Figure out what it’s going to take to move over to the better (or best) technology. Work up a careful transition plan — as accurate and conservative as you can make it — and then figure out what it’s going to take to sell this to upper management. There may be no good or easy paths at this point.

Note that there are cases where you may well be best off staying on the technology you originally picked, particularly if this is an in-house system. That is, it may be more cost effective to push into production, then plan for an earlier-than-expected end-of-life for that system, rather than try to switch horses in mid-race.

Prevention

This is hard precisely for the reasons stated above: in many cases, you just don’t know what will succeed and what won’t. If you’re talking about a major decision — such was what operating system to develop for and deploy on — your choices may be limited by other factors. In general, though, you want to avoid the leading/bleeding edges — never count on version 1.0 (or even 1.x) of anything. You want to choose technologies that have been out in the marketplace long enough to have the flaws exposed and — one hopes — the biggest problems addressed.

References

[Professional observation]

Categories: political

A particular technology or methodology (the “TOM”) is wonderful. At least, you think it is, based on anything from a breathless magazine article to years of experience with solid, successful software development using this TOM. Or you may not think it’s wonderful, but you do think it may offer advantages and benefits to your development efforts. And, of course, what’s obvious to you should be obvious—or, at least, understandable—to everyone else.

So you blithely push ahead…until people start pushing back. And before you know it, you’re engaged in a political battle, fighting resistance to the TOM that may range from guerrilla sniping to a full frontal assault.

Why might people resist accepting object technology? The reasons are varied and may range from the well-founded to the completely irrational to the deliberately obstructionist. Here are examples:

• They don’t understand the TOM.
• They don’t want to understand the TOM.
• They’re afraid they won’t be able to understand the TOM (and thus will have less value to the company).
• They know they won’t be able to understand the TOM, because they’ve been just skating by for the last ten years–taking advantage of the IT job shortage–and know that this will expose them for what they are.
• They have very strong feelings about the language and/or programming methodology, or tools or all three that they currently use.
• They really detest the TOM and/or the associated language and/or tools that you’re proposing they use.
• They’re worried that the reasons for adopting the TOM aren’t well thought through.
• They’re worried that the plan for adopting the TOM has significant problems or flaws.
• They want to adopt the TOM, but they want to do it their way.
• They want you to fail so that they (or someone they like better) can get your job.
• They read this book.

Compounding the situation is the fact that you may face several of the reasons simultaneously, possibly from different sources.

Symptoms

Delays in getting approval or support. Rumors circulating behind your back. Objections constantly brought up in meetings. Former supporters distancing themselves from you. Reduction in project priority and resources.

Consequences

Significant project delays or project failure. Loss of influence. Loss of job.

Detection

If you suspect that resistance is deeper or more entrenched than you thought, you need to find out the sources of resistance and the reasons behind it. This can be hard, because the people resisting you may not be honest about what they’re doing, or why they’re doing it.

Furthermore, if the resistance is coming from above, your boss(es) may feel no obligation to explain their reasons.

Extraction

You have four choices, not necessarily mutually exclusive, based on the nature, depth, and source of the resistance:

• Push ahead in spite of it.
• Mollify or enlist those who resist.
• Redirect the project to quell the objections.
• Abandon the project gracefully and (maybe) try again later.

Prevention

Make a list of everyone who might have any input or influence and judge where they stand. If possible, meet with each one privately to sound out her or him—but recognize that you may not get an honest answer. Offer each person a chance to make criticisms and recommendations; let everyone feel a part of the project and the process. Build enthusiasm, pointing out specific benefits, particularly those of interest to each individual. Use each source to cross-check others. This process is known as “getting your ducks in a row,” and you’d better do that before you start. This process may be more critical for those below you than those above you; don’t underestimate the power of developers to make your life wonderful or miserable.

Having done that, assess the costs and risks in pushing this project forward compared to the possible benefits and rewards. Factor that with the probability of success and make your call. If it looks too dangerous, scale back or redirect. If it looks impossible, find somewhere else to work.

References

Webster, from Pitfalls of Object-Oriented Development (1995).

Categories: political

There is an oft-cited dictum in technology development groups: “It is easier to ask forgiveness than 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 a new technology or methodology (the “TOM”).

Nevertheless, it is not uncommon for a development group to make the switch to 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 this particular 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 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 this particular 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 this 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 adopting this 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 this 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).

Reference

Webster, from Pitfalls of Object-Oriented Development (1995).

Categories: conceptual, political

Native tribes in the South Pacific developed “cargo cults” during the middle part of the 20th century. Having observed planes (such as the venerable DC-3) landing on their islands and discharging goods from inside, these tribes created simacrula of the planes and worshipped them, sure that goods would magically arrive as a result.

Something similar happens with many projects that are used to pioneer a new technique or methodology (the “TOM”). Those in charge select the TOM, possibly with supporting tools and technologies, and the team pushes ahead. Having gone through the motions and used all the right tools, the team and its upper management may presume that what they’ve created is properly in line with the TOM and as such will incur all the benefits thereof.

Unfortunately, what often results bears little resemblance to best practices — or even somewhat OK practices — in professional TOM development. The painful reality is that they are in many cases worse off than if they had simply used existing techniques, methodologies and languages.

Symptoms

Serious problems in schedule, functionality, and quality. Failure to achieve expected benefits of object technology.

Consequences

Project instability and schedule slip, often ending in partial or complete project failure.

Detection

When you raise issues concerning what is being (or not being) created, you get responses of “But we’re using [methodology/notation/language/technology]!” When you probe for actual understanding of TOM development within the project, you quickly run into blank stares, defensive attitudes, and canned answers.

Extraction

This is a hard one to push through to completion. In most cases, what you have to do is bring in some technology and process mentor; in far too many cases, you have to throw out everything that has been done so far and start over.

Prevention

Ensure that the development team has people on it who really understand the technology or methodology and who have the skill and experience to apply it correctly and successfully.

References

[Professional experience]

CATEGORIES: political

Imagine the following scene. Your company’s executive staff gathers for a presentation on a new technology or methodology that will revolutionize information productivity. After a presentation citing the ongoing problems of information management, enterprise computing, and competitive response, you are presented with the solution that will boost the company’s bottom line and guarantee its future: structured development using the C programming language!

But wait! you say. Structured development has been around for a long time, as has C. Lots of folks use structured development and C with mixed results; indeed, many don’t use it well. Lots of companies have gone out of business while relying upon structured development and C. How are structured development and C going to guarantee our future?

Good question. And yet, structured development and its associated methodologies — not to mention the C programming language and its versions — are likely more mature, established, and well understood in real-world applications than are any of the later technologies or methodologies (”TOMs”) that you may want to adopt. For that matter, the number of competent, practicing engineers who are expert at structured development and/or C is likely greater than the number of competent, practicing engineers who are expert at the particular TOM in question. If a company can’t succeed using structured development and C, why does it think it can succeed using a given TOM?

You may think that I’m being reactionary or that I don’t understand all the benefits that more modern TOMs have over structured development and/or C. If so, you miss the point: It is not technique (using Jacques Ellul’s term) in and of itself that will benefit the company, but rather its intelligent and purposeful application by people who know what they’re doing and why. To think that adoption of a given TOM (or even a collections of TOMs) will suddenly make everything better is irrational to the point of superstition.

Symptoms

Unrealistic expectations on the part of upper management. Marketers overpromising delivery times and feature lists. Technical managers who see the TOM as a silver bullet. Developers neglecting solid software engineering practices, because the TOM “doesn’t require them”.

Consequences

At best, you go through a wrenching reeducation and attitude adjustment. At worst, you lose the bet — and the company.

Detection

Take the company’s current business plan, mission statement, and product plans, and eliminate all references to and consideration of the TOM(s) in question. Do these documents still make sense?

Extraction

Point out, repeatedly, that it doesn’t matter what technology you use if the products aren’t worthwhile and if the company can’t get a return on investment. Enumerate the factors required for success independent of the TOM(s) in question. Look at all that you can do to maximize those factors. Then — and only then — look at how the TOM(s) in question can aid and support those efforts.

Prevention

Bet the company on your people, not on some technology or methodology. Isn’t that what politics is all about?

Contributor/References

Webster, from Pitfalls of Object-Oriented Development (1995).

CATEGORIES: political

You know the drill. By hook or crook, through long weeks and late hours and ruthless compromising, you finally deliver the project. It’s finished, it’s out the door, and you have taken a few weeks to remind yourself what real life is like. Now you have the opportunity to go back and make right all the hacks and shortcuts and ugly patches you used to get version 1.0 of the project to the customers. Besides, having done the project once, you now have a far better idea of how it should have been done in the first place. You rub your hands together and…

…you are handed a list of new features required by customers or potential customers for version 2.0 of the project, which has to ship far sooner than you would have thought. After some study, you realize that you’re not going to be able to deliver all those features within the required time frame — and even as you realize that, more features get handed down.

Your plans for cleaning up the code and the architecture are rapidly getting pushed off to version 3.0, and you really wonder whether things will be any different then.

Chances are, they won’t.

Why does this happen so often? There are several reasons, really. One may be economic necessity. Your company (division, group) may have to fund itself, which means that sales have to be sufficient to meet all expenses, including your salary and benefits. If that’s your situation, then don’t worry as much about this pitfall; architectural purity is nice, but a paycheck is better.

Another, less acceptable reason may be a short-term focus on the part of upper management. Determined to milk a current market opportunity and concerned primarily about next quarter’s results, they may not be receptive to an engineering investment that would yield more in the long run at the expense of smaller profits right now.

A third reason — not necessarily exclusive of the other two, and sometimes justified — is a suspicion on the part of upper management that engineers are more interested in doing something “cool” or “elegant” than in doing something profitable. What upper management may not understand is that elegance — architecture and code that are concise, yet clear and comprehensive, tending toward orthogonality — always pays off. Always. The only question is how soon and how much, and that is the fulcrum for the balancing act of the technical manager. Ironically, when the engineering staff is able to rapidly deliver the features requested by upper management, it is often because of a previous investment in elegance; likewise, when features take a long time to implement or bugs take a long time to fix, it’s often because of architectural gaps and past short-cuts.

Symptoms

Constantly having to push engineering work into the next planned release and not the current one.

Consequences

The cost of adding new features or extending current ones goes up, not down, over time. The program gets larger, less stable, and less cohesive. Bugs multiply, possibly causing a customer backlash.

Detection

Sit down with upper management and detail the engineering work that needs to be done. Indicate what impact this will have on the current list of desired features. See what kind of reaction you get.

Extraction

It ain’t easy. The reaction you get under Detection should give you a pretty good idea of what things will be like. There are two approaches, which should probably be used together. First, actively work with upper management and customers to determine which features are absolutely necessary and which are merely desirable — ones they could live without until the next feature release. It’s critical to talk directly with the customers, because they may not have done their own prioritizing; the list you get from management may reflect everything from essential requirements to blue-sky wishes.

Second, build engineering cleanup time into each feature so that an engineer allocated four weeks for a given feature spends, say, three weeks on the feature and one week on architecture.

Prevention

Besides using the steps described above in Extraction, you need to emphasize the need to make the proper ongoing engineering investment in order to gain the desired benefits, particularly if a new technology or methodology is involved. This means investing the time to educate management and customers, to set proper expectations, and (if possible) to run a trial project to demonstrate the process.

Contributor/References

Webster, from Pitfalls of Object-Oriented Development (1995).

CATEGORIES: political, architectural, managerial

While discussing the challenges of software development with Taligent trainer Tom Affinito back in the mid-1990s, I mentioned — citing Fred Brooks — the need for a chief architect. Tom immediately responded, “Yes, and ultimately architecture is a political act.”

That observation has stuck with me ever since. Unless you are both sole architect and sole implementor — and maybe even then — architecture is a political act, and it is especially true in development groups of any size. Developers like to think themselves above politics. Not so; they are as human as anyone else. Developers can be quite political and will use a variety of techniques, good and bad, to achieve their ends: persuasion, hyperbole, fear-mongering, caucusing, lobbying, consensus building, rumors, backbiting, leadership, intimidation, sacrifice, tantrums, threats, and subversion, to name a few. The fact that developers are generally very bright just increases the effectiveness of whatever techniques they use.

Architecture is the lodestar of developer politics because it is ultimately the most prestigious role in software development. Brooks goes to great lengths (and rightfully so) to assert the intellectual and creative challenges of implementation, noting that architecture is not the be-all and end-all. Still, it is Frank Lloyd Wright’s name that remains attached to the structures he designed, not the name of the contractors who built them. Or, to update an old programming joke, the verb “to develop” is conjugated this way: “I architect, you implement, he tests.”

Yet we may fail to recognize or acknowledge this situation and its implications. Why? First, we want to believe that all developers have (with regard to the project) the same intentions and goals. Second, we want to believe that the best course is the one that is obvious to us and that everyone else will agree with that. Third, we don’t want to have to deal with politics ourselves, particularly politics that can lead to confrontations.

Symptoms

Assuming — without verification — that all other members of the development group have the same goals, ideas, and talents. Not wanting to assert architectural issues. Finger-pointing as design problems arise.

Consequences

Hidden or overt team dissension, leading to poor morale and lack of cooperation as well as a weakened architecture.

Detection

Ask yourself these questions:

• Who is the chief architect of this project?
• How well do the other developers support the chief architect?
• How effective is the chief architect in her role?
• What are the obstacles she faces?
• What are all the political issues involved?

Answering these questions should go a long way toward determining whether you have underestimated the politics of architecture.

Extraction

The first issue to address is that of authority commensurate with responsibility: if there is a chief architect on the team, does she really have the authority to compel adherence to the architecture? This kind of authority is different than being able to say, “Do this or you’re off the project,” which often leads to subtle or overt rebellion by team members. This kind of authority accrues from several factors:

• a proven track record
• respect from teammates
• support from technical and upper management
• a mutual pact with the developers that the chief architect will give serious consideration to all their ideas and suggestions but that they will abide by her decisions
• a willingness to give in on the small things so that she can hold her ground on the big things

Beyond that, healing a team that is experiencing jealousy and dissension is no easy feat, especially when you’re in the middle of a project. Books and seminars on team-building abound; study, learn, and apply.

Prevention

Go through the questions in Detection but cast them in the future tense. Then, as with Extraction, proactively work to build the team and establish the authority of the chief architect.

Contributor/References

Webster, from Pitfalls of Object-Oriented Development (1995).

CATEGORIES: political

Let’s try to keep our perspective while standing knee-deep in the hoopla. As anyone truly experienced in a specific technology or methodology (”the TOM”) will tell you, that TOM is not going to end world hunger or bring about peace in our time. It won’t transform the country of your choice into the new economic superpower of the 21st century. It won’t end cancer, reduce the number of handgun deaths, or curb the rate of out-of-wedlock births. It won’t even affect dandruff.

Closer to home, the TOM in question doesn’t invalidate existing programming languages, methodologies, and tools. It won’t make good engineers or architects out of bad ones. It also won’t make good products out of bad ones; although it may allow you to develop a better program than you might have otherwise, you can develop awful software just as well using a given TOM as you can using your favorite scapegoat legacy TOM.

Adopting a given TOM probably won’t make a late project ship on time, though it may allow you to complete a project that never would have shipped otherwise. On the other hand, it may well make the project even later. A given TOM won’t necessarily have a major impact on the time and effort required for analysis, design, and testing — except, possibly, to increase it as your team and/or organization comes up to speed on it. The TOM in question may not even be the best solution to the problems you face. It might, in fact, make things worse, not better.

Symptoms

An almost blind faith in the virtues of the TOM in question and an equal blindness to its pitfalls and failings.

Consequences

Arguments with others; a lack of flexibility; blindness to the TOM’s weak spots.

Detection

Analyze reactions to each of the statements above. When people disagree, note any strong negative emotional response. Have those who disagree with a given statement explain it to a disinterested, yet knowledgeable third party and see whether they think the logic holds water.

Extraction

As with many pitfalls, study and experience will do much to cure this one. Beyond that, the Detection method above will help you to identify specific areas of excess enthusiasm and credulity.

Prevention

Read books, articles and papers that address the TOM, including those in the Bibliography. Find people who have completed meaningful projects using the TOM and ask them for their lessons learned. Have them read the opening paragraphs of this pitfall and respond to any items they disagree with.

Contributor/References

Webster, from Pitfalls of Object-Oriented Development (1995).

CATEGORIES: political

It’s easy to get excited about a particular technology or methodology (the “TOM”). More often than not, they represent a real advance in software engineering, solving — or at least easing — problems that you face on a regular basis. And we all know just how tough software development can be.

However, enthusiasm for the TOM, particularly for individuals relatively new at it or with a vested interest in its adoption, may lead them to give glowing descriptions of its wonders and benefits to you and others. TOM proponents may make these comments in all sincerity and innocence. Or they may make them with the knowledge that they are stretching the truth a bit or perhaps rupturing it altogether. But whether they know that what they’re saying is accurate is, to a point, immaterial: when reality intrudes, the results will be the same, and their lack of knowledge or their lack of accuracy will convict them equally.

Symptoms

There are two phases. First, the people who have been oversold on a given TOM start to express expectations of the TOM that make you increasingly uncomfortable; you may find yourself starting to downplay things a bit. Second, as problems start to pile up, there are growing questions, doubts, and expressions of mistrust and cynicism.

Consequences

Those who trusted what they were told will feel betrayed; those who did not will feel justified. In either case, both the reputation and the influence of those doing the overselling will shrink, and it will be a long, hard road to recovery.

Detection

Sit down with a sheet of paper and write every promise, hope, and expectation that you or others have made in the name of the TOM in question. Ask yourself how supportable or valid each is. If you have questions about your ability to judge this, find someone who knows more about the TOM than you do and ask them for help evaluating how supportable or valid each point is. Ask yourself whether you’ve succumbed to wishful thinking.

Extraction

If you or others have oversold the TOM in question, you need to start readjusting expectations immediately. It is probably best to do it in one massive reset than to do it piecemeal — a single sword thrust is, in the end, less painful than a thousand paper cuts. As Fred Brooks says, “Take no small slips.” But it’s going to take a long time to reestablish your credibility, which is why it is so critical to avoid this pitfall in the first place.

Prevention

Several times in this book you will find the recommendation to underpromise and overdeliver. Believe it and make sure that others believe it. If you have questions about your ability to judge, then bring in two or three experts to consult and weigh their opinions.

On the other hand, if you knowingly oversell, telling yourself that you can manage things down the road, you will almost certainly be wrong. Resist that temptation. It will always get you into trouble, and your own integrity will be diminished. It’s just not worth it.

Contributor/References

Webster, from Pitfalls of Object-Oriented Development (1995).