Change management: Change in requirements

Introduction
So you have just started to undertake a new exciting IT project, your business requirements are all mapped out and the development process is just starting. But, in the back of your mind you are thinking "Have we missed anything? Is this really how we want to operate? Is it too late to change anything?" Let's face it, we all get these thoughts, and with any IT project no doubt there will be changes in your requirements. The key is being able to identify change, then manage and implement it in a smooth fashion.

If you get change management wrong, you can end up with a lot of finger pointing, a larger bill than expected and, potentially worst of all, a system that doesn't meet your needs.

In this article I identify tips via a basic IT change control process, highlighting key steps and individuals to make changing your IT system as easy as possible.

Key people
When dealing with changes to requirements and systems, many methods seem to forget that real people are involved - the staff that help design the system; staff that will use the system day to day; or the developers building the system. If you are to succeed, then having these key people not only on board with your project, but also available to participate in reviews is essential.

The change process
To help provide tips on handling changes to requirements, I have identified a 'Good Change Process' that you can follow. I would always advise that this process

• Identification of potential change
• Change assessment
• Change implications (both process/system and development) and implications of not implementing change
• Change priority
• Implementation and review

Identification of potential change
The best way to identify potential change is to ensure that prototypes and working versions of screens and functions are reviewed by different staff members as early as possible. Typically reviews should include line managers, team leaders and some end users. The key to ensuring any change is identified is having the right people at these reviews. So remember the following:

Change assessment
Once a change has been identified, it needs to be verified. A lot of time and effort will have gone into the initial requirements gathering phase, and when looking at the bigger picture, it may be that this new change / requirement was omitted for a reason. Because of this, any changes have to be reviewed and signed off with the complete system in mind.

Change implications
This is often overlooked, but forms an important part of the change process. If you don't do this step well, then your changes could have negative effects elsewhere. You must understand all the implications of implementing this change, as well as what would happen if you don't implement the change.

You must look at:

• The basic fundamental requirement (Without this change does the system still work?)
• Implications on other modules / areas of the system for business users
• The day-to-day use of the system
• Implications on the system structure. Will the change require modifications to the database, stored procedures, multiple layers of code, multiple screens, and multiple calculation modules?

To find this information out, many different people will need to be aware of the change request and get involved in providing the necessary implication information. Again, remember people are at the heart of good change management, so you will need:

The aim of the change implications part of the process is to ensure that the requirement is implemented in a cost effective way that does not break other areas of your system.

Change priority
Some changes are urgent and they need to be done before work can commence on other areas of the system. However, depending on your project stage, the change priority may be very low. No matter what, an accurate priority must be allocated to the change and it must not drop out of scope.

I personally like to prioritize the requirement using the MoSCoW method. If you want to learn more about MoSCow click here. In this method you identify the requirement as:

• Something the system MUST have
• Something the system SHOULD have
• Something the system COULD have
• Something the system WOULD have

In essence, any requirements marked with an M (must have) must be implemented. S (Should have) has to be implemented or the system will not work at all well. C (Could have), the system could have this to increase system expectations. W (Would have), would have it if everything else has been implemented, there is enough budget, resource and time to get it done. Often these "would" have requirements get termed as "won't have"!

Implementation and review
The developer gets the change request, and because of everything that has gone on to get the change to this stage, he/she is able to implement the change as quickly and efficiently as possible. Once the change has been completed, any areas of the system that may be affected need to be tested and then reviewed. In many instances, a re-review throws up new additional potential changes, simply because the review group now can see the screen/function in more detail. This means this process can be iterated through any number of times, until everything is just right.

A simple change?
Change management of requirements sounds simple, and to some extent it is. However, like many things in IT, the simple things can have massive implications when they go wrong. If you handle changes in your requirements poorly, then ultimately you are left with budget issues, a system that doesn't meet your needs and finally, something that has a negative impact on your business in general.

So treat change management as one of the most important aspects of your solution. Take the time to ensure you have the right people involved throughout the change process and ensure that all involved understand how change is to be identified, assessed, implemented and reviewed. If you do these basic things, then you won't go wrong.

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.