Quando o Agile atende à conformidade regulatória

O fornecimento de projetos regulatórios é sempre uma proposta de alto risco para bancos. Diante de um ambiente de conformidade cada vez mais exigente, os bancos hoje estão investindo quantias extraordinárias de tempo e dinheiro nesses projetos. O banco médio gasta aproximadamente 40% a 60% do seu orçamento de mudança na conformidade regulatória - mas diminui uma parcela significativa desse investimento em ineficiências. À medida que os regulamentos continuam a se expandir, as empresas precisam mudar fundamentalmente sua abordagem.

Um novo modelo ágil oferece aos bancos uma abordagem alternativa promissora. A percepção entre os executivos bancários-e entre os membros do conselho-é que o uso de métodos ágeis em projetos de conformidade regulatória multi-diária e multimilionário é arriscado e impraticável. Pela nossa experiência com os clientes, acreditamos que essa percepção é falsa. Estimamos que o uso da abordagem ágil pode cortar os gastos dos bancos de 20% a 30% e pode melhorar significativamente sua capacidade de fornecer projetos regulatórios no prazo.

Um modelo desatualizado

Os bancos são naturalmente conservadores em sua abordagem à conformidade regulatória - e por um bom motivo. Falhas graves podem resultar em multas, restrições regulatórias, ações legais e danos à reputação de um banco. Mas, à medida que os requisitos regulatórios continuam a se expandir no escopo, o modelo tradicional de conformidade regulatório é menos eficaz e parece cada vez mais desatualizado. Para a maioria das empresas, uma abordagem rígida e seqüencial ao design e desenvolvimento de software é comum, mas leva a um desperdício extraordinário em uma grande maioria dos projetos regulatórios. legislação. O processo legislativo enfrentou vários atrasos, e os requisitos de nível 2 para o MIFID2 aumentaram para mais de 5.000 páginas. A abordagem tradicional dos projetos regulatórios não é ideal para implementar esse tipo de diretiva, porque seus métodos inflexíveis podem resultar em desperdício. Os bancos ficam atolados na fase de requisitos, tentando abordar todas as contingências possíveis, quando não tiverem todas as informações necessárias para fazê -lo de maneira eficaz. À medida que os novos requisitos são anunciados, a fluência do escopo se torna impossível de evitar, e as equipes devem voltar à prancheta para reformular os requisitos-tudo o que pressiona para criar soluções intermediárias para que não fiquem muito atrasadas nos prazos. Os empreendimentos clamam para o ágil:

Take the European Union’s Markets in Financial Instruments Directive (MiFID) 2. This directive—which aims to change how stocks, bonds, derivatives, and commodities are traded, cleared, and reported—began as an 80-page level 1 piece of legislation. The legislative process has faced numerous delays, and the level 2 requirements for MiFID2 ballooned to over 5,000 pages. The traditional approach to regulatory projects is not ideal for implementing this type of directive because its inflexible methods can result in waste. Banks get bogged down in the requirements phase, attempting to address every possible contingency, when they don’t have all the information necessary to do so effectively. As new requirements are announced, scope creep becomes impossible to avoid, and teams must go back to the drawing board to reframe the requirements—all while pushing to create interim solutions so they don’t fall too far behind on deadlines.

A New Model

The new agile model can be an extremely effective tool to help banks navigate the unexpected twists and turns that come with regulatory projects—and these large-scale IT endeavors cry out for agile:

• Os projetos são caros e de alto risco. Departamentos.
• They have tight, indisputable deadlines.
• Regulatory requirements are unclear at the beginning, open to interpretation, and evolve over time.
• Each new regulation requires a novel technical solution that touches many applications, systems, and departments.
• Overdelivery é comum - e caro para as organizações. Ele apresenta novas maneiras de trabalhar que alguns funcionários podem achar desconfortáveis ​​no início, como iterações curtas que permitem que as equipes identifiquem erros e reagem às mudanças rapidamente, colaboração em equipes multidisciplinares e transparência e responsabilidade total. No entanto, esses princípios podem ser extremamente eficazes na transformação da capacidade de resposta dos bancos às mudanças regulatórias. (Para uma visão geral dos princípios ágeis, consulte a barra lateral.)

But agile is not a quick fix. It introduces new ways of working that some employees may find uncomfortable at first, such as short iterations that enable teams to spot errors and react to changes quickly, collaboration in multidisciplinary teams, and full transparency and accountability. Nonetheless, these principles can be extremely effective in transforming banks’ responsiveness to regulatory changes. (For an overview of agile principles, see the sidebar.)

