A growing complication for I.T. management . . .

The untrainables

Conrad Weisert
© Information Disciplines, Inc., Chicago -- 6 April, 2009

NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.

The brainwashing

Suppose you're the application system development manager of a medium-large organization. In trade journals and at conferences you've been hearing about a new breakthrough software development methodology, MDB, and you want to find out if it's appropriate for your organization. You send Jerry, a talented young programmer, to a intensive bootcamp orientation with instructions to find out everything he can about MDB and report back.

During the course, Jerry hears from enthusiastic instructors that a number of practices your company routinely follows are passé and dismally unenlightened. Furthermore those dinosaur techniques just don't work, and are to blame for hundreds of failed projects over the past few decades.

The instructors describe projects in other organizations that had failed miserably under traditional approaches, but were later salvaged by adopting MDB. Under MDB users were delighted with their new systems, which were routinely delivered under budget and ahead of schedule.

When Jerry returns he writes a report praising MDB and recommending that your organization adopt it for all current and future projects. You thank him and charter a pilot project to evaluate MDB further.


Meanwhile, you assign Jerry to act as lead developer and project leader1 on a major project for a very important business function. You tell him that he should use his good judgment on trying aspects of MDB in combination with your organization's established standards.

For weeks that stretch into months Jerry submits optimistic status reports. From time to time the developers conduct computer-based demonstrations of prototype frameworks and selected features of the proposed new application system. User representatives express approval, but are beginning to feel uneasy about the eventual completion of the project.

You ask Jerry for a firm target date. He responds by affirming the date that has been stated as a goal since the beginning of the project, qualified by a list of obligations that the sponsoring users will have to meet. Those obligations include:

You're starting to feel uneasy yourself. This is a major highly visible project, and failure will be a severe, possibly fatal, blow to the I.T. organization and to your own career. You ask Jerry for a copy of the project plan.

After a few days Jerry responds by repeating the latest of his optimistic vague status reports. "No," you explain patiently, "I need to see the detailed task network with deliverables specifications and estimates of time and resources."

"Uh, we don't do those any more," Jerry responds. "That's BUFP (big upfront planning) and it doesn't work. We're following MDB's incremental and interactive approach to project planning."

"Jerry, that may be," you explain as calmly as possible, "but our standards still call for a rigorous project plan, and without a plan your estimates have no credibility. Please prepare a project plan now, according to our standards guide. Meanwhile, let's see the latest version of the system requirements."

"Well, we don't have all the requirements in one place," Jerry continues in an increasingly defensive tone, "but if you're interested we can assemble for you the list of desired features we've collected from the users."

Cutting your loss

After a few more rounds of mutual misunderstanding, you reluctantly conclude that Jerry is the wrong man for this critical role, and you replace him. The new project manager, after reviewing the status of work and developing a proper plan, reports that the actual target date will be considerably later than the wishful-thinking goal Jerry has been affirming. This is a severe disappointment to the sponsoring user organization and an embarrassment to your development organization, but the project is now under control.

Because Jerry is a talented programmer who has done some good work for your organization, you decide to send him to a 5-day project management course. After the second day, Jerry quits the course, explaining angrily that they're teaching obsolete approaches that have long been discredited. The instructor confirms that Jerry was argumentative and hostile, and advises that Jerry is untrainable.

Depending on the size of your organization, you have to figure out what to do with Jerry. His attitude borders on insubordination, which can be grounds for termination, but you feel responsible since you sent him to the MDB course that brainwashed him.

How can such situations be avoided?

Such sad situations are easily avoided by adopting and staying with a participative approach to the organization's methodology. When an individual staff member believes that some new approach ought to replace the organization's established standards, he or she is free to propose it. The proposed change will then be reviewed, and debated in a rational forum. Those who oppose the proposal will have a chance to state their arguments.

Instead of stubbornly trying to sneak MDB into a critical project, Jerry should have submitted a proposal to replace specific aspects of his organization's methodology with MDB. Reviewers would then have had a chance to examine the likely consequences of such a change. Resolution might have been acceptance, rejection, or some sensible compromise, but everyone in the organization would have understood what the official methodology is and how it was arrived at. If consensus couldn't have been reached, then those on the losing side of the debate would have understood why they lost and would have accepted the result with grace.

Must we de-agilify?

An interesting irony in these increasingly common situations, is that the untrainables often turn out to be advocates of so-called agile methods. Although the word "agility" connotes flexibility, adaptability, and open-mindedness, some of the most stubborn and inflexible practitioners are the hard-core agilists.

Bona fide agilists, in the positive and originally intended sense of the term, are willing to listen, to adapt, and, when necessary, to compromise.

1—Two roles that should rarely if ever be assigned to the same individual.

Return to Management articles
IDI Home Page

Last modified 6 April 2009