coder . cl

Managing changes is really important in software development projects. Each change should be handled carefully and must not be seen as part of the original development process. Instead, you should measure and control each change in the original requirements, even if you are using agile or cascade methodologies. You cannot accept all changes that the customer proposes without the proper management process. Is not that easy to handle changes in requirements like changing a comment in the code. Instead of accepting changes and delivering software without the proper management process, you should be able to handle those requirements using a standard method to manage those requirement changes.

An example of requirement change management process is as follows:

1. Log the changes.
2. Perform an impact analysis on the work products.
3. Estimate the effort needed for the change requests.
4. Reestimate the delivery schedule.
5. Perform a cumulative cost impact analysis.
6. Review the impact with senior management if thresholds are exceeded.
7. Obtain customer sign-off.
8. Rework work products.

So, you should record each change in the project documentation, on the product backlog on agile projects and the project specification in structured projects. If you do not record all changes that are made to any software piece, there is not log or evidence that were made changes to the project, and you are loosing the core project specification. Any change requires analysis of all changes that are applied to the software piece. If you do not perform analysis, you are delivering software pieces without the proper structure and logical basis, even if you are working with prototypes. And finally, all changes should be measured and estimate the effort required to complete them, without an estimation of those efforts, you will not be able to handle the change set cost, deriving in a project with a higher cost than it was measured originally. Even if you are using agile or structured methodologies, you should measure changes and manage them.

So, if you are working with project managers that are not reestimating the delivery schedule with requirement changes, you are really wasting your time on that company. You can find about this topic on any modern project management book, and you will agree with the idea that a requirement change implies a change in the delivery schedule.

If you think in software pieces like products or physical products, for example like building houses, if you have some UML diagrams, like class diagrams and sequence diagrams, which are specifying how the application should work, if you receive changes over those diagrams and specifications, is the same thing as changing a house plane, you need to rebuild and refactor everything, and it has a very high cost. The same applies to those applications implementing work flows, if they are implemented using precarious if statements, instead of using state machines, any change to the work flow will lead you very hard changes on the code. So you should measure and control each change, so you must do management.