Software/Systems Engineering Projects: How to work with the independent RegulatorFollow article
This is the third of my blogs on working in a regulated industry as a software/systems engineering professional. The other two parts are available here to read: Preparing for Regulatory Approval and The Impact of having regulatory requirements on a Software project.
A lot of engineers work in industries where their products require external regulatory approval, eg Pharmaceutical, Defence, Aviation, Medicinal aids etc. External Regulatory approval may also be related to such topics as Cyber Security.
As previously, I have used anonymised examples from defence and aviation as those are the industries that I have experience in. My examples will also be based around working with Independent Safety Regulators reviewing the product safety (not Health and Safety which I have no experience or competence in!). This article is very much a personal opinion of how to work on a project where the end result will need regulatory approval. I have also been extremely fortunate in working with constructive and helpful Regulators.
The key thing is that you need to start engaging with the Regulator at the start of the project and maintain that throughout the project. It is my opinion that building a good relationship with the Regulator can pay dividends and ease the approval mechanism. (Note, I was very interested to see some press reports about how the University of Oxford/ AstraZeneca COVID vaccine trials and the regulatory approval was obtained. There, it was reported, that they have been working with the regulator and sending them information during the development and the vaccine trails rather than waiting until the end.)
On one project, we had a formal meeting comprising both main suppliers, the end customer and the Independent Safety Regulator. When I was introduced to the Regulator, who I was sitting next to, I stated how pleased I was to meet him, as I wanted to have a discussion regarding his role and the impact of his role on the work that I was tasked with the undertaking. His response was shock and a comment that very few people wanted to meet him and usually kept him at arm's length! During the subsequent discussion, we were able to identify what the key issues were going to be and where he was going to focus his attention which made subsequent work more straightforward.
On a different project, I took over from a Safety Manager where the project was responsible for replacing multiple instances of some obsolete infrastructure equipment. I took over when all the safety documentation for the first site had been produced but we were still waiting to commission it into service. Before the first site could be introduced into service, the Regulator needed to review all the (considerable) documentation and visit the site to review the installation. As the other sites were going to be installing the same equipment I was keen to identify whether there was a way to simplify the safety documentation for these subsequent sites to ease the workload for me and the review process for all the impacted parties (5 in total). As I said to the Project Manager when suggesting this, it would save me copying and pasting the documentation (with the associated risk of human error) and that “I didn’t want to write multiple versions of this and I’m sure the others didn’t want to read it either!”. After discussing and agreeing on the proposed approach and therefore the documentation amendments needed internally, I arranged a meeting with the Regulator and spent a couple of hours going through the changes and explaining my rationale. With the explanations that I had already provided to my internal stakeholders, I could confidently talk it through with them and answer all their questions. After this meeting, they agreed with the proposed changes which I could then finalise and implement. As a result, what was supposed to be a full-time role on that project meant that I could manage multiple projects thus saving the company and each project a significant amount of money and time.
In all the companies that I have worked in where there is an independent safety group, there has always been a direct line of report up to senior management bypassing any project management. This provides a mechanism for raising safety concerns independent of the project, if necessary. With that route and also the option for raising concerns directly with the regulator, sometimes having a regulator can be of great benefit. I have never had to approach the regulator in this way, but I know of cases where it was considered.
One final example: there was one occasion where I needed help from the head of security on a project. I was working for a supplier and was faced with having to deal with a security concern which while it was primarily my concern could have had an impact on the security of the whole project. Because the security manager was approachable and helpful, I was able to have an open and honest conversation about the problem that I was facing, and we were then able to work together to identify a solution that meets my requirements while maintaining the security of the project.