Defining business requirements for a technology solution isn’t just about what the business stakeholders want; it’s about what they need.
To discover what the business requirements are – wants and needs, strong business analysis is required, understanding what the business actually does, the overall process and how that business functional area defines success.
So many IT – business analysts sit down with the end users to gather requirements and ask them what they want. The analysts dutifully take detailed notes, ask a few questions, and then document their findings. While there’s some dialog, it’s inadequate. Even when a good analyst asks questions that lead to understanding exception handling for the solution, they may miss the key point.
What do the end users really need? Usually business stakeholders cannot convey their true needs to IT – and IT must engage in a dialog to ascertain the needs.
Many years ago, Harvey L., a senior vice president at NationsBank, shared with me the frustrations resulting from the role IT plays in providing technology solutions to the business. He stated that IT would spend months defining and documenting requirements, developing a solution, and then, after delivering it, be told that the solution wasn’t right. When IT would respond that the solution met what was requested, the business stakeholders would respond that maybe it was what they said they wanted, but it wasn’t what they needed.
A new online discussion site for project managers had a question posted recently by a project manager about how to get specific requirements. From the way the question was phrased, my take was that this project manager expected to be given the requirements through some fast sessions and be able to move forward from there. Sorry. It doesn’t work that way.
Not long ago I sat in on a session between the leader for IT for all of Asia-Pacific with his manager for business-technology initiatives (BT) and two key management end users. The frustrations with the solutions and understanding the business needs were palpable: The IT leader wanted to be told what it was they needed – yet they didn’t know how to express it. Finally, a dialog started with some whiteboarding and a bit of humor. The atmosphere lightened, the end users became more open and talkative, and soon everybody was nodding their heads yes, that’s it, that’s what is needed.
It’s not easy to get at what the business needs in terms of defining business requirements, but it’s absolutely crucial. Get it right the first time.
The Requirements & Analysis Phase of any software development life cycle (SDLC) takes up to about 40% of the timeline – the SDLC – and is the most crucial.
A missed requirement can cost a fortune, depending on when it’s discovered (e.g., does the missed requirement come to light after the project and system has gone live versus being discovered during coding), and can, in some cases, kill the project – or worse…
So why not get it right the first time? How do you get to the real requirements? How do you uncover what the business stakeholders really need? Defining the requirements involves detailed analysis, discussions and whiteboarding, and prototyping.
When I work with business users, regardless of whether I’m leading a transition engagement or determining how to solve some problems, inevitably we get to a whiteboard – or the very large Post-It notes that can be stuck up on walls around a meeting room. I’ve found doing this, whether I’m working with IT or with business associates, to be the most effective manner of getting to the real needs or issues.
Additionally, pictures work much better than lots of words. Believe it. It’s so much easier to convey complex subjects or problems when you can diagram what it is – somehow. It also establishes a common understanding and language for that problem or issue because, guess what, we don’t all use the same words to mean the same things. Even inside IT we need to do this to assure everybody “gets it.”
There’s no getting around it. In order to adequately address what business users really need, the IT leaders need to dive deeply into the business and understand the key success criteria, business processes, goals, and business drivers.
To do that, it means IT is aligned to the business – so they’re considered part of the business team. IT needs to become more bilingual, meaning the IT leadership needs to be able to think in both business terms and in techno-ese.
It’s heavy lifting. But it can be done.
First, be sure your IT is focused on the business and aligned to the business process areas. Have a business-savvy project leader and business analyst – and support the effort.
Getting smart about IT pays off when you get it right the first time, especially when it comes to getting business requirements right.
Note – December, 2014: I’m preparing a blog post series on requirements management and will also be sharing some special tools to blog subscribers. I recognize that requirements management is one of the most difficult undertakings in IT – and one of the most critical. Leave me your questions or challenges in the comments – and I’ll try to address them in the blog series! – Jessica