How to engage stakeholders who keep changing project requirements

I remember the excitement I felt the day we commenced the project. The team had assembled for the kickoff meeting; there was familiar anticipation in the air. The external stakeholders were equally eager and let us feel confident about the project and the collaboration.

As soon as we started working, we realised that even though we had captured the essence of the project, we couldn't capture project requirements correctly. We were shooting at a moving target in the dark. But this is a common woe, isn't it?

Project stakeholders having second thoughts? Let’s accommodate

Stakeholders who regularly change their minds are not unheard of. The perpetual onslaught of changes in project requirements leads to scope creep. The scope goes far beyond the original vision of the project – over budget, past the timeline or of compromised quality.

But you can't blame the stakeholders for changing requirements. They aren’t supposed to articulate requirements such that your development and design team will immediately understand. If it were out of your control, you could’ve shrugged your shoulders with a c'est la vie. But, the onus of managing changing requirements lies on the project team.

How to deal with stakeholders changing requirements?

Pay attention to communication: Keep internal and external lines of communication open and receptive. Be direct and ensure that you understand everything expected of the project team. The same applies to stakeholders. Convey the implications of additions and changes on the project constraints. Instead of reading between the lines, ask to spell out the details. The stakeholders may not always know what it takes from your side to fulfil their expectations.
Create a requirement approval process: With the help of stakeholders, establish a procedure that lays out the sequence of actions and interaction moving forward. A standard process ensures that any deviation is recognised as change and hindrance. This brings order to collaboration and makes it a better structured process. Working in an organised and mutually agreeable manner prevents the escalation or even occurrence of conflict.
Spend more time in requirement analysis: This is a given and sounds simple enough, but looking at the number of projects that fail due to poor requirement management, bears repeating. Spend adequate time in understanding the problem statements that motivate the project or the 'existing system' that you're replacing. Leave no detail of requirements gathered from stakeholders inadequately analysed.
Get clear SLAs: Service level agreements should be carefully worded and on time. Let agreements clearly state terms of the collaboration, the work environments and deliverables before you begin.
Be flexible and adaptable within reason: Be flexible, receptive, and reasonable. Best assume that requirements are subject to change. With this approach, you establish a positive relationship with external stakeholders and increase your chances of getting their approval later.
Convey the impact of specific changes: Stakeholders may not wholly comprehend the indirect impact of the changes in terms of person hours and other costs. Be upfront on how specific changes may lead to unexpected complications and delays in the project. Make stakeholders understand which changes lead to significant ripple effects.
Use requirement management software to set a change control process: Establish a foolproof change control strategy. Adopt a requirements management software to regulate the process of requirement extraction and management. It shouldn’t be just a series of changes conveyed from one channel and one person to another but a properly documented, transparent and trackable process. Software will present a clear picture of where each requirement stands, what tasks and responsibilities are marked against it and how it has evolved.
Establish a prototyping mechanism: Gathering requirements using a limited prototype is attractive to users since it allows key stakeholders to envision what parts of the product may look like and check if they have any concerns going ahead. Minor details that both sides may have missed otherwise may now be visible.
Go agile: Agile, iterative or scrum projects ease managing new additions and modified requirements. The backlogs in agile projects ensure that all changes, even new ones springing up on the spur of the moment are documented as 'user stories' or prototypes, documents, pictures – whatever describes the idea the best.

Refining some user stories form the product backlog and extracting requirements is entirely in your control. The development team gets to pick which stories to include in this sprint and which to keep in the sprint backlog.

If stakeholders are familiar with how scrum and agile work, expectations and schedules are managed accordingly. But not all projects are iterative and switching to agile is not always an option. The bottom line is secure stakeholder input early and often and shape the project collaboratively.

Better stakeholder engagement, better chances of project success

Perceiving value in stakeholder input is the mark of an excellent project manager. Project leaders must be a little flexible to engage with stakeholders to set projects on the path to success. Remember, it isn’t so much ‘us versus them’ as it is a partnership. Sometimes it still may not be ideal, but it is a part of the job; the not-so-easy job that is project management.

You may also be interested in:

_{fizkes/Shutterstock.com}