Changing Requirements in Project Management: How to Stay on Track

Changing requirements is what project managers often have to deal with. Successful project implementation depends on a number of components that are important and interrelated. However, clear requirements are the key to a project’s success: according to the Project Management Institute, almost a half of unsuccessful projects fail to meet goals due to poor requirements management. What happens when clients or stakeholders repeatedly decide to change something after the team has already started work on a project and how to get this situation under control? 

Key Takeaways: 

• Changing requirements in project management cannot be avoided but can and should be taken under control. 
• Unmanaged requirements result in scope creep, budget overruns, resource overload, and project delays.
• Managing changing requirements involves the following steps: documenting requirements, establishing change control process, testing the impact of changes, approving or disapproving the suggested changes.

Changing Requirements: Who, Why and What Does It Result In?

Changing requirements are a common phenomenon in the project lifecycle that can become a real obstacle to a project’s success. They mostly come from customers and stakeholders. As for clients, they sometimes don’t know what exactly they want at the very beginning and may come up with better ideas afterwards. Also, they often don’t understand what consequences for the whole project their changes may have, and what it takes for the project team to implement them. The same can be said about stakeholders, as they sometimes don’t know what stands behind the project implementation: e.g. if it’s an IT project, they may simply lack the expertise to understand the technology and functionality of a system. Actually, making some changes is inevitable as customer needs may change over time, and the delivered project is expected to meet their needs. So, project managers should be aware of what these changes lead to and be ready to manage them.

The bad thing about changing requirements is not that they are possible, but that they can become uncontrolled and lead to project failure in the end. At least, they can result in a certain amount of rework. But the most common result of unmanaged changes in requirements is scope creep. According to PMBOKGuide, scope creep is defined as the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources. As the project team is expected to deliver the increased number of tasks with the same resources and in the same time, the following consequences become possible: 

• delays and even failure to meet important deadlines;
• exceeding the budget;
• overloading resources;
• misunderstandings among the team members and with clients/stakeholders;
• lack of control over the project;
• decreased quality of the final outcome;
• disappointed customers.

After all, the reputation of a project manager will be at risk, as it may seem that they aren’t able to take control of the situation. The solution to this problem is proper requirements management. Read further to find out what actions this process involves.      

Read more: Change Management Best Practices: Overcoming Pitfalls of Change Implementation

5 Steps to Manage Changing Requirements 

Effective management of changing requirements is the key to successful project delivery. According to PMI, requirements management is the discipline of planning, monitoring, analyzing, communicating and controlling requirements. It is a continuous process throughout a project. It involves communication among project team members and stakeholders and adjustments to requirements changes throughout the course of a project. Requirements management involves the following procedures.  

Setting and documenting current requirements

This is the first and really important step in managing requirements. You should list all the current requirements you have and then talk to all the project stakeholders and/or customers to make sure that you are on the same page. Then these requirements should be documented and shared with all the parties involved. This document will be your baseline, and if someone wants to make some changes, they will have to be thoroughly analyzed and undergo a change approval procedure.   

Testing the consequences of the changes

The other responsibility of a project manager is to inform of what will happen if certain changes are introduced, e.g.: the project will finish later than it’s expected, it may require more resources than available, the quality of the outcome will be different, or the project costs will change. 

In this case, project managers can make use of What-if analysis technique. It helps review and compare various outcomes depending on changes made to the initial data. What-if analysis enables project managers to evaluate possible outcomes, obtain better project predictability and make more reasonable decisions after all. Under conditions of changing requirements, what-if analysis is a handy tool for a project manager to predict future bottlenecks and demonstrate them to stakeholders/customers, so that they will know what impact their changes will have, resist the impact of those who want to change some small details again and again, and lead the project to successful delivery. It’s worth noting that project management software makes a project manager’s job easier: what-if analysis is performed by software tools like Epicflow that has a corresponding feature.  

Specifying change control procedure

Change control is the process that is used to manage requests for any changes that may impact the baseline of a project. This process reflects how requests for new requirements or changing the existing ones are handled. Whether it be formal or informal, it usually consists of several steps. 

1. A request for changing certain requirements is received.
2. A project manager should assess the following criteria to find out what this change will result in: project schedule, budget, resources’ capacity, and possible risks. Equally important is analyzing what the final outcome will be if these changes are not done. 
3. Finally, the decision on introducing changes is made. If it’s positive, the changed requirements should be documented, the project plan and schedule should be updated, and all the participants should be informed. 

Of course, stakeholders or customers who would like to introduce any changes to the project should be informed of the procedure of changing requirements and realize that no changes can be made off the cuff.  

Adjusting a project schedule

If any changes have been approved, it’s time to develop an adjusted project schedule. It will reflect all the requirements and the way they will be achieved in the form of tasks and milestones with start and finish dates. At this stage, it’s critically important to prioritize tasks. Prioritization will make it possible to avoid the situation when team members work on multiple tasks at the same time and are not focused on what is the most important at this particular time.  

The opportunity to create the list of tasks and milestones is provided by project management software. In particular, Epicflow’s Task List automatically orders the list of tasks according to their priority. Therefore, handling possible changes will become easier for both the project manager and the team, as delivering high priority tasks greatly contributes to overall successful project delivery. 

Communicating with the team

One more important thing is communication with the project team. They should also be aware of the change control procedure, and how these changing requirements affect their work. It may happen that some of the team members want to be helpful for stakeholders and agree to introduce some changes without their approval according to the procedure. Therefore, it’s critically important to explain the importance of following the change control procedure to them. Effective communication with the team will reduce to a minimum the possibility of misunderstandings and any unexpected actions on their side. 

Conclusion

Nothing is constant except for change: changing requirements is something you’d better come to terms with that fight. The purpose of requirements management is to help project managers avoid negative consequences of changing requirements. It involves the following procedures: setting and documenting current requirements; clarifying the consequences of possible changes to customers, stakeholders, and project team members; establishing change control procedure; and creating a project schedule. 

If you’d like Epicflow’s features to help you stay on track when project requirements are changing, do not hesitate to contact us.