Use a form such as the change request template that you can download here.

The next step is to evaluate the new requirement as it relates to different factors.

Trying to understand what the client actually needs should be your first step.

It might seem confusing, but more often than not there is a big difference between what a client wants and what they actually need.

People always want to stick with familiar processes. They don’t want to question why a process is done in a particular way. This can become a problem in scope definition when they are not aware of the big picture. Instead of tackling the core of the problem, they just care about fighting the symptoms.

Here is an example:

Take a scenario with two departments: A sales department which enters the customer orders, and a logistics department which packs the goods to be shipped to the customer. The sales department is unhappy with the work of the logistics team, as they often forget to add the necessary information to the shipment. That’s why it has become practice that sales is double-checking the shipments and makes final adjustments.
Is that the right way of doing things? No. The proper solution would be to train the logistics team to do a better job.

This one is very common in IT projects.

When replacing a legacy system with a newer system, the newer system is usually a lot more powerful than its predecessor.

The problem is that the client does not have enough of an overview of all the new functionality, and in makes requirements that are not needed.

Many of the tasks that had to be carried out manually previously are now automated. Many of the issues that users struggled with have been solved due to smarter systems and automation. Therefore, the change the customer is requesting may just no longer be required.

Example 1:

The client tells you they needs to be able to edit an address on the invoice form. On the new system the address prints automatically, making this additional step obsolete.

Example 2:

The client asks you to develop a “data check report” it can find errors in the customer orders. In a new IT system there may be no need for such a report, because the system automatically corrects any errors or automatically notifies the user in case their intervention is required.

Example:

The client requested a “printout function for purchase orders“. Your IT people had a technical perspective on it and called it “enhance printing interface for purchasing“. It’s the same thing, but with two different names.

Conclusion:

Be very precise in your communication and ensure consistent naming.

Once you have checked that the requirement is valid, here may still be a reason why the requirement wouldn’t be implemented.

Sometimes requests fall into a gray area and other times they are simply not allowed. This could be, because of a company policy disapproving of certain practices or it didn't meet accounting or legal standards.

If there is any kind of financial risk or potential loss of knowledge involved, make sure you check with the respective department. This could be legal, accounting, HR or another department depending on the area.

These two questions should be answered together.

I recommend that you discuss both points with the client and invite the manager of the person who raised the request.

During the meeting, I let the client explain why they need the change. In the beginning I might even respond with: We currently have no resources, but we’ll see how we can fit it in.

When do you need it by?

Can it wait after? [SOME IMPORTANT MILESTONE]

Naturally, the client will respond with "We need it as soon as possible! We can’t do our job without it!"

It’s not always true, but it’s the kind of bargaining that you should expect in such situations. It’s OK to challenge your client a little, but stay levelheaded and equitable.

You might find the following scripts helpful to qualify changes:

* If this item was so important, why was it forgotten in the first place?

* How often do you use/perform this process? (which requires the change)

* How would it affect your business if the [CHANGE] was not implemented?

* Is the change supported by your management?

After some discussion the client might even drop their requirement, because it’s actually not needed or you can agree on a later implementation date.

Whatever the outcome is, in the end the client will have to accept the extra budget for the change.

You make an estimate for the cost it takes to implement the change.

Don’t forget to track that number in your change log.

Now the change needs to be improved by management. Send the completed change request form to the managers who have been appointed as approvers.

The last step is to implement the change.