Compliance needs a mindset, not a pamphlet

Regulatory requirements are a major challenge in IT projects. If we are being honest, I am sure we have all found that compliance requirements in projects make life difficult, even though compliance serves to protect project teams themselves in addition to protecting organisations. This is because non-compliance can result in substantial fines, damage to the company’s reputation and even imprisonment.

Although agile project methods are now increasingly spreading out of software development into a wide variety of business areas, compliance departments and compliance projects, which typically involved a high level of technical complexity and a large number of interfaces, especially to IT, are usually neglected in the agile transformation. That is why we ask ourselves the question of whether compliance departments and projects can benefit from agile methods and approaches that involve an iterative and transparent approach.

But first – What does compliance actually mean?

The term ‘compliance’ refers to the act of organisations obeying rules. This means adhering to laws and rules to ensure that no violations of the law occur. This is because violating the law may result in criminal and civil proceedings. However, compliance violations usually also involve serious damage being done to the company’s image, and there are numerous examples of this, including the German government’s face mask scandal, the Siemens bribery scandal and the VW emissions scandal. A functioning compliance system is therefore essential for every company to have. In addition to legal requirements, compliance also includes rules and guidelines voluntarily established by the respective companies. This can be, for example, a specific code of conduct for certain areas, such as environmental protection or communication.

Compliance departments are under pressure

It has become commonplace for companies (depending on their size and the industry they are active in) to establish separate internal compliance units that ensure the organisation adheres to the rules to guarantee compliance. Compliance departments are facing a growing number of challenges – regulatory requirements have become increasingly complex in recent years, they have less and less time to meet reporting deadlines and the volume of data they have to process has increased exponentially. This is just a small sample of the challenges that compliance units have to deal with and will continue to have to deal with. It takes a great deal of bureaucratic effort not to lose track of the situation, to recognise new rules immediately and to ensure that they are implemented and adhered to, which means that compliance departments should be able to react flexibly to unforeseen events. This raises the question of whether processes and projects can be handled more efficiently with the help of agile methods and approaches. This is because, for example, a product is only reviewed in accordance with the current compliance guidelines at the end of the development process, which can result in delays and considerable costs if corrections need to be made.

Agile in compliance: iterative, cross-functional and, above all, with the right mindset

Looking at the Stacey Matrix, which ranks problems and their solutions according to how clear they are, most compliance projects are in the ‘complex’ range (see the figure below). New regulatory requirements are initially unclear, open to interpretation and evolve over time. Most of the time, it is not known what impact the requirements will have on parts of the organisation or the organisation in its entirety when they are introduced. It is also not always clear how the specifications, that is, the solution, are to be implemented, especially in large-scale projects – particularly when they affect company processes and IT systems and fundamentally change them.

A good example of a complex project from the area of compliance is the implementation of the Payment Services Directive 2 (PSD2). PSD2 is a new EU directive that is intended to increase the security of customers, strengthen consumer protection and promote innovation in the banking sector across Europe. Since it was adopted, the directive means banks are now obliged to grant so-called third-party providers access to bank customers’ accounts, among other things. This gives customers the freedom to use their own data in services of their choice. The requirements associated with PSD2 are complex and include many different rules. The impact they would have on banks and their processes was also largely still unknown at the time of the announcement. On top of that, the question of which technologies and solutions could be used to best implement these requirements was completely new territory for the financial industry, which made everything difficult to implement as a pure waterfall project. An iterative approach would have made sense in this case to avoid long planning phases and enable faster learning. For example, the industry could have already started taking the first steps towards redesigning IT landscapes to open up technical interfaces for third-party providers (APIs) and finding solutions to the question of API security in parallel so as to obtain and factor in specific feedback from end users as early as possible.

Various disciplines come together in the implementation of PSD2. It requires cross-functional teams comprised of experts in order to understand and uncover the connections between regulation, technology, processes and strategy. Having a wide range of perspectives and experts means that not only can problems and risks be identified at an early stage, but unleashing the creativity of ‘many’ also allows new business models to emerge. This also creates a common understanding of the directive across compliance boundaries and promotes transparent communication, as team members become aware of misunderstandings and develop a common language.

To enable cross-functional and iterative working, banks and their compliance units need to shed their silo thinking and hierarchical structures and create a framework for agile working – and that starts with the mindset. This is because agility goes beyond Scrum. First of all, agility refers to an inner attitude that deals with changes in a positive way based on the situation, as changes can also mean opportunities. Apple and Google are good examples of this. They took advantage of the introduction of PSD2 and were able to expand their business model as a result, while most banks, on the other hand, waited until the market was settled.

The first steps towards agility

If we turn our attention to the question of whether compliance departments and projects benefit from agile methods and approaches, the answer is yes. Both agility and compliance are required to translate complex issues into tangible, transparent results. To do this, you need to understand that agility is more than agile frameworks. Rather, it is a positive and proactive attitude towards changes such as regulatory changes. The example of PSD2 has shown that laws can not only slow down but also be drivers of innovation. In this context, it is important that regulatory changes are not implemented blindly, but are viewed from different perspectives and possibly rethought.

Unlike IT projects, however, it is difficult to work in a purely agile way in areas of compliance. The Agile Manifesto states that we need to value working software over comprehensive documentation, which means this agile principle cannot be adopted one-to-one in areas of compliance. Depending on the industry, there are relevant regulations that require proper documentation to avoid sanctions.

We recommend starting with the following steps to make your compliance departments and projects agile:

• Start having daily meetings: 15-minute daily meetings help compliance teams in increasing transparency, identifying dependencies and risks at an early stage and clarifying technical issues.
• Hold retrospectives: In line with the ‘inspect and adapt’ principle, compliance departments can conduct regular retrospectives to help uncover inefficient processes and take a critical look at past cooperation. The measures derived from the retrospective help compliance units – such as employees – save themselves having to perform repetitive tasks by automating them or think about established processes in a customer-centric way.
• Form small, cross-functional compliance teams: A compliance department does not always have to consist exclusively of lawyers. The team should be able to understand the needs and challenges of different parts of the company. This not only promotes creativity and innovation, but also enables a customer-centric mindset and prevents misunderstandings by developing a common language. This is especially true for implementing compliance projects. Many companies make the mistake of forming a homogeneous project team that is too large, which in most cases includes people who are not needed on a regular basis, resulting in wasted time and distracting the team’s focus. Instead, a small, dedicated core team of experts can work much more efficiently and only call on people when they are actually needed.
• Introduce a backlog, break down requirements and prioritise them: There has been an increasing number of new legal requirements in recent years. Introducing a backlog has proven an effective means of maintaining an overview, creating transparency and setting priorities. For compliance projects, this means dividing regulatory requirements into clearly defined, manageable blocks that can be implemented independently of each other, prioritising them and presenting them transparently to everyone involved. This way, important parts of the requirements can be fulfilled continuously instead of trying to implement the entire project in one big step.
• Promote and strengthen the agile mindset and agile values: First and foremost, compliance requirements are not a bad thing – they can also mean opportunities for companies. The ability to react quickly and flexibly to changes, in this case to new regulatory requirements, and to view them positively first is what distinguishes agile teams and organisations. The agile values of openness, respect, focus, courage and commitment form the basis for the success of agile work processes. These should first be understood, internalised and practised by compliance departments, otherwise all further measures are doomed to fail. Although it sounds banal to practice agile values, the challenge, however, lies in the fundamental cultural change that senior management need to want and need to put into practice themselves. Agile methods can only be implemented in a meaningful way when agile values and the practiced corporate culture are compatible with one another.

Would you like to learn more about exciting topics from the world of adesso? Then check out our latest blog posts.