I've been talking to a lot of readers lately and a lot of people are seeing frequent changes in scope and direction on their projects. Users come at them from different directions. Right when they just completed a change request and had a chance to regroup and do a little planning, another two are coming down on their laps. And it sends schedules and our budgets way out of the ballpark again.
And there's a lot of followers of the Servant Leadership style, who are trying to play along. "At the end, users will use the system, so they better tell you what they really want". And yet another change request goes down to development or another RFP is issued for a new vendor solution and the cycle continues.
Some years ago I personally was involved in a project where a vocal BA has been bullying project managers into constantly accepting new features into a project, until 3 years later they have finally ran out of ways to expand their budget and got themselves shut down.
And a lot of PMs out there have seen this happening or have been beaten on the head with similar horror stories, so they fight their users tooth and nail to keep these additional requirements out.
Being an Order TakerSo is this ok to be an Order Taker or is it your job to protect your scope and your budget from poachers?
The answer comes when you "step back" and ask yourself a question - where do all these 'additional' requirements are coming from?
You see, many times, when a stakeholder is asking us to initiate a project, more often than not, they are also 'recommending' a solution. And if you're a consultant, you probably should not try your luck at proving them wrong right there and then.
And even if the solution was not prescribed by your stakeholders initially, chances are, your Business Analyst has been asking them questions like "What would you like us to build?" - and that leads the project in a wrong direction.
More often than not though, your users will be almost right, but pieces will be missing and some of these requirements, forgotten or omitted in analysis, would resurface later on as change requests.
So you may have to take orders, but being a PM worth your salt, don't just assume that your business requirements are complete or perfectly accurate when they hand them off to your team for implementation. Do your own analysis.
Watch business users follow the processes that you're trying to improve. See how they're doing things right now... Ask them about the biggest issues they facing in their jobs. Don't ask them what they would like you to build. It's not their job to design a solution!
Have your team start with a prototype. And you can get a lot of mileage with paper, Visio or other quick and easy visualizations of what will your completed product be like.
Then ask your business users to 'use' it. Don't tell them how. Just put them in fro
nt of the prototype and see how they do.
Taking actionYour user research activities would most definitely bring results. You may end up finding holes in your requirements and occasionally you'll find your project going in the wrong direction altogether. What were they thinking?
Don't jump the gun. Consider the circumstances, your role and the local politics. If you want to make a difference and really help your org - don't get yourself fired!
It may be a slow process and you may need to be politically correct and keep on asking non-threatening questions and use your soft voice for a while, slowly guiding your stakeholders and your sponsor in the right direction.
You'll succeed in the end and they will appreciate your contribution. Just remember, it could be a lot easier to find the root causes and real reasons behind things then to get people to admit things and get them on board.
Were you in a situation like that? Have you tried any of these approaches in the past? Would love to see your thoughts in the comments area below.