Let us now examine Governance in action. We need a test case. Suppose there is a straightforward piece of eminently useful coding which it is blindingly obvious ought to be done. For example, your profit-and-loss module is so flaky that two of your engineers have to spend all their time spannering it simply to keep it going. They’re fixing bugs, they’re rebuilding data corrupted as a consequence of those bugs, and they’re explaining and justifying to users the bizarre and counter-intuitive figures the damn thing comes up with on the odd occasion it does work right. One of the engineers realises that if he could take two months out from continuous fire-fighting he could tidy it up and improve performance, reliability and usability no end. Then he and his pal would be freed up to move on to some other more useful activity.
In a climate of sanity and common sense, this proposal could be brought to a manager (a single manager – just one), agreed and scheduled within the week. Maybe it could even kick off straightaway. There would be some paperwork and a bit of organisation required for testing, and a little more for release. But sanity and common sense have little to do with Governance. Let’s see how it might fly in practice, in a well-governed business.
- First, we need a Development Proposal. But your procedures stipulate a Customer / Supplier relationship. You and your hapless engineers are IT, and as you actually produce useful stuff are classed as Suppliers. You are therefore a Cost Centre, formally speaking a liability and drain upon the Business, and are not allowed to register a Development Proposal. You must find someone wearing a Customer hat who can be persuaded to front the wretched thing.
- Then their boss has to agree to them fronting it too. Development Proposals must have full managerial authorisation.
- And their boss’s boss as well. Proposals for significant development (defined as more than 10 days) need departmental approval.
- So: you need to find a management chain of three people who are all prepared to put their name against this job. This they must do in the sure and certain knowledge of the ceaseless round of meetings, documentation and tedious bureaucracy this will demand.
- This will entail explaining, schmoozing, cajoling and return-favour-exacting from all your contacts across the company. Which will take many days.
- To pull this off you will need to recruit your department head and probably his boss too. Just reaching the point when one can start writing a proposal requires a high degree of stamina.
- Now that you’ve lined up your stooges – I’m sorry, I mean to say you have an appropriate stakeholder, sponsor and business contact in place – you can finally write the bleeding proposal.
- But first you must establish what the required format is. A series of queries to the Project Office will return a variety of responses. In the end, you will be presented with the last proposal submitted and told to copy it. This format will run to at least 12 sections. Only three of these allow you to enter any details relevant to fixing the blessed profit-and-loss module.
- Your first draft will be rejected instantly as it is the wrong format; it changed last month. You will not hear about the rejection immediately, and it will take two further days to get hold of a sample of the right format.
- The second draft will return after a week, heavily annotated. The annotations will be simultaneously banal, excruciating and pointless, but you will dutifully act on all of them: modifying spellings to match American English; recasting sentences into the passive voice; cutting and pasting standard boilerplate texts; referencing a series of weighty governance documents – Terms of Reference, Rules of Engagement, Operational Standards etc.
- The third draft will be provisionally accepted by the Project Office, but rejected when you present it in person to the Technology Work Initiation Team some days later. Their comments will rollback most of the previous round of changes and additionally require you to add definition of several basic concepts which you would think anyone who claimed to be an I.T. Professional would understand.
- The fourth draft will finally be accepted, but only after a fortnight because of the Bank Holiday.
- This is no cause for celebration. All you have earned so far is the right to propose some development. Now you need outline budget approval from the Funding & Allocation of Resources Team
- Once you have budget, you will need a design. Putting to one side the hoops to be jumped though in order to produce that design, once it exists it will have to be approved by the Architectural Review Secretariat – Enterprise via the Production-Ready Approved Technology process.
- Then you have to do detailed planning, and go back to the Funding & Allocation of Resources Team for formal budget approval
- … and on …
- … and on …
- … and on, on to bullet point 97 and beyond.
The governance is so tight it’s unbearable even to write it out, never mind hack your way through. You would need oil-tankers filled with bloody-mindedness to get to the end. One could cross Antarctica naked on foot with such reserves of endurance; you would have to be the corporate equivalent of Ranulph Fiennes.
Aside from the spirit-crushing despair produced by an endless chain of petitions for permission to put one foot in front of the other, this degree of oversight hoovers up time and money. Each checkpoint requires the production of artefacts. Each artefact needs review and approval. Each reviewer of each artefact will need to be pestered to remind them to approve it. Usually more than once. It might all be pointless but it’s still work and someone, ultimately, has to pay for it.
I once was employed by a particular well-governed organisation and much time was spent in the canteen reflecting on the latest whimsical adjustments to our already North Korean levels of control and freedom. One lunchtime we sketched out how long a project would take from conception to closure, if that project’s sole deliverable was a “Hello World” program. Your choice of compiler. Our first estimate was 26 weeks. This turned out to be too optimistic, as first estimates are wont to be. We had forgotten that some of the checkpoint conference calls happened only once a fortnight, and had assumed that all approvals would come back within a day or two. Further analysis, this time in the saloon bar of The Clarendon, came to the more realistic figure of 39 weeks. We then realised that we had only considered the rules and regulations on the Technology / Supplier side of the fence. Consulting with esteemed co-colleagues on the Customer side of the business, it turned out there was another 15 or so weeks of process before embryonic projects got anywhere near us. So, 54 weeks all told, and only that quick if nobody actively tried to block progress along the way. Costing this whole farrago was more approximate, but taking all the people involved into account it seemed there would be little change from £30,000.
We were genuinely shocked at first, and compared our joke-guesstimate against a few projects in flight. It held up. One or two things had moved forward a bit quicker, but only through devious and underhand hustling – dodging round the architects, starting without budget actually being signed off, “borrowing” authorisation from vaguely related activities, that kind of thing. Anyone who’d followed the rules had gone about the same speed, or maybe a little slower.
So. For a touch more than the average yearly wage in 2010-11, over a touch more than the average year, you get this:
That’s better than one man year of value, under max-strength governance. Money well spent. Well, do you want order or do you want anarchy ?