Changing the Conversation on Software Requirements: The Role of Business and IT
What, Truly, Is the Role of a Business Analyst?
Recently I came across the question “is a written [software] requirements document really necessary?” in a Business Analysis forum. I found the question intriguing and had to look at the discussion around the topic. A lot of the discussion revolved around methodologies (Agile vs. Waterfall) or around requirements techniques (diagrams vs. words). One responder claimed that “the creation of the requirements document is central to BA’s business existence.”
I was bothered by this direction of the conversation. To me, if “the creation of the requirements document is central to their business existence” then the Business Analyst (BA) is not focusing on the right way to improve requirements or to ensure project success. To me, what is central to a BA’s existence on IT projects is to focus on ensuring that the team is providing the agreed to business value for the client. Any documentation is simply one method of communicating the business need and what success looks like to the business stakeholders.
Poor requirements or scope creep are often listed as top reasons why projects fail. We’ve all heard statistics, such as, “more than half of all IT project fail to meet the business requirements”. At a recent webinar hosted by Geneca and Forrester Research, the Forrester analyst pointed out that finding and fixing a software problem after delivery is 100x more expensive than finding and fixing it during the requirements or design phase. Obviously there is a need to ensure that the requirements process is successful.
Think Beyond the Documentation
However, is creating “better” documents going to provide this success? Is more and more documentation going to provide this clarity? Is developing the “perfect” template going to solve the problem with requirements? If the focus is only on improving the requirements by creating better documents or providing more documentation, then I believe that the team is missing the root cause of why the requirements need to be improved.
Most of the BAs that I have worked with are competent and create readable documents. Although they work diligently at capturing all the project requirements, projects can still go awry. The business complains that IT isn’t delivering what they asked for. IT complains that the business doesn’t really know what they want. Business stakeholders “sign off” on detailed requirements documents without really understanding their content. Development teams create software without really understanding what it is that they are delivering.
Perhaps what we need to do is to make the conversation about understanding what needs to happen in order to accomplish the goal of providing true business value. To do this, the business stakeholders need to be accountable for defining what is of value to them – defining what success means. And, all of the business stakeholders for a given project need to be aligned on what success for the project means. If the stakeholders don’t have a common vision of what success for the project means, how can IT be expected to deliver a successful solution?
Create Clear Accountability for the Definition of Success
Likewise, IT cannot tell the business what success is. It is not their job to tell the business what they can and cannot have. The IT team needs to be accountable for listening to the business stakeholders, understanding what success is from the business’ perspective and then communicating what it will take to deliver to that vision. IT can offer alternatives and suggestions on ways to deliver to the business’ vision in a timely, cost-efficient way. But, ultimately the business stakeholders own the decision on which alternative to accept. The entire team – both business and IT members – are then jointly accountable for the success of the project.
In this environment, the role of the BA shifts from just being a creator of documents to being accountable for communicating this common vision to the IT team and helping ensure that they provide a solution that meets the business vision. The requirements documentation becomes just one of many vehicles to help accomplish this goal, not the end goal of the role.
What is the expectation for the BA in your organization? Are you expected to be a documents creator or to take a more active role in ensuring that the right solution for the business is delivered?
Next week, we’ll talk about how to carry the common vision throughout the project in order to deliver a solution that truly delivers business value.
Photo Credit: Incase
Category: Business-IT Alignment, Defining Success, Requirements Definition