Requirements – from Wants to Value

Every project (usually) starts out with great intentions – bringing something of value to your customer. During the requirements gathering process though it can sometimes be lost upon everyone what value is bring brought to the table during the elicitation of the business requirements. Is there a problem that is being truly solved or something to help make it not so painful to deal with? This can be especially true with projects where a legacy system is either being replaced or modified. This post is going to focus on how business analysis and requirements gathering should be focused on business value as opposed to just framing the project.

Understanding the Problem(s), Challenges and Opportunities

The single biggest challenge facing business analysis professionals is the ability to see the business in the eyes of your stakeholders. Often times only a select few individuals from the business participate in the requirements gathering phase of the project which narrows the field of view for the project team. They may not be seeing the entire business view, as much as the sponsor or tagged business representatives may want to think they have a holistic view of the business but may not in fact have that global view of all the challenges the business faces that can be addressed. In addition to actual problems, there may be hidden opportunities or challenges that may not be realized as such that can be addressed through the project as well. By examining the customer from top to bottom and talking to as many stakeholders as it makes sense, the business analyst is able to formulate that intricate understanding and use that knowledge coupled with what the project team can offer to marry up solutions to those problems and opportunities.

Finding Solutions

The real value in business analysis comes from both understanding the problems that need to be solved but also in finding matching solutions to those problems through the implementation of your project. The Business Analyst is a key cog in the project in that they are the lynchpin that is able to effectively speak the language of the customer and the language of the project team, essentially translating the value proposition extracted from the requirements gathering processes to a business design that the project team can build towards (i.e. the project scope framework).

Writing a Value Declaration

This is where the project shows its worth to the customer – proving a solution that helps solve a real (and visible) business problem is the best way to demonstrate a solid value offering. Writing a value declaration isn’t something that necessarily should be in the business requirements since the requirements is just a statement of understanding for the problems, challenges and opportunities that are being targeted. By declaring the value that your project is bringing to the customer, you can correlate the identified issues from the business analysis phase with the proposed solution that your product (or services) can provide to your customer.

Requirements analysis is not just about creating a big matrix of requirements for your technical people to check off as they build it into the product but more about understanding what business problems are being solved by the project. How are you making their lives easier by conducting this work? When you as a project team can clearly articulate that to your customer, you will have a clear roadmap to project success!

Want to know how we can help you with our Digital Discovery service? Contact us

#digitaldiscovery #digitalexperience #requirements #findingsolutions #valuedeclaration

Featured Posts
Recent Posts
  • Facebook - Black Circle
  • Twitter - Black Circle
  • LinkedIn - Black Circle

© 2017 by QS2 Point