Are you a business analyst or product owner developing software requirements in a regulated industry? If so, you’ve surely encountered the challenges that come with defining and managing regulatory compliance requirements. And unfortunately, those requirements are among the most critical to get right. Faulty compliance requirements not only put your projects at risk, they can put your organization itself in a dangerous position legally and financially.
Understanding the challenges associated with defining and managing high-quality regulatory compliance requirements is the first step to doing just that. Here are 6 challenges that top the list.
- Managing regulatory compliance is extremely complex.
The business of managing regulatory compliance is not a simple one. In most organizations, it requires coordinated efforts across multiple teams as they respond to rapidly changing, hard-to-interpret laws and guidelines. Those teams must have strong capabilities in governance, risk management, and compliance – inter-dependent capabilities that are complex even in small organizations. They require highly experienced people and well-defined business processes. Business analysts need a clear understanding of this complex environment to develop complete, accurate compliance requirements. This is a significant challenge, particularly for new business analysts or those who are new to a regulated environment.
- Project, system, and regional teams view regulations from their unique perspectives.
Regulations usually impact multiple teams in an organization – crossing projects, systems, and regions or countries. Ideally, organizations want a consistent, comprehensive set of compliance requirements across these areas, but that’s not easy. Teams tend to focus on their own goals, because that’s how they’re measured. Developing a bigger picture view of compliance requirements is outside their scope. So interpreting regulations and developing solutions happens in siloes – within individual project teams, system teams, or regional groups. As a result, interpretations and solutions vary. Each team develops its own, duplicating efforts and leading to multiple systems to maintain over time.
- Regulations change.
Regulations change – often frequently – meaning governance, risk management, and compliance requirements can also change. To complicate matters further, multiple regulations may emerge or change in the same timeframe – leading to a complex matrix of impacts to systems, projects, and processes. Even in-flight projects must accommodate the changes induced by regulatory change, which can lead to serious delays and increased costs. Product owners and business analysts have to perform solid analysis quickly to stay in pace with regulatory change and adapt requirements appropriately without impact to project timelines and cost.
- It’s tough to get to the right stakeholders at the right time.
The subject matter experts that represent compliance requirements – people from legal, risk management, or audit teams – are just darn busy. They have competing priorities, and they’re not usually part of core project or system teams. The result? It’s tough to get enough time with them to elicit requirements. And when regulatory change impacts multiple teams, all of which are developing compliance requirements in their silos and seeking time with compliance stakeholders, issues are magnified. Stakeholders are asked to spend time in multiple elicitation sessions, answering similar questions. They become frustrated and less likely to participate willingly. Their participation, however, is crucial. Failure to get enough interaction with the people who can answer compliance questions accurately can keep a business analyst or product owner from developing a complete, true view of compliance needs.
This challenge is often more difficult for Agile teams, because they thrive on collaboration and shared accountability within a core group of full-time team members. It’s tough for Agile teams to figure out how to involve stakeholders outside that sphere. They’re likely to be unavailable when Agile teams need them, and without their timely participation, product owners are faced with a difficult decision: Live with unclear requirements or develop lower priority features until the right people are available for elicitation.
- Teams don’t (or can’t) do robust analysis.
Given the complexity of the regulatory environment and the diverse, distributed nature of large organizations, analyzing regulatory change, assessing its impact, and identifying potential solutions is time-intensive. Teams often underestimate the effort needed. This is a major challenge for Agile teams that seek to reduce pre-work – including a lengthy up-front requirements phase – to avoid the “analysis paralysis” teams often experience. Teams that underestimate the time needed for elicitation and analysis of compliance requirements experience increased risk of getting them wrong. They also reduce the likelihood of identifying opportunities to leverage work across systems or projects.
Additionally, many organizations haven’t invested in purpose-built requirements tools – tools that provide functionality for defining new object types, visual modeling, precise multi-directional traceability, and requirements reuse. Without those capabilities, it’s difficult for business analysts and product owners to perform the analysis needed to identify missing user stories, prioritize the backlog appropriately, and fully understand regulatory change’s impact.
- An Agile bonus challenge: There’s no good mechanism for capturing non-functional requirements.
There’s not a great solution for documenting compliance and other non-functional requirements in traditional Agile methodologies. Teams could capture them as user story acceptance criteria, but they’ll inevitably apply to multiple user stories, leading to duplication of information. With information spread across user stories, teams lack the ability to keep it consistent and manage change. It’s also impossible to generate a clear, comprehensive view of compliance requirements. Alternatively, teams could resort to Agile’s “definition of done” artifact. This artifact, however, isn’t written at the level of detail needed to be actionable for testing or deployment. It’s intended to be a reference – a tool used to assess completeness and outlying tasks.
If regulatory compliance requirements challenge you, stay in touch! This is the first of a series of blog posts to help you get them right.
For more information or a demo of Blueprint’s support for compliance requirements, please contact us today.
