Often in large organisations we have to deal with groups with names like "legal" or "compliance" or to use an example from my days in the healthcare software industry "patient safety". To a project manager, the function of these groups seems to be to throw up obstacles and prevent getting things done. These groups tend to appear out of the woodwork near the end of a project, inspect everything that has been produced, identify a bunch of problems and then block release until they are all fixed. The problem of course is that at the end of a project, everything has already been built so changing things is hard and expensive. There is also a very good chance that the money is starting to run out so these changes would push the project well over budget. Throw in a rapidly approaching release date and a team already stressed with defects and last minute changes, and it's no wonder project managers view these groups with dread.

Of course, these teams are not just a bureaucratic hurdle to be jumped. They do an important job. The organisation could be in serious trouble if they release anything that is illegal or is not in line with whatever regulations they are under. Groups like legal and compliance have the skills and knowledge to make sure that doesn't happen. In the healthcare company I worked for, patient safety was responsible for exactly that - the safety of the patients whose treatment was administered through the software we wrote. They were trained medical professionals, with years of hospital experience, who assessed what we produced and made sure that in the stressful, overworked environment of a typical hospital, that the software could be used without the risk of accidentally administering the wrong drug or the wrong dose or operating on the wrong leg (or even wrong patient) or anything like that. That's a pretty important thing to do. We knew how valuable it was. We still hated dealing with them though. Product managers would jump through hoops to get their product classified "non-therapeutic" so they could avoid a safety review. The downside of course is that there was no safety review. If only there was a way that we could get the value that these groups provide without all the downsides.

The problem here is not with the function these groups provide. What they do is important. If the wording on the product page breaks the law somehow, that can leave the organisation facing heavy fines or other penalties. If the software isn't safe to use in a clinical setting, it can leave the directors of the company open to charges of manslaughter (and it isn't a great outcome for the patient either). The problem is in how these groups are set up.

Groups like this are typically set up under an inspect and block model. They inspect the finished product and block its release until any corrections needed have been made. The usual reason given for following this model is that it's more efficient. These groups are generally fairly small (they are made up of rare and therefore expensive specialists), so they need to minimise the amount of time they spend with each individual project. Doing a singe inspection at the end allows them to use their time in the most efficient manner.

Except that it doesn't. Not really. What it leads to is a work flow filled with peaks and troughs. Long periods with nothing much on then, when enterprise release time comes along and everything is trying to get out the door at once, a massive workload that they really can't get through effectively. Batching work like this is actually a very inefficient way to organise work. It's a case of local optimisation - minimising the amount of time spent with each individual project but leading overall to an inefficient workflow. Is there a way they could manage their work to even out the peaks and troughs but still do their very important job? Of course there is. But it needs them to reassess what their role is.

As I said above, most of these groups see their role as a check and block function - check what has been built and block it from moving forward until it is right. What we need instead is a consult and enable model. In this model, the role of these groups is not to stop things being released but to work with the team to enable products to go out. Stop thinking "how can we stop bad things going out?" and start thinking "how can we enable good things to go out?". Work with the team right through the project to make sure that the right thing gets built in the right way. Make sure the text meets all legal requirements by working with the designers right at the beginning. Make sure the product is safe to use by consulting with the team on proposed designs right from the beginning.

When we shifted to this model in healthcare, not only was it better for our patient safety folks, but it was a much better outcome for the patients. The safety team had a much steadier workload. They spent more time with each product but it was a consistent amount of work rather than being full of peaks and troughs. By engaging with the teams, they were also able to transfer a lot of knowledge to the teams so the team could start to design in a way that was mindful of patient safety. Once the team saw it as an important function and not just an impediment, they were much more willing to make the changes that were needed. The safety folks also learned a lot from the teams. Some of the changes they wanted weren't possible to implement so working with the team allowed them to learn what was and wasn't possible.

What about the patients? Well, by finding safety issues early on the project the team was able to fix them before release. We saw safety defects released to production reduce by over 50% in the first year alone and the number of safety waivers issued (yes, that is as terrible as it sounds - it allows you to release software with safety defects into production as long as the defects are documented) dropped massively.

I have since used this approach with security teams, legal compliance teams, accessibility assessment teams and a host of others, all with great results.

This shouldn't be a surprise. This is exactly what we have been trying to do with developers and testers for years. Stop treating testing as a check and block activity. Work together, find the issues early when they can still be fixed. This is just expanding it beyond the core development team into the wider system.

If you can switch these groups from inspect and block to consult and enable, they start to become valued partners and not unwelcome impediments. It's a better outcome for the people in those groups, it's a better outcome for the realisation and most importantly, it's a better outcome for the organisation's customers.