Last modified: 13:18:26 23-Jan-2009
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.
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.
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:
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.
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.
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.
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.
Last modified: 13:18:26 23-Jan-2009