Change is natural in projects. Some people even say that change is the only constant. But change also costs money and creates risks. Changing requirements are a major cause for project delays. The more a project has progressed, the higher are the related cost and risks.
But in most cases, I prefer to avoid changing requirements in my projects. Here are five undesirable causes for changing requirements – and my strategies to avoid them.
5 Causes For Changing Requirements You Want To Avoid
Cause 1: Requirements specify an awesome product but that product does not meet the customer needs
Have you ever been in the tricky situation, that in the middle of the project your customer told you what you’re doing is not what he ordered? That would be the time to wonder whether
- you did not understand what the customer wanted or
- the customer has never told you what he really wanted
How can you prevent this? You cannot completely. But you can reduce the risk of changing requirements because of these two causes. How?
- Discuss the needs with your customer
- Ask about his intentions behind them. Analyze them
- Address your ideas, your doubts, your expertise
- Do the same while and after compiling your set of requirements
- Make sure your customer understands the requirements you specified
Cause 2: Requirements specify an awesome product but they are not required to meet the customer needs
Being an engineer, it is in my blood to improve things. Then I tend to think (dream) about what is possible. And for some time I might forget to stick to what is necessary. If this happens during requirements analysis, there will be requirements that are not required: “requirements creep”.
If those requirements continue to exist, they will influence the design. They will generate cost. But nobody will pay for it. So when I recognize crept requirements, I want to get rid of them. And of all the traces they have already left. This will cost money, too.
How can you avoid requirements creep?
- Define and follow a requirements engineering process
- Go top-down
- Record the reason for each requirement
- Make sure the reason originates in a customer need or any other obligatory source
Cause 3: Requirements do not specify a functional product
For those who haven’t heard about it, here is a true story that is very annoying for (especially German) project managers like me:
The Berlin airport was finally supposed to be put into service in June 2012. Four weeks before that date it was announced that the airport “will not be ready”. It was terribly not ready: Now it is October 2015 and the currently planned opening date is in 2017 (edit: the airport was finally opened in October 2020). How could this happen?
I do not know many first hand facts about the details about the Berlin airport delay. From what is available in the news (and here is one article from a reliable news source), one of the reasons was (they call it bad planning) that some requirements did not specify a functional product.
How can you avoid changing requirements because they don’t work?
- Follow a structured Systems Engineering process
- Don’t talk about the design before you have specified the requirements
- Let an expert (someone who understands the business AND the problem) perform the requirements analysis
- Listen to the experts and only make planning or management decisions when you are sure about the impact
- If you are unsure whether a requirement can be met, analyze its feasibility
Cause 4: Requirements are ambiguous
Ambiguous requirements cause trouble at the end of the chain – when someone has to actually make a decision. How many are several? How big is optimal? How fast is sufficient? Which color is pleasant?
What is the right answer? The answers can only be given on the top of the chain. By the person who created the requirement. Sometimes only by the customer. Both of them may already have pushed their intentions to the back of their minds. Raising the issue – and changing requirements afterwards – cost efforts – and time.
So why doesn’t the guy at the end make the decision? Finally – he is the expert. Right, this might “somehow” work when he is the only one affected. The more people involved, the more dangerous ambiguous requirements are. What is the danger? Imagine: in a second location in the project another person might ask the same questions. And he or she might find different answers.
And more important: at the end of the project the person who is responsible for the requirement may be responsible for the acceptance. Look at the questions again. How big is the chance that two independent people would give the same answers? Ambiguous requirements will call for changing requirements. Do you agree?
So how can you avoid changing requirements due to ambiguity?
- Use clear language (fair enough: what is clear? – I found a great tutorial on modernanalyst.com)
- Communicate requirements: Discuss them openly when you hand them over. Make sure questions are asked. Have them reviewed by an independent person. Do not just pass them.
Cause 5: Stakeholders enforce changing requirements
Imagine the following fictional story you have definitely experienced before: the progress is as planned. You are highly motivated. You know that you will successfully finish the project. You can already see the finish line. So far so good.
Now comes the second part of the story. I hope you have never experienced this before: Just when you feel really confident and safe, the customer approaches you. “Hey, this is not as I expected”.
You are shocked. You did perform a stakeholder analysis in the beginning of your project. You did discuss the expectations and intentions behind each customer need. You did do everything to meet these expectations. So how could that happen?
Third part of the story: what can you do? You immediately talk to the customer. You remind him about all the intentions and expectations that were there in the beginning of the project. He agrees. But – for him the situation has changed. He was influenced. Not by you, but by the users, his colleagues, competitors – his environment.
The end of the story: either you accept his change or he will enforce it by escalation. In the second case the decision might be taken not by functional arguments but by political. In any way, the not so happy ending of this story will be: changing requirements.
What could have gone wrong? – My explanation is that the project manager did not manage the stakeholders throughout the project. Others did. They always do.
How can you avoid changing requirements due to the influence of stakeholders?
- identify your stakeholders
- know their expectations and concerns
- communicate with them to find out signs for changing expectations or other problems
- communicate with them to counteract changing expectations
- manage your stakeholders influence towards your project
What causes for changing requirements have you experienced? Share them below.