Why do requirements change?

You’ll often hear from consultants that customers are always changing their requirements. Meanwhile, their clients will often tell you that what they wanted has been consistent from day one. Without proper understanding, this can lead to frustration on both sides.

So, who’s right?

The short answer is that they both are. The subtlety lies in the distinction between “requirements” and what the client “wanted”. 

A client will often approach a design services company with a requirements specification. This specification represents the client’s concept of how to achieve what they want. It should not be confused, however, with the want itself.

Let’s take a low-tech example. The client wants to feed birds in his garden. He decides he’d like to solve this problem using a bird table. He writes a requirements specification with table dimensions, height of the supporting post, weatherproofing requirements, etc.

The design team come up with some concepts and show them to the client and his wife. At this point, his wife points out that cutting the grass around the base of the bird table is going to be a pain and comes up with the idea of hanging it from a nearby tree. He agrees, so the requirements change, but what he wants, to feed the birds, is still the same.

What happens next? The team updates the design, replacing the post on the bottom with a chain from the roof. They show the new drawings to the client. The client likes the design, but realises that now the table is hanging, there’s a problem. The fat balls that he likes to put out for the birds will roll off the table if a larger bird lands on one side. The design team propose to add higher sides to the bird table. The requirements have changed again, but the client still just wants to feed the birds in his garden.

The team now move to a prototype; it looks great, and the client hangs it in his garden to try it out. He returns to his house and turns to admire the new bird table through the window, but already there’s a problem. A squirrel is climbing down the chain and over the roof to steal the bird food. New requirement: the table must be squirrel proof.

At ITDev, we don’t design bird tables (unless you have an idea for a connected IoT bird table… hmm… that could be a thing), but this story illustrates just some of the factors that lead to requirements changes…

• Input from other stakeholders (the idea to hang the table from the tree)
• Missing requirements (the need for the table to work with fat balls)
• Unexpected external factors (the squirrel – although in my garden I’m not sure that would qualify as “unexpected”)

From the client’s perspective all he’s ever wanted was just to feed the birds.

From the team’s perspective, the requirements keep on changing.

The moral of the story is the need for empathy, communication, and realistic expectations on both sides.

Engineers must find out, understand, and keep in mind the client’s fundamental goal. Requirements specifications are important, but they must be seen as part of a much wider information exchange between the client and the team. Changes are to be expected and are part of the product development journey. This may result in wasted effort, so everyone should do what they can to minimise that. The concept review, design review and prototypes in the example all help with this, but avoiding all wasted effort is unrealistic. Engineers shouldn’t be frustrated by this, but instead act as fellow travellers on the journey, collaborating with the client to find the best route to their fundamental goal.

From a client’s perspective, it’s also important to understand the difference between the requirements specification and your goal. Keep in mind that the time, effort and cost to implement your requirements may ultimately be quite different to the time, effort and cost of reaching your goal. Help the team to understand your goal as well as your requirements and you stand a better chance of taking a more direct route to get there. Maybe the team will suggest building a bird feeder instead of a bird table and you’ll reach your goal even quicker than you expected.

What ITDev can do for you

We can assist you in achieving your goal and solving your problem. Through open, frequent communication we look to understand your aims, help to capture and refine your requirements as required and ultimately guide you to find the best route to your goal.

If you have any questions or would like to find out how we can help you with your product development journey, initial discussions are always free of charge. We would be delighted to speak to you so please contact us.