To use agile successfully on complex regulatory projects, organizations need to give special attention to several key aspects of the implementation. Companies that can master these best practices have an opportunity to accelerate ahead of their competitors and improve the effectiveness of their Abordagem da conformidade regulatória .

Crie uma equipe central. Na maioria dos casos, esse grupo inclui muitos negócios e os membros de TI que não são necessários regularmente, o que desperdiça tempo e diminui o foco da equipe. Em vez disso, uma equipe central de especialistas pequenos, mas totalmente dedicados, pode funcionar de maneira muito mais eficaz, com base nos negócios e recursos de TI somente quando necessário. Com uma equipe estável e central - liderada por um forte proprietário do produto - todas as partes interessadas ganham muito maior transparência nas áreas em que a equipe fez progresso, tarefas que ainda precisam ser realizadas e impedimentos à conclusão. exemplo). Particularmente com projetos regulatórios grandes e complexos, a resolução rápida de problemas é essencial. (Consulte Anexo 1.) Embora esse número possa chegar facilmente às centenas por dia, as empresas devem priorizar os 20 ou 30 itens principais no backlog. Ao fazer isso, eles podem criar rapidamente um plano de ponta a ponta para entrega incremental. E eles podem determinar facilmente quais recursos são essenciais para atender aos requisitos regulatórios. Priorizar o backlog para eliminar itens não essenciais pode produzir economias substanciais. Em nosso trabalho com um banco, descobrimos que apenas 40% das centenas de milhões de euros que as equipes do projeto solicitaram para projetos regulatórios eram essenciais para a conformidade. Requisitos regulatórios em pedaços claramente definidos e gerenciáveis ​​que podem ser entregues de forma independente. Dessa forma, eles podem fornecer continuamente partes importantes dos requisitos, em vez de tentar entregar todo o projeto em um empurrão maciço. Algumas organizações estabeleceram uma autoridade central de design para gerenciar o atraso dos requisitos, identificando novos, dividindo -os em itens individuais para cada área impactada e incorporando -os na lista de pendências. Essa abordagem beneficia a equipe ágil porque a autoridade de design analisa um requisito regulatório apenas uma vez, simplificando o esforço geral. Quando isso acontece, os bancos ficam lutando para abordar mudanças imprevistas - sob prazos extremamente apertados. Saber quais requisitos implementar e em que ordem pode ser difícil. Por esse motivo, a abordagem seqüencial padrão geralmente requer modificações substanciais e, ausentes dessas mudanças, essa abordagem pode levar as equipes a perder os prazos cruciais. Em vez disso, as equipes devem se esforçar para criar rapidamente um produto mínimo viável, testá -lo, aprender o que funciona e iterar até que ele atenda ao requisito. When planning for and implementing regulatory projects, many organizations make the mistake of creating an overly large project team. In most cases, this group includes many business and IT members who aren’t needed on a regular basis, which wastes time and diminishes the team’s focus. Instead, a small but fully dedicated core team of experts can work much more effectively, drawing on business and IT resources only when needed. With a stable, core team—led by a strong product owner—all stakeholders gain much greater transparency into the areas where the team has made progress, tasks that remain to be done, and impediments to completion.

To provide support to the core team, companies should consider establishing a separate acceleration team that focuses on resolving conflicts and addressing barriers to implementation (by ensuring that teams have the proper tools to work efficiently, for example). Particularly with large, complex regulatory projects, rapid issue resolution is essential.

Prioritize and groom the backlog. Over the past five years, the number of new regulatory requirements has tripled globally. (See Exhibit 1.) While this number can easily reach into the hundreds per day, companies must prioritize the top 20 or 30 items in the backlog. By doing so, they can quickly build an end-to-end plan for incremental delivery. And they can easily determine which features are essential to meet the regulatory requirements. Prioritizing the backlog to eliminate nonessential items can produce substantial savings. In our work with one bank, we discovered that only 40% of the hundreds of millions of euros that project teams requested for regulatory projects were essential to compliance.

Divide requirements into clearly identifiable pieces. Teams should break down regulatory requirements into clearly defined, manageable chunks that can be delivered independently. In this way, they can continually deliver key portions of the requirements rather than attempting to deliver the entire project in one massive push. Some organizations have established a central design authority to manage the backlog of requirements by identifying new ones, breaking them down into individual items for each impacted area, and incorporating them into the backlog. This approach benefits the agile team because the design authority analyzes a regulatory requirement just once, streamlining the overall effort.

