It’s 10am and the Requirements Session has Started… Do You Know Where Your Business Team Is?
When sharing Getting PredictableSM best practices, specifically around requirements definition, a common question that comes from I.T. management, Business Analysts and Project Managers is:
“How do I get the business to come to the table? How do you get the business folks to commit to the time needed to properly collect requirements for a project?”
Most business folks are very busy, but the underlying problem is more than just time management.
Many business users feel it’s a waste of their time. It’s truly annoying to have to tell the “tech folks” requirements. They’re gonna get it wrong anyway.
And you can’t really blame them.
Let’s picture their world:
You’re working 8+ hour days doing your full time business job. You have plenty of regular weekly meetings you go to, some that are a waste of energy. Now your boss tells you the tech team wants to meet to ask: “How you do your job” or “What features would you like in the new system”.
You show up and as you start sharing your thoughts, they keep suggesting a better way. At times, you hear things like “what you are asking for is very complex – or is undoable”. A bit frustrating, but you trudge on.
The Requirements Sign-off
Then the business users are asked to read the requirements and sign off.
First off, some of the documents read like a technical manual for a Sears Washer and Dryer explaining how to disassemble the drive motor and replace some fan belt so your washer doesn’t make that whining noise anymore. The part of the documents that do make sense to you are sort of right – but you’re not sure how much effort to spend to get it 100% perfect.
This might be a little exaggerated, but go ask your business user to read the above paragraph and listen to what they say. Many will surprise you with their feedback.
Over the next couple of months, the I.T. team asks a few clarifying questions here and there and some of the questions have no resemblance to your original requirement.
When you get the new software, it isn’t what you asked for. And the technology team is combative. The I.T. team is saying your requirements were wrong and that’s why the system doesn’t work properly.
Surprised?
Hmmm… Why in the world would the business want to experience this?
While a little exaggerated, I have to admit that over my career I have heard business users say this. There is some truth to these remarks and they represent obstacles for our teams.
That said, there are some simple ways to get the business to check in and truly get passionately involved. Here are some quick ideas to point us in the right direction:
- First and foremost, Listen.
The joke I share with my technical leads is that “Before we might say ‘no’ to a particular feature, at least listen to their entire request. Then you can say ‘no’”.
And yes – this is intended to point out that all too often, we start compromising a requirement because we know the business better, or their way takes four weeks to do and tweaking the requirement can get it done in one week with an off-the-shelf product. We need to listen to their full need and the “why”. Then you can be a partner and offer them options.
This brings me to the second suggestion.
- Give them Options.
Don’t simply tell them the system can’t send the data to all 123 data centers and get responses in under 30 seconds, assimilated in 14 languages and then graphed real time.
Explain to them this one requirement may take two years and 24 people to pull off and that if they would be willing, here are two or three alternatives that may work and would take two months to get completed. Ultimately it’s their budget and their choice on schedule.
They will feel less like something is being “done” to them and more like you are truly trying to help them through this process.
- Finally, Give them what they asked for and Quickly.
What I mean by this: If they asked for a special screen to do a quick side calculation, and you see they have energy, create a quick mock-up or even a prototype and ask if this is what they had in mind. Make sure you don’t embellish. Give them exactly what they asked for.
If you have a great idea, then show them a second version of the mock-up after you showed them theirs. Let them buy into it.
In an iterative world such as Agile, it is part Agile to quickly turn around a requirement for user feedback. Even in Waterfall, you can create anything from paper prototypes (see my previous Lo-Fi post) to a wireframe or real code for those scenarios that the user was really passionate about.
Before you know it, you’ll need a bigger conference room for your requirements meetings because all the different business stakeholders will want to come and give you “their” requirements. They won’t trust their colleagues to represent their opinion.
Do you have issues getting the business to come to your requirements sessions? How do you deal with it?
Category: Business-IT Alignment, Requirements Definition