Featured in these publications:

Featured in these publications:


"Can you really fix most of these common requirements issues by using an 'Active' approach to Business Analysis?"

According to PMI , 47% of projects that missed the mark are there because of requirements management. Are you seeing any of these signs of r...

Friday, March 11, 2016

Is it BAD to be an Order Taker?

This is a copy of my post published on ProjectManagement.com

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 Taker

So 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 action

Your 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.


  1. Yes, Dmitri, this is a common occurrence. People can't tell you how they want the system to operate until they see it. Or sometimes you provide what they asked for, but after they see it, they want it to be different. And... different people will have different opinions. If you listen to individuals and try to give them all exactly what they ask for, you will never finish. Your prototypes are a great start to achieve alignment and buy in. I suggest you review them in groups and work with the group to form consensus before adding individual requests into your requirements list.

    The first priority is to know your constraints. If you are constrained by calendar time/duration, people/FTEs, and/or funds, then you must focus on providing the capabilities that will provide the most value to your stakeholders within the established budget. Agile approaches are great for this, especially where you have a dedicated business owner representative who compiles, manages and prioritizes the "backlog" of requirements. New requests get added to the backlog but if they don't significantly impact users' ability to follow the target business processes, they don't get top priority. It is often better to start with a simpler solution and then optimize it where it makes sense and where you have time and budget to do so.
    Whether you are building out a bespoke system or configuring a COTS solution, you must prioritize your team's investment based on the relative impact to the business. If you've provided maximum value within the available time and resources, you've done your job. If remaining capabilities are justified, then you may be able to obtain more time and/or resources to build them into the target system(s).

    One additional note, the business users are key stakeholders, but the operations and support groups are also stakeholders and their needs should also be considered. Adding an optimization feature for a power user may add confusion for the typical user which increases the cost of training and support, and may ultimately reduce user buy-in and adoption.

    1. Terry, thanks for taking the time to express your views!

      Forward thinking Agile practitioners have long since realized the value of challenging user requirements and getting to the real issues by using Specification By Example framework to get to business goals.

      While this is a valuable first step, Human-Centric Requirements offer more robust tools and processes for getting more consistent results.