Fix it sooner, not later

IN A RECENT staff meeting, one of the engineers on my team related a story in which the business users of a product he developed were brainstorming on the product's features almost until the day it launched. As the deadline approached and the engineer protested further changes to the specs for the project, the users' mantra began, "Can't you just ..." or "Would it really be that difficult to ... ?" Anyone who has been involved in the internal development of custom software for an organization has heard this before, but the question is: How do you deal with this phenomenon without seeming inflexible, maintaining the "can do" attitude that business requires, yet still building a quality product or system?

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

This problem is especially difficult for CTOs under the gun to deliver near-immediate ROI, but with systems that are inexpensive to maintain and scale for the long term. The answer is to make sure that your company understands the truths about how costly -- in time, money, and human resources -- it is to do business that way, and deal with disruptive last-minute changes as a management and communication issue, not a technology problem.

The first truth that needs to be communicated to the business side is that software isn't quite so soft and the development process requires active, dependable, and consistent participation by everyone, especially in the critical early stages. Software design and development typically do not enjoy the same respect as projects in the physical world where nontechnical people can actually see what is happening. Your methodology has to be flexible to deal with ambiguity, but no methodology will overcome a flurry of new requirements at the end of a project. CTOs need to constantly communicate this reality to the business.

Changing the design of a software system after the construction is under way is not much easier than changing the design of a bridge. You don't need heavy machinery to move code around, but the same principles apply to software projects.

You must have a solid plan before you start building and the longer the project goes on, the more expensive design changes become. If you decide to move a bridge 1 foot to the east when the project is 90 percent complete, you're going to have to disconnect the electrical infrastructure, haul in more dirt to shore up the landings on both ends, redo all the testing and inspection, and deal with any unforeseen issues that arise from such a major last-minute change -- lots of time and money. Software isn't much different. The cost of change is high, and unfortunately, the folks who pay the price are the developers who burn the midnight oil adjusting to the changes. The results from those efforts are often less than stellar.

Fortunately, the CTO has fiscal responsibility on his or her side in defending against last-minute changes because the "can't you just" school of thought has been shown to be fiscally irresponsible. In UML and C++: A Practical Guide to Object-Oriented Development by Richard Lee and William Tepfenhart, the authors refer to a study that shows correcting errors can cost five times to 100 times as much after the requirements analysis phase of a project, as opposed to if the errors had been identified in the initial phase. This is something that every CEO and CFO can relate to, and making sure they understand this fiscal reality is one step toward making sure that your organization has commitment from the top for solid software development practices.

After all, as CTO you certainly don't want to find yourself saying to the CEO, "Can't you just allocate five times the original budget to complete this project?"