Stay in sync with the regulator. It’s a fact of life for financial institutions that regulations imposed on banks change over time. When this happens, banks are left scrambling to address unforeseen changes—under extremely tight deadlines. Knowing which requirements to implement and in what order can be difficult. For this reason, the standard sequential approach often requires substantial modifications, and absent such changes, this approach may lead teams to miss crucial deadlines. Instead, teams should strive to quickly create a minimum viable product, test it, learn what works, and iterate until it meets the requirement.

Para conseguir isso melhor, o proprietário do produto deve permanecer em contato regular e próximo com o regulador, não apenas para garantir que a equipe integra alterações regulatórias no backlog do projeto, mas também para reconhecer quando o regulador é atendido. Um banco europeu teve grande sucesso com essa abordagem. A equipe ágil do banco convidou o regulador a participar de grandes eventos, como as críticas da Sprint. Ao participar dessas discussões, o regulador ganhou total visibilidade sobre como o banco estava progredindo e forneceu contribuições valiosas para a equipe ágil. Às vezes, quando o regulador determinava que os resultados da equipe eram suficientes e que uma implementação adicional agregaria valor limitado, o regulador estava disposto a ajustar certos requisitos. Esse processo começa com os membros do conselho, que devem entender o porquê e o quão ágil é usado em projetos regulatórios e apoiar totalmente a abordagem. Também requer confiança entre os funcionários, que podem estar acostumados a gerenciar uma parte discreta de um projeto e agora devem trabalhar em colaboração para resolver desafios, ignorar os obstáculos e assumir a responsabilidade por todo o projeto. Finalmente, requer confiança entre unidades, para que as equipes possam trabalhar em colaboração em direção à mesma meta abrangente, sem medo de que outras unidades passem pelo dinheiro. As equipes devem fornecer total visibilidade do status do projeto, incluindo marcos, tamanho do backlog, cronograma de entrega e principais obstáculos. O desenvolvimento de uma série de metas compartilhadas também é útil, para garantir que todos estejam se movendo na mesma direção. O registro de rastreamento de implantação com sucesso de projetos complexos e multifuncionais que tocam em vários sistemas e plataformas. Fase.

Generate trust by maximizing transparency. Because serious mistakes on regulatory projects can have ruinous consequences for individual employees, board members, and organizations as a whole, building a culture of trust and transparency is extremely important. This process starts with board members, who must understand why and how agile is used in regulatory projects and fully support the approach. It also requires trust among employees, who may be accustomed to managing a discrete portion of a project and now must work collaboratively to resolve challenges, bypass roadblocks, and take responsibility for the entire project. Finally, it requires trust across units, so teams can work collaboratively toward the same overarching goal without fear that other units will pass the buck. Teams must provide full visibility into project status, including milestones, backlog size, delivery schedule, and key obstacles. Developing a series of shared goals is also helpful, to ensure that everyone is moving in the same direction.

Would Your Regulatory Projects Benefit from Agile Methods?

Numerous conditions may suggest that a bank’s regulatory projects would benefit from agile methods:

• The regulatory requirements are not viewed as stable and will likely change over time.
• The bank has a limited track record of successfully deploying complex, cross-functional projects that touch multiple systems and platforms.
• Some key stakeholders doubt that the organization can successfully deliver projects with the current delivery model or fear that regulatory projects will have a negative impact on other important projects in the pipeline.
• Although the bank has developed an extensive and detailed list of functional and nonfunctional requirements, most are stuck in the concept development phase.
• A organização nunca forneceu com sucesso um requisito funcional de ponta a ponta relacionado a demandas regulatórias. Sirva como uma lista de verificação - mas, em vez disso, apresentar uma variedade de condições em que o Agile é ideal para ajudar as organizações a superar obstáculos e alcançar o sucesso. Caso contrário, eles podem desperdiçar uma enorme quantidade de recursos. As organizações com um histórico positivo de fornecer projetos complexos por meio de métodos tradicionais de conformidade regulatória podem não precisar do Agile. Mas para a maioria dos bancos que estão lutando para implementar projetos regulatórios no prazo e sob o orçamento, o Agile oferece benefícios extraordinários. Norbert Gittfried
• The underlying IT architecture is modular enough to allow for partially independent releases in certain applications.
• The organization has had at least one successful experience working with agile, and senior leaders are willing to embrace a new model.

This is not intended to serve as a checklist—but rather to present a variety of conditions where agile is ideally suited to help organizations surmount obstacles and achieve success.

---

Regulatory requirements inevitably evolve, and banks need the flexibility to respond effectively; otherwise, they may waste an enormous amount of resources. Organizations with a positive track record of delivering complex projects via traditional regulatory compliance methods may not need agile. But for the majority of banks that are struggling to implement regulatory projects on time and under budget, agile offers extraordinary benefits.