The Importance of Business Requirements Gathering

This is 2015. Do we still need to even think about this topic? Isn’t it old hat? There are more technologies today than ever before, more IT enablement than the world has ever seen. Users are savvy and access to information has empowered them with even greater awareness, access to the benefits and convenience brought to them by new business models. IT technologists have access to a range of technical and education resources they may need literally at the touch of an online button. It seems like everyone is more aware of so many more things than ever, thanks to humongous amounts of information that are pushed to anyone who would care to receive them, and even to those who don’t. Project methologies have become very flexible. With so much more information and knowledge available all around, it’s amazing that the statistics on the failure of IT projects haven’t improved all that much over the years. Projects can fail for many reasons, and one of the leading causes is the quality of requirements. So, yes, not only is the art and science of business requirement gathering still worth a mention, it’s probably more important than ever. We have so many requirements management tools available today, so why are clear and adequate requirements still such a problem?

Perhaps the problem is that requirements are not seen as being a potential issue, or perhaps the need is not understood well enough. At the highest level, perhaps the single reason for this is that expectations are not being set and managed on either side. Either the business expect too much business knowledge of the technologists, or the technologists haven’t got a deep enough appreciation of the details of the business domain as they claim they have.

Very often we hear of IT led innovation or IT led transformation. These are terms that are used too loosely, I think. Whether IT leads the business or the business leads IT may seem like a chicken-and-egg or situation dependent issue, but really, at the root it’s always a business need that gives rise to an IT solution, regardless of how it may seem. In other words, IT will always only be creating solutions to real world problems. For example, Google’s driverless cars may seem like an IT-led solution, but is it really? Or is it just that the business problem domain (ie, how to drive) is already so commonly understood by so many, including the IT engineers, that those who work on the solution don’t really need to consult a business domain expert (ie, a driver) to understand the problem?

From the perspective of the lay business user the IT and analytics teams are often seen as black box problem solvers - give them the problem and let them figure out how to solve it. The truth is that the IT team is a group of people skilled primarily in information technology, analysis and project management. If they’ve picked up any sectoral expertise over time it is purely as an additional supplementary skill with limited depth, and their knowledge cannot be the same as that of an experienced business practitioner. Analytics teams know how to analyse data using various technical treatments, but they need be helped with continuous inputs that tell them what they are expected to come up with from a business point of view, and how to understand their data and their results from a business perspective. When this is not understood the end result is often not a solution to a business problem but merely an automation of the business problem.

It is this lack of appreciation of the needs on either side that give rise to the secondary causes of requirements not being good enough, and these are much more easily recognizable:

• Insufficient detail in requirements, or incomplete requirements
  
• Underestimating the complexities or timelines involved in delivering change
  
• Changing requirements not being incorporated into the project cycle on time
  
• Realities of the business environment not factored into the requirements .
  

The bottom line is that the same fundamental lesson never goes out of date: in order for technology to produce business results, the business teams and the IT or analytics teams need to spend enough time together to ensure that they have jointly understood and considered the business requirements down to the most thorough level in order for a realistic and workable solution to be produced.