Healing Sick Software Projects
By Charles Connell
Many software projects run into trouble. Software often is late, filled with bugs, or both. Software project fiascoes have postponed the opening of a major new airport and delayed the return of tax refunds. Some projects are so riddled with problems that they are cancelled, wasting millions of dollars, with nothing to show for the effort.
How can you tell if your project is getting into this kind of trouble? If your project is floundering already, what can you do about it?
While software projects vary greatly in their details, the reasons they get off track are remarkably similar. To succeed, every software project must have the following elements. If one or more are missing, the project almost certainly will have significant problems.
Shared end-goals -- Everyone involved in a software project should agree on where the project is headed. It may take years to get to the end, but everyone should be walking in the same direction. Nothing is more frustrating for managers or engineers than completing a piece of software, only to have users say that it is not what they wanted. If your project does not have this long-range agreement (among all parties involved), stop work and solve this problem first.
Modest, stable goals for each version -- Software projects often have difficult or lofty long-range goals. This is exciting for a team and leads to innovation. But each specific version of the software (say every few months) should have fairly simple, manageable goals. It is too complex to make giant leaps all at once. It is important also that the goals for each version be stable. No one can manage or work on a moving target. If your current release is too big, break it into smaller pieces. You are not giving up any features; you are just spreading them over several releases.
Good internal design - The design and structure of a building has a large impact on its usefulness and lifespan. The same is true for software, although it is harder to see the design hidden inside a software system. While difficult to see, software's internal architecture determines the software's usability, reliability, performance, and length of service. If a software project has poor internal design, take time to improve it. The effort will pay off many times over.
Realistic schedule for each version - Software projects should be controlled by a schedule that takes into account events that really happen during software development. This includes computer breakdowns, sick time for key employees, personnel turnover, adequate testing, and difficult bugs. Do not trust a schedule that depends on everything going well. To make a realistic schedule, assume that significant problems will arise and allow time to solve them.
Source code library and repeatable build process - After software is written, it must still be assembled into a working program. Doing so (via compiling and linking) is an error-prone process that can derail even the smartest engineers. Software projects should use an automated system to store all the parts of the project and build the parts into a working program. Fortunately, there are tools to accomplish this automation. Members of the project team need only to select a commercially available source and build product, then make sure to use it.
Efficient process to track bugs - Every piece of software has bugs. How a project leader handles this fact makes the difference between calm and chaos. There should be a simple method for users and testers to report bugs, and to verify that the engineers received the reports. Engineers need a simple, reliable method to keep track of bug reports, mark those that they have fixed, and communicate the fixes back to users and testers. This problem of tracking and communicating about bugs can be solved with a combination of existing tools and manual procedures.
The project aspects at the front of this list tend to have the largest impact on the success of a software project. These items also can be difficult (but not impossible) to fix when they are off track. On the other hand, the aspects near the end of the list have a smaller (but significant) impact on a project's health. The latter items are quite easy to fix, however, using known methods. Improving all these aspects of a software project yields a final result that has high quality, is on schedule, and meets user expectations.
Biography: Charles Connell is president of CHC-3 Consulting in Woburn, MA (www.chc-3.com), which helps companies manage and turn around software projects.
(NOTE: This is the text of the article as submitted to Boston Business Journal. The published version was shortened somewhat during editing.)