home   about   contact   downloads   links   [pricing]   reading list   salesforce   site map  

Current loctn: pricing > software difficulties

Software Difficulties - Timelines

Software development projects have a number of inherent difficulties that affect most projects. In particular, cost and timelines are difficult to predict with sofware development.

Multiple Projects

Several times we have made a very serious effort to arrange consulting work with clients to focus on one project at a time, with full focus on that project for the duration. The theory was that this would minimize timeline slips, maximize efficiency by having all the details of conversations, etc. current in everyone's memory, and so on.

None of these efforts was successful. Each effort quickly degenerated from the one project at a time ideal to the typical situation where a developer is working on several projects at one time, trying to schedule work dynamically to meet the most critical client needs.

In each of these efforts, we found client organization was inadequate to support a full-time development effort. It often required several days before a critical client reply was obtained. Scheduling conflicts within client staff played a role, since the regular work of the client organization must proceed despite the development project. Also, the important questions that arise often require consultation with others and a little bit of thinking time for a decision to be reached. Hurrying an answer in this situation encourages bad decisions - it is probably wiser to accept the delay needed for proper consideration.

We've tried to simply learn to accept this and work with it. Sometimes the number of details a programmer must retain in memory for a programming task is close to saturation level. In such a case, it can be difficult to put the task aside and then pick it up again later. But this is seemingly the nature of the situation... and it may be unproductive to fight it. If you get stalled on an issue that cannot get a fast reply, you have to divert to another project while waiting for a response.

Some elements of this situation manifest at the client's end of the situation. Time waiting for required client input is typically NOT charged to a client. Instead, we simply switch attention to another project. This keeps client expenses down, and ensures that the client is charged ONLY for time when work is being performed. However, it ALSO requires that we work on several projects simultaneously. That creates a very complex situation. If the alternative task puts a programmer near memory saturation, it may be important to complete that task BEFORE returning to the original project. In this case, it may take several days to return attention to the original project...

We've grown to accept that there is at LEAST a kind of symmetry in the client/developer relationship. Sometimes the developer has to wait for replies and input from the client. Sometimes the client has to wait for the developer to complete a task for another client before they regain full attention. In both cases, the delays that will be experienced are difficult or impossible to predict. We now tend to view these delays as an inherent part of the partnership between client and developer. My observation is that clients with long experience in development projects seem to accept and cope with these situations in much the same way we have.

Inherent Characteristics of Software Development Projects

In addition, there is something about software development itself that seems to defy reliable prediction of timelines and costs. Every issue of every software development journal seems to have an article examining the problem, analyzing some particular case study of slipped timelines, proposing ideas for improvement. This seems to ALWAYS have been the case - this obsession with timelines seems prominent throughout the last 20 years or so at least. Even IBM and Microsoft routinely miss their predicted release dates for new software. If companies with resources and expertise like that of IBM and Microsoft often miss timelines, this suggests the root cause is inherent to the subject.

We try to mindfully apply the recommendations of the software development technical literature to minimize timeline and cost overruns. The usual suggestions from the literature are that timelines and cost estimates occur because:

  1. timelines and/or budgets are set without proper assessment of the actual problems to be dealt with OR... someone promises a timeline that is desired by a manager/client without ever really looking at the problems likely to be encountered

    We attempt to avoid this situation by making in a standard practice to perform a relatively detailed project evaluation before providing the client with cost estimates or asking for a committment to a project. This is provided for formal approval in a statement of work document.

  2. Additional features are requested or added to the project without adjusting the timelines and cost estimates to compensate

    Significant revisions of the project scope are typically captured in a formal amendment to the statement of work that typically includes a revised set of cost estimates.

  3. Software is just too inherently complex for ANY preliminary estimates of timelines to be reliable

    This situation can be at least partially addressed by adopting practices and expectations appropriate to the difficulties of predicting software development timelines. This approach can at least prevent the client/consultant relationship from being damaged when unrealistic expectations are held.

Triaged Diversions

A GROUP of clients rely on us for software and database support. Sometimes critical emergencies arise with these clients. If we are currently working on a project that does not have critical timelines, we may decide to divert attention to the emergency. Nearly all of our clients are deserving non-profits - it is doubtful another client would deny emergency attention in favor of a non-critical timeline on their own project. Naturally, responding to the occasional emergency hinders the ability to predict timelines accurately.

Naturally, a similar process can play out without the need for a full-fledged emergency. For example, a critical timeline on one project may divert attention from a project with a timeline that is non-critical.