Engaging Regulators

On large software projects, one group of stakeholders that I find are routinely missed are regulators. This group can be regarded as a proxy for policy-makers; regional, national or supranational. Examples of regulators would be tax, customs inspectors; or standards’ auditors (such as the ISO) covering safety, quality and environmental certification.

Missing this stakeholder group is potentially an expensive mistake; for example, the new software may fail to replace old functionality on which the organisation relied to retain standards’ accreditation, or result in missing reports that tax or customs regulators require. Conversely, it may be equally expensive to treat regulators as first-class stakeholders which may result in un-necessary regulatory features leading to delays of those with more direct business value to the organisation.

In addition, the organisation may have its own internal authority who interprets regulatory rules into corporate policy. Such authorities will have varying titles, such as Quality Assurance Manager or Environmental Compliance Officer. Occasionally, you may find that this internal authority may try to influence the priority of the regulatory feature-set disproportionately , perhaps even to the point of trying to influence the sponsor directly.

So: what’s the best way to proceed? Some regulatory functionality needs to be implemented but how do you know that the internal authority isn’t over-emphasising its importance?

One way to clarify matters is to engage the regulator directly – perhaps the best way to start is to ask your internal authority for a three-way introductory meeting. Briefly explain the business aims, and the scope of the project, then ask for an opinion as to what the regulatory implications are. Like most people, regulators are pleased to offer advice if asked. You may well be pleasantly surprised: a compliant interim solution may be relatively inexpensive in terms of effort. This has two advantages: the new system can compliant from day-one and it allows more time for development of business-critical features. Subsequently, a more integrated compliance solution could be scheduled for a later delivery.