Changes and additions

We follow an efficient change management system when accommodating and implementing requests for changes in the software being developed. This system has proven to be effective and has saved a lot of our clients time, money, and headaches. 

As much as possible, changes and additions should be avoided during development. Changes and additions have killed many IT projects. The main reason based on our experience is best summarized below:

A person in the organization gets an idea to add a smart little feature in the software. When presented to the developer, he gets just as excited about this new idea. In his excitement, the developer estimates that it would take 25 hours do this little job. While 25 hours is enough time if he starts from scratch, he forgets that to do the job, 3 classes and 1 module also need modification. Further, once the 3 classes are modified, 2 other modules are affected because they use the same classes. And before everything works again, 50 hours has been used (of which 20 hours were used for debugging because of the errors that happened due to lack of planning). Finally, the project is now 50 hours behind schedule and costs 50 hours more to develop.

So, how should changes be implemented?

The correct approach in IT change management is to write all additional ideas on a list, and collect them while the software is being developed. When the application is finished, we will sit down with you to go through the list and make version 2.0 of the software. Here, we will take the necessary time to plan every addition or change that you want.

If changes or additional features are crucially needed for the software to succeed, then it must be done. But if the said feature can be classified as "nice to have" or "really, really nice to have", then we suggest that waiting and making version 2.0 is a better approach in requirements management.

Remember, changes and additions always make the project more expensive and most likely will cause delay.