Managing changing project requirements
How to manage changing requirements on different software development projects.
Changing project requirements is a norm in software development. Today, businesses are trying to keep up with the high dynamics in the markets, technology and trends and expect the same attitude from technology vendors and partners.
To keep the product up-to-date, our clients may rethink their ideas, modify their concepts, shift priorities. They often add or bale on product features to better address customer needs and adjust to the ever-changing business space and market conditions.
In other words, the changes in project requirements are inevitable. We accept it and know how to deal with changing requirements on different projects. Also, we realize the importance of effective management in this environment.
Why managing project requirements is important?
Effective management of changing project requirements is essential for leading a product to a successful launch on time and within budget. Poor management, on the contrary, implies sufficient risks and losses:
- delays or a complete failure to meet important project deadlines,
- exceeded budget,
- misunderstanding within teams and between a client and a vendor,
- lack of control over the project development.
In order to avoid these risks, both clients and vendors should understand the importance of changing project requirements management and adopt reliable techniques to ensure its efficiency. And here come two issues:
- Often, clients don’t realize how serious the changes they offer are and what it takes to implement them. This confusion emerges for different reasons.
For example, stakeholders may lack the expertise to understand the technology and complexity behind the system and its functionality. In other cases, clients don’t follow the course of the project and may suggest modifying the key feature that in turn triggers the need to change many other features or reconfigure the whole system.
- When changing requirements appear at the final stages of product development, they are usually harder to manage and implement and call for more critical analysis. In many cases, these changes may cause significant delays in delivery and cost increase.
In my practice, both these issues and the causes of poor changing requirements management can be tackled or even avoided with the help of proper communication.
The best strategy for a service provider to overcome the first issue is to provide detailed estimations and hold explaining or educational sessions for a client. Do not just throw numbers at your clients. Let them understand how changes they request affect the system and why.
The second issue is harder to resolve. You have to constantly keep the decision-makers on the client’s side aware of the project development status, show the dependency between front-end and back-end functionality and project development stages when there’s still room for making changes.
Now let’s discuss how to deal with change requests on fixed-price and time and material projects.
Managing changing project requirements on fixed-price projects
Years of experience in IT showed me how even the projects with the strictest constraints and fixed terms are “alive” and require changes, add-ons and cut-offs. However, the projects with everything “fixed” – budget, scope, deadlines – can be dangerously affected by changing requirements if not managed adequately.
Therefore, it’s absolutely important for the management to analyze and discuss everything with the client – study requested changes, model potential alterations, compare current and planned functionality of the product, assess deadlines and budget. Together, they should consider the criticality of the suggested changes and the impact of their implementation on the project.
Read: What is a product analysis and strategy service and why it is important for business
In reality, there are a couple of established practices that help manage changing requirements on a fixed-price project.
- Change request is a standard procedure that allows a client to claim certain modifications, add features or cut down on some functionality.
When dealing with a change request, a vendor should make a detailed analysis to find out if the new features can substitute less important ones in the original scope to stay within the original project budget.
If this is not technically possible, or the project development roadmap doesn’t allow such a substitution, a software vendor and a client should decide either to increase the budget or postpone the change for the future product versions. The other option is to renegotiate on the payment schedule and allow a client to pay extra later.
- As a rule, a software vendor anticipates future changes and includes some extra to the fixed price so that to eliminate unnecessary negotiations and offer more flexibility with the requirements.
However, if the company adds extra 100% to the estimate for stabilization, then probably, this vendor doesn’t have enough experience in the project’s subject area or doesn’t have adequate expertise in requirements management. In this case, ask for a detailed explanation of the estimate to find out the reasons for such an increase.
Managing changing project requirements on time and materials projects
Time and material is a flexible approach to an IT contract that implies billing for the completed scope of work and in most cases is associated with agile development. Agile, in turn, is a common practice in IT that addresses the specifics of the projects with changing requirements. The tools and practices of agile enable this methodology to work best for non-fixed project scopes and ensure the product you are building stays up-to-date over the development and at launch.
Here’s what I mean by the agile practices that favor the effective management of changing project requirements.
- Agile keeps all the stakeholders in the loop. Traditionally, this method implies dividing the whole cycle of a software product development into regular 2 or 4 week-long sprints. Each sprint has its own goals, prioritization of tasks and delivery at the end and allows project stakeholders review the results of each iteration and provide feedback on the go. This process allows project stakeholders to literally follow the way the product evolves, make changes and shift priorities depending on the current needs and business requirements.
- Backlogs in the agile methodology also help manage changing project requirements and define the right priorities at the right stage of development. In short, backlogs are to-do lists that show the set of features and tasks to be implemented at every sprint. Each backlog depends on the results of the previous sprint and is open for input from stakeholders and teams. As a result, this order helps develop a project consistently, enable collaboration and make interim prioritizations reasonable and up-to-date.
- It’s habitual to hold daily stand-up meetings in an agile environment. This practice allows the ultimate transparency and visibility in the development process. Stand-ups promote communication, help team members follow and comment on the changes, connect different teams and allow managers to monitor the process with scrutiny and manage changes on the move.
It should be mentioned, that the agile methodology works only if there’s a product owner or other decision-maker on the client’s end capable of taking an active part in the product development requirements prioritization and management.
I don’t recommend taking time and material approach as an endless voyage that should consume your entire budget. Ask your vendor to start with an estimate providing optimistic and pessimistic costs, risk assessment and agree on a so-called estimate with a cap. Estimate with a cap implies that your vendor won’t charge you more than the sum set as a cap. The cap amount is usually close to the pessimistic estimate.
Read: Staff augmentation best practices
At Digiteum, we usually opt for agile development regardless of the type of project and know how to adapt to the workflow of the fixed-price projects to these practices. This approach helps us quickly adjust to and manage changing project requirements, keep the product up-to-date at every stage of development and delivery and engage the client in the development process to ensure transparency.
As a result, we are able to provide clients with quality software that stays relevant at launch and further, reflects the stakeholders’ feedback and changing needs and fully addresses the client’s most recent business goals and expectations.
