Developer

Application development: Surviving the unreasonable estimate

The project will take 12 months, but it's due in six: par for developers. But you could still come out of this in half-decent shape. Follow these suggestions, and you may be able to turn a nightmare project into a success.


What do you do when an unreasonable project estimate is chiseled in stone? You could just focus on the technically challenging aspects of the project and disregard the unreasonable timeline estimate, but that won't do your career any good. (See "Project success or failure: Do you and management see eye to eye?" for a look at why it's important to understand management's success criteria.)

Fortunately, there are alternatives. Here are some suggestions for the developer who wants to meet the goals of his or her organization despite impossible requirements—and who hopes to avoid some of the exorbitant amount of overtime that such unrealistic schedules entail.

Feature triage
More than likely, you have been assigned one or more features that need to be developed in a very short time. Marketing may have already told you that all these features are critical to the success of the product. Through its extensive analysis, it has determined that every feature is a “must have.” (If this is always true, why do so many features get cut out at the end of a project to make schedule?) Not all features are created equal. From a technical perspective, it is important to critically assess which features can easily be developed, which ones may be difficult to develop, and which ones might be easier to develop if the requirements were modified slightly.

Work with stakeholders and others with a perspective on the business issues so you understand their priorities. Between your technical assessment and their business needs, you should be able to identify those features that will provide the most bang for the buck. Selling others on dropping features early in the project will probably be impossible, but if you know up front what is and isn't vital, you can approach the project more intelligently. Once you do this triage, you can develop a prototype plan.

Be ready with a deliverable
Faced with an unreasonable project timeline, you must always have a working version of your application. So get something working quickly! You could develop an initial prototype that includes the easiest feature(s). The goal of the first prototype is to build a quick success and get positive momentum going. Once the first prototype is complete and working successfully, start to prototype the more difficult functions. The goal of the next iteration of prototypes is to better understand the more complicated features. Make a list of all the items that are keeping you from developing those features and attempt to find some answers as you develop future prototypes.

By taking this approach, you will always have a deliverable. If the due date comes before you are completely finished, or someone moves up the date, you will still have something to show for your time up to that point. If you don’t take this approach, you may be 80 percent finished but still have nothing functional to show for your efforts. On the other hand, if you have a screen that's missing only a few menu options, PF keys, or controls, you are in a much better position to lobby for an extension to complete your work.

Negotiate feature releases
Once you gain a little experience with some of the features, you can better identify the effort needed to complete the remaining features. Armed with experience, you can work with the marketing and project management staff to recommend delaying some features for later releases. You may also be able to propose a less complicated feature to the marketing department and delay the more complicated version of the feature for a later release.

Get some help
Adding people to a project may help—but be careful how you use these extra resources. The help will be marginal, and there are definite limits—and even drawbacks. Determine whether you can have someone handle as many side tasks as possible. Those are the activities that do not directly contribute to your development effort. Documentation is important, but if it requires research, are you the only person who can do it? Can support staff (no, not technical support) help with status reporting or tracking down responses from inquiries to your users? All of these resources will make more productive time for you.

If someone suggests adding more programmers, remember Brooks’ Law: "Adding manpower to a late software project makes it later." It's important to keep these issues in mind:
  • It will take time to get additional programmers up to speed.
  • Not all of your work can be neatly divided to allow multiple programmers to take a piece and work on it independently.
  • The more programmers on a project, the greater the communication problems and overhead.

The bottom line is this: Be wary of proposals to add programmers to your team but jump at getting help from secretaries, assistants, and users.

Brooks' Law
Frederick Brooks, Jr., was a manager of IBM's OS/360 project and is the author of The Mythical Man-Month. This classic book on software engineering points out, among other things, that communication difficulties, training, repartitioning, and system testing all place a greater drag on a project than the benefits gained from having additional developers. According to Brooks, "More software projects go awry for lack of calendar time than for all other causes combined."

Reuse software
If your organization has developed a library of software components for reuse, you might be able to save some time by integrating some existing code into your feature. Of course, it's important to assess the quality level of any software components you anticipate using. You don’t want to use buggy code.

Also, you don’t have to be in an object-oriented environment to reuse code. If you work with a non-object-oriented language such as COBOL, you may be able to find a collection of programs that can serve as a model for your new program. Keep in mind, however, that sometimes it takes longer to understand someone else’s code than to develop your own from scratch.

Consult experts
As always, you might be able to get some key insights from those that have walked in your shoes. Consult experts within your organization to see if they can provide some advice and share a few lessons learned.

Don’t let it get you down
The next time you're hit with an impossible project schedule, don't assume that your efforts are necessarily doomed. After your feelings of incredulity pass, follow some of the tips presented here. Odds are, you'll fare much better if you follow this prescription for dealing with the situation. You might even wind up being a hero.

Editor's Picks

Free Newsletters, In your Inbox