When (not if) software requirements change

A young acquaintance asked me this question.

How is it best to handle mid-project changes from clients? Are there times when a project is beyond the point of some kinds of changes? How is it best to resolve such issues?

Every project experiences specification changes; it’s a normal occurrence and a part of the business of software.

It’s important to understand that one of software’s key strengths is the ability to adapt to changes in requirements. (This sets software engineering apart from other disciplines; obviously it’s next to impossible for civil engineers to add major capacity to a bridge half way through construction for example.)

To say that software CAN adapt to changes is NOT to say it’s easy or cheap to do so. Unfortunately the temptation is to say “we CAN accept this change request therefore we SHOULD accept it.”

Good software contracts (like all good engineering contracts) make reference to a change-order process. That process requires specification, estimation, and agreement on extra time, development and QA costs, and deployment costs. (Deployment costs include user training, extra hardware, and other expenses.)

And, a wise project leader responds to change requests from the customer by saying, “yes, and here’s the process we use to work out how to honor your request.” An experienced customer will say, “OK, good, let’s work this out.”

An inexperienced customer may push back saying “it’s just a small change, can’t you just do it?” This is where the personal ethos of the project leader comes into focus. The leader must be able to say with credibility, “We use this change-order process because hard experience has taught us it’s the way to meet your requirements professionally.”

This level of professionalism delivers good results. It is very difficult to achieve in a software organization with sales people who don’t follow the process. It’s important for the sales people to understand that change orders are a vital part of the software business opportunity, PRECISELY because of software’s flexibility.

If the sales people continually say “yes” to customers’ change requests without following a change order process, then it’s time to get new sales people. Why? Because they are damaging the business. They are leaving money and customer goodwill on the table by giving changes away. Any fool can make quota selling 1000 rupee bills for 50 rupees each, and that’s what free changes mean.

When a software project has reached alpha-test stage, the cost in time (delay) and labor to make major changes is high. So what do you do? It’s impossible, in business, to say, “No. Too late. F**k off” to your client. That’s why you need a robust change order process: it sets their expectations at a level you can meet. It makes your customer into your partner in the decision making process.

In the real world this is sometimes difficult. Often big money and and bigger egos are at stake. That’s why I suggest beginning the conversation saying “yes, and here’s how we do it” rather that saying “no.”

Leave a Comment