Working at a regulated environment such as a bank, even in software, requires satisfying different areas of compliance. Different organisational structures ensure compliance with different areas of regulation, by mandating the existence of evidence, imposing checkpoints, and auditing projects and teams.

Coming from non-regulated software companies, my first realisation was that almost all “procedures” were in fact processes, which benefited from clear timelines that clarifiy the interactions and responsibilities of all the actors involved.

Some developers perceive these processes as overly bureaucratic and as barriers to real work being done. Therefore, they may explore loopholes and take shortcuts when possible. This is surprising in a regulated environment, where non-compliance may expose the bank to fines from the regulators and may result in swift disciplinary action against employees.

Developers that avoid official processes fail to make the connection between the bureaucratic steps they are required to follow and the hight-level regulations and guidelines they were taught to follow.

To make that connection explicit, I wrote two sections for each compliance area:

• Expected outcomes of that compliance area, as perceived by the bank and the regulators. This specifies the ultimate purpose of the bureaucratic processes.
• Principles that the bank wants to observe while pursuing the outcomes. These principles may prohibit some ways of working, or they may describe desirable ways of working.

The principles justify the existence of the bureaucratic processes as a way to achieve the desired outcomes.

For a certain area of the bank, reports feed auditing by describing how that area caters to a specific area of compliance. These reports now start with the expected outcomes and guidelines, followed by the processes in place. Some reports may also offer proof that the processes were performed successfully.

Announcement bio at TCUK

Joaquim is the Principal Technical Writer at Millennium bcp. Joaquim has documented large and evolving software products that require industrial writing instead of just writing craftsmanship since 1997. Facilitation is an occasional need. Joaquim is a member of IEEE PCS and a leader at ISTC, APCOMTEC, and EuroSIGDOC.

References

Presentation slides

Local copy of the slides for the presentation.