Governance is about ensuring a good outcome
When systems are developed, they have to follow a set of rules. The way it works must be constrained. These rules will allow for systems to be supported, maintained, and perform at its maximum. Without rules or guiderails, designers would be free to use all sorts of exotic software and hardware, which would be impossible to support and even more impossible to use.
Provantage was asked by a client to investigate the way their systems development was governed. When we looked at the process, we were astonished at its complexity. It was a good list of constraints, just too many of them, and many were not backed up with good evidence to justify many of the constraints.
Talk to the developers
We embarked on a series of discussions, looking at what are their main concerns with the governance process. The main complaint was the sheer complexity. Over five hundred questions had to be answered. It was time consuming and tedious.
More worrying was all this data was collected and nothing was done with it. The whole process proved nothing, did nothing to advance the development, nor did it do anything to help any following development.
The premise was a good one. It would reduce the number of other stakeholders who need to ensure developments stay within their guidelines, but we had to simplify the process and make the results more meaningful. We also had to work out why they were required to complete these lengthy documents too.
After some quick analysis of the reports, we discovered interesting results such as a number of the constraints never used, some were only partly agreed, and some were always agreed with. When a constraint needed to be broken, the owner never put up any arguments, so it threw the whole process into disrepute.
Starting a new process
Armed with what the business really wanted out of the process, we embarked on a re-write. The stakeholders who created the constraints were charged with creating policies or guidance to back up their constraints. No longer were we going to accept ‘best practice’ as a reason for the constraint. Having signed off documents to back up each one meant developers could refer to the document to give a wider context.
The list was cut to a still overwhelming three-hundred plus constraints. But now, we had organised them into sections, which when filtered by the development type, would reduce the list to about a hundred.
We also ensured that when a constraint could not be met, the stakeholder would interact with the project to discuss it. If there was constant breaking of a constraint, it could either mean the platform couldn’t satisfy the constraint, meaning the constraint had to be changed, or the project would need to try harder.
Each constraint also had a priority, from advisory to mandatory. This led to a further reduction in the number of constraints down to less than fifty.
As these were collected, we could run stats off them to see how much risk the business was carrying with non-compliance, and target systems which would be fully compliant with a little bit of effort.
The compliance question is going to be further refined by the business, with the introduction of automated processes and front-loading projects with a staged set of compliance checks. This way, investment and resource can be directed to developments supporting core business capabilities which can be made more compliant.