Managing Change in Software Projects

One of the most difficult portions of executing a software project is the user acceptance phase since a lot of changes in the application are suggested during UAT. Project managers might think "Why can't the stakeholders anticipate these things in requirements phase?" or "We are getting changes even after getting the prototypes approved." Fair. But we have to accept the fact that software development is all about supporting and enabling a business function and in doing so, changes are bound to come.

Most of the times, end users cannot really anticipate certain things unless they see something functional. There is always going to be a disconnect between what has been analysed and what is actually required. On top of it, changes come because of changes in business priorities and processes.

As project managers, we have to accept this and include change management as an integral part of business development and project planning. A strategy should be defined to ensure that changes can be efficiently implemented without hurting project bottom lines. At times, it also helps to educate customer on technical implications of implementing the changes suggested.

So, how do we account for the changes in product development ? In blog post "Just because the project is over, does not mean it is done!" on "Random Thoughts from a CTO" skip suggests the following

• Add tasks in your product development projects for changes – Where the changes can still apply to the general scope of those projects, you should account for changes in those projects.
• Create product maintenance projects – Where there are a lot of smaller changes that relate to your products that can be grouped together in a project (and don't related to the scope of projects in the previous point), you should create separate maintenance projects to address the changes.
• Create infrastructure projects – Where the changes aren't directly related to the development or maintenance of your products (such as operating system changes), you should create separate projects to address and incorporate the changes.
• Educate customers and other non-technical people – Talk to your customers and others about the costs of incorporating new technology or solutions, both short-term (projects) as well as long-term (maintenance).  The better they understand both the value of these changes (long term stability, better security, improve ease of use, etc.) as well as the costs mentioned above, the easier it will be to support the new technology and solutions in the future.

In addition to the above, small and frequent deliveries can also help in reducing the risks related to major changes coming in later in the development lifecycle.

What have you done lately to effectively manage changes ? I would love to hear.