Business analysis capability is a key success factor for all organizations undergoing changes — hence, for all organizations.
Enterprise requirements management is especially vital to the success of major digital transformation efforts or managing a wide initiative portfolio.
Mature business analysis practices succeed when they share and reuse requirements between projects.
It is important to understand and implement key steps to establish a reusable requirements repository.
Understanding reusability
Often, requirements are considered artifacts of a project useful only for the duration of the project.
Once the change is executed, the system is modified, or a new process is established, data and process requirements documentation is filed away in an archive folder and forgotten.
This is often a sign of an immature BA practice and a lack of appreciation for the value of reusability.
Quality business requirements can (and should) live beyond the scope of change. Once the change is implemented, the requirement — the definition of the desired capability — becomes a description of the actual capability.
In other words, it becomes a snippet of organizational knowledge.
Not only this is valuable to the organization’s knowledge management, but implemented requirements can also be reused in subsequent initiatives to:
- Describe the current state of a business process, function, or capability.
- Define relationships between business concepts and data management requirements.
- Reflect needs of internal and external personas.
- Capture key business rules that either need to be maintained by the new solution or consciously changed.
- Become templates or starting points for new requirements.
Requirement reuse can lead to a significant reduction in analysis time and improve the overall quality of business analysis outcomes.
Culture of Sharing
How to share business requirements?
When multiple analysts work on multiple projects, coordination and opportunities for reuse must be planned.
Projects tend to absorb all available time from the project resources, and business analysts are always at risk due to their skills and versatility.
One good practice is to establish a weekly meetup for the business analysis team where the main goal is to share what’s happening on each project, and what features and requirements are being analyzed or designed.
Even a simple sharing exercise can lead to the discovery of overlaps, gaps, conflicts, duplication of work and opportunities for reuse.
Team members can agree to coordinate and align their findings or split up the work, for example:
- Business rules captured by one initiative can be shared with the others.
- Personas that one project identified by analyzing marketing data and customer surveys can be reused by another initiative that impacts the same personas.
- A section of a high-level process captured by one analyst may be elaborated by another analyst focused on improving one of the sub-processes etc.
Opportunities for sharing are numerous — but for this to work, the leaders must be involved and promote the spirit of sharing.
Team huddles should be a priority as this will not work without broad participation.
Senior team members must be actively encouraged to make themselves available and provide mentorship.
Sharing and collaboration should be one of the development goals for the staff.
And no business analyst should be penalized for spending two hours explaining some of their work to another analyst who wants to reuse it.
Continuous professional development is an essential component of all effective organizations.
Effective Requirements Management Tools
When used intelligently, requirements management tools can help organize, package, and publish requirements to enable effective sharing and reuse.
There are many strong products on the market, often oriented to the agile planning methodologies.
Market leaders usually have comparable capabilities and offer similar features:
- Support for requirements hierarchy such as themes, epics, and user stories.
- Ability to organize requirements by features, impacted systems, business areas, project iterations or other grouping categories.
- Unique requirements identifiers and permalinks for ease of locating and referencing.
- Rich metadata and tagging of requirements to track business owners, keywords, audit trail, priority, business value, complexity and risk.
- Full traceability up to themes and business objectives, and down to design features, test cases and defects.
- Tracking discussions, attachments and artifacts associated with requirements or user stories.
In addition to obvious advantages for product development and project management, a requirements management and planning tool can provide additional benefits from the data governance perspective.
In highly regulated environments where tight requirements control and audit trails are enforced, such a tool will be instrumental to satisfy compliance requirements.
Robust Methodology
For most organizations, the choice of a requirements management tool, however useful, will not be a deciding factor of success.
A powerful tool can be mesmerizing and offer a promise of solving all the problems at the click of a button.
Business analysts, more than anyone else, should know that this is only an illusion. The tool will only record and store the information fed into the tool, and no tool can be a replacement for quality business analysis.
There is always a risk of focusing too much on populating the tool instead of tackling the business problem.
Identifying root causes is difficult and requires high-level thinking. The analysis involves unexpected discoveries, getting stuck and making mistakes.
The process of populating a tool can be comforting and create an impression that business analysis is going well, hiding the gaps in requirements behind the comprehensive-looking tool structure.
The complexity of the tool and the way information is stored may also be a deterrent for less technical team members and business stakeholders who may find it difficult to review rigidly structured requirements.
A business analyst may need to be inventive in planning validation activities that encourage feedback and do not intimidate the stakeholders.
The requirements methodology and analysis process must emphasize the discovery and analysis activities.
Capturing and structuring the requirements is one of the outcomes of business analysis, but not the analysis itself.
Conclusion
Creating a repeatable process for capturing, sharing, and reusing requirements give organizations the ability to implement changes faster and smarter.
Fostering the business analyst mindset and the spirit of sharing allows to create high-performing analysis teams capable of supporting fast-paced and effective changes at the enterprise scale.
This article was originally published in the DataManagementU blog.
Contact Yulia for training and consulting services to support your business analysis practice development.
2 comments