When the team isn't following the standards

Over the years, I've both come across and chatted with others about joining a delivery team or even a programme to find that it isn't following expected standards.

This could be not working to or even not being aware of:

• accessibility regulations - be it WCAG 2.2 or in UK public sector websites The Public Sector Bodies Accessibility Regulations 2018)
• industry standards - in the UK government for digital services this might be the Service Standard or Technology Code of Practice
• expected delivery practices or roles - in the UK government for digital services this would mean using agile ways of working and having roles as specified in the Government Digital and Data capability framework (formerly the Digital Data and Technology or DDaT capability framework)

How does a team end up working off-standard?

Over the years I've seen a few reasons that the team may have got to the this way, many of which may be related:

• the money for the project has come from a non-standard funding pot. Generally projects should go through a standard spend control process which then makes sure that all the checks on standards are baked into the process. However, when money comes from a slightly different than usual channel—for example, marketing or operations, especially if a smaller amount—then it may not quite go through the standard process.
• the people working on the project are isolated from communities of practice or assurance processes and so are either unaware of the standards or mistakenly think that it doesn't apply to them. This may be because a team is mostly outsourced, or in an unusual pocket of an organisation, and the service has somehow gone under the radar (for example it has been in public beta for a long time so changes can just go live without external oversight). There are particular examples where standards change so that people are using outdated and wrong information, for example that the Service Standard and the Public Sector Accessibility Regulations 2018 don't apply to services built for internal use only (both of them do).
• there is precedent of best practice being overruled. This could be because there is a 'burning platform' or some other form or 'commitment' that meant concerns were overruled, and then started expectations that if one project could do it then so could others. Thankfully I haven't seen this that often, but when it does happen it can set unhelpful expectations that if one service got to ignore the standards then others can too

So, you've arrived in a team that isn't following the standards…

The first thing I encourage people to do is assume lack of understanding or awareness of standards rather than deliberately ignoring them (though, as mentioned with precedence, it does happen). Often people just don't know what they don't know.

After that there are three general themes of work: understanding, finding champions for the standards not being followed, and encouraging transparency.

• understanding means trying to do some due diligence as to why things are the way they are. Talk to people about what has happened, how the project got procured. For those working to the Service Standard, it's worth tracking down previous service assessment reports (they may even be really old ones or even not published if they were not met - this might mean finding emailed versions) to unpick what has happened before and even make notes of anything controversial. I did hear a great story of someone doing their due diligence with previous reports and then correcting someone incorrectly saying a technology had met the standard with a quote showing that it had not.
• finding champions for the standards not being followed means that you have experts that can help align the team as to what they should be doing. Ideally this should be within the same organisation and in fact as close to the team as possible
• encouraging transparency means finding ways to get other people to see what has happened with the team. Ideally there are show and tells that people can be invited to, if not, then it may mean looking for opportunities for crits or to take work to ad-hoc feedback sessions. This may also mean that the champions you have found need to create events to allow for this type of regular (if not continuous) assurance.

Making sure that future teams start from standards

If there's one team like this, there may be others. So it can be worth talking to line managers or practice leads about:

• procurement and spend control processes - is there something that needs a review?
• principles for working in the open (and ideally continuous assurance) - show and tells, crits, show the thing, even if just at your profession level
• onboarding processes - do outsourced teams need to be baselined when they join a team, even if just to double check that everything that should have been sorted during procurement and spend control actually has happened? To this end, I think the work like DWP's accessibility manual and the Deparment for Education's Service Standard guidance are great examples of trying to set expectations for all.

More than anything, these sorts of challenges are systemic and require curiosity and patience to unpick and eventually change.