Two Easy Rules for a Director of System Development

by Conrad Weisert, May 10, 2006
© Information Disciplines, Inc., Chicago

NOTE: This article may be circulated freely as long as the copyright notice is included.

Practice
what we preach.
Finish
what we start.

The above guidance seems so obvious that you may wonder why we should need to state it. That just goes without saying, doesn't it?

Yet many I.T. organizations manage to violate both of those rules, and the most chaotically mismanaged organizations are those that violate them in the highest degree. Indeed it's rare to find an in trouble software development organization that hasn't been violating one or both routinely. Let's look at an example of each.

Preparing project plans

A few years ago a frantic I.T. Director confided that he was frustrated by his staff's failures in executing projects. He fumed over their "seat of the pants" (i.e. undisciplined improvisation) approach to planning, estimating, and commitment making.

The director engaged a consultant who conducted a short project management course for the staff and proposed some practices to be followed on future projects, including:

With a few minor changes, those practices were approved by senior staff and published in the organization's methodology handbook.

A few months later an influential user initiated a request for a new information system. The assigned project leader paid no attention to the standard practices, confirming the sponsoring user's wishful thinking estimates and recommending a vendor's packaged software solution without specifying the user's requirements. The I.T. Director—the same one who had initiated and approved the project-management standards—defended the project leader's shortcuts, citing the project's urgency and the sponsor's political influence.

The structured revolution

In the 1970s a vice president of a large bank became intrigued by the early successes of structured methods. He chartered a series of task forces to assess the benefits of adopting those techniques as corporate standards. One of the study groups prepared comprehensive recommendations for the bank's programming methodology infrastructure, including:

The vice president thanked the task force team and said he would consider their recommendations. Several months later he chartered another study group to evaluate a newer version of structured design. They, too, returned with strong positive recommendations.

After a couple of years the vice president moved on to another job. By that time isolated project teams were following different (and incompatible) approaches to software design, and the bank never did adopt a coherent, corporate-wide programming methodology.

Secondary effects

Those two examples weren't at all unusual. Many software development organizations have a long history of deviating from the practices they promote and of abandoning worthwhile efforts in midstream.

The direct effects of the I.T. Director's violating his own standards and the bank Vice President's failure to follow up were clear. Their organizations suffered from the effects of out-of-control projects and hit-or-miss programming.

But in the long run they suffered even more from the impacts on staff morale and on respect for management discipline. In those organizations and in others like them the professional staffs came to assume that:

Exceptions -- backing away

Of course, there may be legitimate reasons for deviating from standards or for abandoning plans in mid course. But then, shouldn't we have the courage to face the situtation, to admit that's what we're doing, and to state a reason?

One of the surest signs of a badly mismanaged organization is that stated goals, objectives, and principles just fizzle out as the organization loses interest in them. No one says, "This was an ill-advised standard. Let's get rid of it." They just begin ignoring the standard and don't even tell new employees that it ever existed. No one proposes that it's no longer worthwhile to issue the monthly newsletter or to hold the bi-weekly staff meetings; they just let a few months go by without doing so. Chances are, no one will complain.


Return to IDI home page
management articles

Last modified May 11, 2006