Modifications to software packages : a very expensive bad habit

Modifications to software packages are costly in every respect. They could be compared to ice cream flavours. In the world of software packages, there is no better flavour than vanilla. In other words, changes to software packages often leave a bitter taste.

 

It is therefore suggested that business processes supported by software packages be adopted. This is much more efficient than making changes to software packages to adapt them to your organization.

 

Why are changes to software packages very expensive?

As mentioned above, these modifications are expensive to develop and maintain later. In addition, they represent major risk factors for an implementation project. Why is this? The development of an application is already complex and costly. It should never be implemented without a complete cost-benefit analysis.

 

Updates to software packages can also become very costly. Indeed, when upgrading to a new version, the changes made will have to be reviewed and adapted to fit into the new version. This is an expensive operation that will hold up the migration project schedule. It is also quite possible that the project team that initially developed the modification to the software package will no longer be available and that the documentation could not be found.

 

Why should modifications not be made to the software packages?

There are also cases where changes to a software package are very important. In some cases, the manufacturer may no longer be able to honour the post-implementation support contract for its product. This is a fairly significant issue if the software package needs an update or maintenance.

 

Before making any changes to a software package, it is therefore essential to fully understand all the costs associated with the design, maintenance, support, and possibly migration of the desired changes. An analysis that the modification will bring must also be carried out.

What to do if the software package needs to be modified?

Despite the costs, it is possible that your software package may need a real modification. Before developing a modification yourself, ask the manufacturer for information. Is it possible that the functionality in question can be delivered in the next version of the software package?

 

Another way to ensure that your modification will work is to have it developed by the manufacturer of your software package. Ask them how much it would cost you to support this modification once it goes into production. You may still decide to develop the modification yourself. In this case, ask the manufacturer about the best way to proceed and ask them to review your design.

 

Why were modifications to software packages a run-of-the-mill affair 20 years ago? The answer is simple: software packages offered less functionality and were less complex. Today, these software packages have evolved significantly and generally support the most common and recognized business practices. As a result, they are more complex.

 

An extension to the software package rather than a modification

Some elements, such as interfaces, data conversion programs and reports, are not considered as being modifications to the software. Interfaces are often essential for integrating the software with other applications that support an organization, but this does not make them any less expensive to develop and test.

 

As a last resort, it is possible to develop an extension to a software package without compromising its integrity. An extension adds functionality without modifying the software package. Its creation must, however, follow certain rules. First, under no circumstances should records be created directly in the software package’s database. If it is necessary to create records, they should be created using the interfaces provided by the manufacturer.

 

Do not forget to document all modifications, extensions, interfaces, or any development work that surrounds a software package. These documents will be used to support the production of the software package and the migration to the next version.

 

Finally, before you make any changes, remember the reasons why you first had a software package developed in the first place. Was it to avoid having to do the development yourself? Did you want easy access to new versions? Did you want to take advantage of the best business practices offered by a software package? Modifications to software packages may seem more economical in a short period of time.

---

Jean-François Desroches is Program Manager at PlanAxion Solutions.
He can be reached at jean-francois.desroches@planaxion.com