One of the biggest challenges of an IT project is to make sure that the agreed scope of services is clear and encompasses all the client’s needs.

The pre-sales effort of mapping those needs is often focused on the bigger issues and it is not uncommon that the original scope receives additional requests. When those changes impact price and delivery deadlines there is always place to dispute and aggravation. Since all businesses are on the move along with market dynamics, some changes are expected to happen, but there are diferent opinions when it comes to avoid the “change request minefield”.

Are change requests expected and welcome?

Some people advocate that change requests in IT are unavoidable, just like death and taxes. Dark humour aside, our experience shows that people get sidetracked by demands that are often not critical enough to demand attention. It only confirms the theory that the optimum compromises what is good enough.

A great number of change requests come from an incomplete pre-sales phase. In all those cases it will cause stress and discomfort to all parties involved. On the other hand, it is not always feasible to discuss each and every item of a project in depth, specially in times when everybody seems to be overwhelmed by their workload.

Each change request should be carefully evaluated by project managers on both sides of the table and compared against the established scope. Although the contract always reigns when it comes to establish what’s included – and what’s not – the point of evaluation should not focus only on the cost and timeframe.

Some changes are inevitable, some are strategic and some are just “nice to have”. We expect requests just as much as we appreciate new ideas. While the common sense perceive changes as villains, we find that the important point is how to manage and evaluate a request for change, so as to welcome contributions from the professionals involved in each project.

If the business demands the proposed change, is there alternative ways to implement it using standard programs and parameters? Is it possible to implement on a second phase? Does it need further specification? While the investment in a perfect pre-sales is silver, discussing alternatives and taking in new ideas is gold as a way to manage change requests and not let them knock your projects down.