What is a requirement? Most definitions describe a requirement as a “condition or capability needed by a user to solve a problem or achieve an objective”.
A condition or capability could be anything – a process step, a new template, a change to the accountabilities, or a new “Welcome” mat in front of the office.
It could be a new or modified feature of a business application sitting somewhere on a server or in the cloud and interacting with users through screens and signals, but it does not have to be.
Photo by form PxHere
Decades of business analysis being tightly embedded into the information technology function created a perception that requirements are only needed when technology is impacted. This led to the limited view that requirements analysis captures only system changes. Everything else will be taken care of “by business”, or by a mythical “change management fairy”.
This is often cemented into the mindset of a junior business analyst when they start their career with an organization that subscribes to this philosophy. In such an organization, business analysis is positioned as part of the IT function that “serves the technology”. It tasks business analysts with “documenting system changes”.
Not only this elevates project failure risk for the organization, but it also skews business analysts’ understanding of what their job is about. They are nurtured to become system analysts and servants to information technology. And as they move on to the next organization, they take this mindset with them.
This is how we breed a category of business analysts that think as system analysts and system engineers.
The “business” part of their title fades away and becomes just a prefix.
Dear business analyst:
Please remember that you serve the business – your client.
Your goal is to help your clients solve their business problems and achieve their goals.
You do this by helping them understand and visualize what they want to achieve – their future state.
You help them articulate and share their vision of future state by capturing it as business requirements.
Business requirements that you capture must describe the future state of business as a comprehensive and complete picture. This complete picture must include all changes to the business system that are needed to solve the problem to achieve the goal.
Yes, some of the business requirements will be translated into system changes or a design of a new technology solution. You will work with architects, solution designers, and developers on this part.
But in addition to this, you also provide a unique service to your clients beyond technology changes. Your role is to define all the changes, including those that do not involve IT.
The complete solution to a problem may include:
- Business process changes
- Organizational changes (new and changed roles and responsibilities)
- Business rules changes (including those implemented through policies and procedures)
- Logistics and environment (changes to locations, movement of people and materials, storage arrangements and relocation of resources)
- Communication requirements (including regulatory and mandatory communications)
- Documentation and marketing collateral updates
- Training requirements
All these changes need to be defined as requirements first. This is the best strategy to ensure that implementing these is included in the project plan, executed and ready when the technology changes are ready.
More posts in the Business Analysis Pitfalls category.
For more on types of requirements and how they are captured and managed, check out the book “Business analyst: a profession and a mindset”.
Contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.
1 comment