fbpx

Software Project Salvage

If the developer failed to get a true understanding of the requirements, he will go forward on what he thinks is the best solution. He will deliver something but it may be awkward to use and the features don’t actually match your business pattern.

A second common outcome is that you get a system that met the requirements at the time but now needs new features that from your business perspective are logical and obvious. But now you find that because the original design did not include any forward look at future requirements, you can’t get the feature put in without unreasonable expense – if they can be done at all.

A second common outcome is that you get a system that met the requirements at the time but now needs new features that from your business perspective are logical and obvious. But now you find that because the original design did not include any forward look at future requirements, you can’t get the feature put in without unreasonable expense – if they can be done at all.

A software developer must consider possible outcomes that have not yet come over the horizon at the time of the build. The types of things that come up are in the following categories:

  • As the design and implementation unfold, the customer now sees possibilities for features that simply were not conceivable until now. He will see more potential benefits from the new understanding of what has already been specified.
  • The business growth, now less restricted by reason of the new automation, now accelerates. The increased volume of work and the number of users required increases unforeseen load on the system.
  • The customer’s business expands by adding new products and new services, requiring additional features to be added.
  • The customer adds new lines of business, requiring additional features to be added.

With our having experience in so many diverse industries, we can bring that experience to the design process. The speed of environmental change, speed of business expansion and speed of new technological developments really require one to consider these future developments in the present-day design challenge.

 

A wise man said “Change is the only constant” (Heraclitus, Greek philosopher some 2500 years ago). Some scholars think he meant “What’s the use of trying to keep up?”.  A better outlook is to keep a forward look, not only with business and opportunity changes that come up, but in software design as well.

Here is another pitfall: once you’ve learned that your software cannot expand to handle current or future requirements, you are told that the underlying technology is “too old” and that the only way forward is a complete re-write. This might be true, but for sure you should get us to provide a second opinion. 

On several occasions we have taken over projects in this category and we found ways to correct or build around major flaws and keep the system running effectively.

In one case a client was running an in-house developed database which was nearing its end of life cycle. The company IT department could no longer commit to supporting it but had no solution for replacing it.

As a result of our intervention, we addressed several shortcomings so the staff could continue with the system for the short term. The client was very happy to have bought time to continue with the old while embarking on an evaluation of what commercial software was available. This process took over a year including the time to make a controlled phase-over to the new platform. The advantage was they had the time they needed to budget the expense of acquisition as well as the internal IT and other expenses in an orderly fashion.

Mark Thomas is a CRM and Data Solutions Master. If you have any topic you would like to  see addressed, feel free to make a suggestion. He can be reached here.