Are you still blaming users for new requirements? We're getting an overwhelming amount of feedback about common requirements trouble - from projects of all sizes, across all industries. Trouble like confusion around the scope and direction, lack of project alignment with business needs, getting stalled looking for perfection and end up missing the mark, trying to anticipate business needs instead of getting the facts, and many more.
Why is this all happening? Isn't that because of the lack of discipline among requirements holders, when they just keep on asking for different things - often late in our projects - throwing a monkey wrench into our schedules and our budgets?
Let's look at Stakeholder Management, one of the top time and energy drains for a lot of PMs right now.
Dealing with difficult peopleWhy are we seeing constant issues with 'difficult people'? Why are they keep on asking for changes, and new functionality?
Except for a very few cases of anti-social behaviour, most business people are not asking for changes just because they like to disrupt projects. They do that because, in a lack of robust processes for collecting requirements, critical realizations are often missed and they get later discovered as 'new' requirements.
If you're like most organizations out there right now, chances are that your stakeholders too have very little faith in your requirements process and feel the need to constantly interject and check on status and otherwise get involved with the project team.
And these requirements they 'discover' after the fact are anything but new requirements. They are just the ones that wasn't considered before.
So as the project progresses and time is passing by, stakeholders are continuing to unwind their feelings and continue to explain what they really wanted, even though these often perceived by the PM and the project team as net new requirements.
Not only this creates schedule and budget issues, as the project is constantly expanding to accommodate these unplanned changes - following these practices also creates a lot of frustration.
It's one thing when Agile is used to iteratively deliver functionality in small chunks with some changes and new features added with each new iteration. It's totally different thing when the business frequently doubts the value of everything that has been delivered to date because of a change in direction. Do this a couple of times and you're also facing morale issues in your project team.
So the critical realization here is this - all of this scope creep, this confusion, these stakeholder management issues - all of this is happening on our projects simply because nobody has taken the time to get all of the requirements early on - and then work with users to validate them.
Validating requirementsNow lot of organizations we're dealing with are still relying on a 'download' process -when a BA is sitting next to a stakeholder and simply asks them what would they like to see built or procured. The validation process is then reduced to simply reviewing the Requirements Document in a meeting and having the business sponsor sign off on each individual requirement.
Yes, that creates commitment and accountability but doesn't offer a reliable way for making sure that following these requirements will actually achieve desirable business goals.
If you have a user interface (UI) component to your project, validating becomes really simple. Your BA could start by creating a prototype. And you don't have to be fancy about it. Many times, a paper prototype or a set of rough clickable wireframes, taking a few hours to create, would just do the job. As long as the core functionality you're looking to develop or procure is represented, the prototype is doing its job. And then you could test it with users.
If no UI component is involved, BA can still bring people in from outside your key group of stakeholders and present them with sample outputs from a system you're about to develop and see if that would solve their problems.
Playing it safeNow what does a typical BA do instead? They just download the requirements.
And I'm not saying this aren't smart. It's nice to be a note taker and then blame it on business users. Won't even have to do that. Just keep quiet, do nothing else and the blame will still land on business anyways!
It's easy and it's safe. And they won't have to face the consequences. It's you, the PM who will have to explain why are you asking for more money yet again and when is the thing going to be ready.
BA has nothing to do with it. They asked what your key stakeholders wanted to do and they recorded it correctly. Look, they even got them to sign off on their notes!
Next stepsWell, I'm not saying your BA is sloppy or malicious. It may just be an education issue... And if you're ok with the situation, no action is required and you could continue with your rocky ride.
But if you're sick and tired of this blame game... of all this confusion and constant changes in scope and direction, if you are looking to build better benefit realizations from the start - you need to fix your BAs.
You see, requirements holders are not trained in business analysis, design thinking and requirements management. Most of them are used to expressing their needs in form of solutions. And it's not their job to take a step back and look for the real business goals behind what they are asking a project to do.
It's a job of a BA to see if directions should be taken literally or they need to be refined. It's not your stakeholder's job to create mock-ups and validate them with users either. It's the BA and the Designer's job.
So there you have it. You can blame and complain or you can take an action and provide your BA with the education they need to be effective at collecting all of your business requirements upfront and use reliable ways of validating them.
Would love to hear your thoughts. Please lay them out in the comment area below.