Just process in consultant's clothing
permalinkNovember 26, 2007
I first noticed the word governance being sprinkled liberally into IT conversations sometime in the late nineties. It was (and still is) used as foundational prop to suggest that, if you have it, all will be well. The word appeared first, as far as I can remember, in Finance and Investment Banking IT - not surprising as financial governance is all about the appropriate exercise of authority and control. The word itself means a method or system of management and so I guess it's no surprise that you see it, more often than not, in slide packs delivered by consultants.
I’ve always thought of governance and process as being inextricable - process being merely a repeatable and structured way to achieve something, and governance being those elements of the process that give some confidence what is proposed meets some pre-agreed or desirable standards.
I think a process without governance isn’t actually much of a process at all. I mean, why bother with a process if what comes out the other end isn’t what you want, or has cost too much, or whatever? Similarly, governance without process is just a regulatory framework blissfully ignored by the process-free masses who will just build what they like until the company collapses.
And yet there we were, with our nineties haircuts, discussing governance as a stand alone concept. Not just as if it were an important idea (clearly it is) but as if we'd never had it before (we had).
More recently there's been the rise of Architecture Governance and Service Governance. Has life become so easy that we need to make it more complicated for ourselves? I must say I find it tiresome in the extreme to listen to all this twaddle. What was wrong with just having a process, as lightweight as it's possible to get away with yet still meet various quality, institutionalisation and repeatability goals?
Let's say I want to create a database for some kind of promotional activity. The process might tell that I must first make a business case to show that the financial return from the use of that database is higher than the cost of building and maintaining it. I can't even create a Project Brief to start formal proceedings until I can show I have a money-making concept. This is a good, if frustrating, obstacle because it reduces the risk of projects getting kicked off that won't make any money. Oh but look, that's also governance, because we've subtly steered what's proposed (the database) towards what's desirable (money making projects).
Process and governance are the same thing.
All each are trying to achieve is a measurement of something proposed, against something desired. You could see it as all governance, with process being itemised steps to enforce the measurement, or all process with governance being the checks along the way. The result is the same.
A good way to describe the governance/process objective is that it should give the business four chances to prevent something happening that would be undesirable (i.e. because it wouldn't make money or perhaps wouldn't be in line with business strategy, which as I have said before is never fixed). In practice there are lots more opportunities to shut down a project because it can be done on a whim but, megalomania aside, it would normally be because one of the following four no longer hold true.
The four pillars are:
Business Approval
Our proposed database needs quite a bit of work before it looks like a project. To begin with we need to check it's even feasible. Is this database going to hold master copies of customer data? Add new data entities to the IT landscape? Require stringent security controls? Need specialist skills? Needs skills already in use? Overlap with another proposal? To answer these, and the host of other questions, requires a lot of work. What should result is a well formed idea and a bunch of 'commitment dependencies' that must be met for progress to be made. Flexible and engaging technology input is critical here to make sure those commitment dependencies are realistic.
Investment Commitment
Now we know what we need, someone needs to provide it. And we're only talking about money here, not people.
Companies do this through two mechanisms, either periodically at a regular budget committee meeting, or when planning the following year's activities. The two are not exclusive of course - I think most businesses make a big plan for the year ahead of time then promptly undermine it with a steady stream of new initiatives all with a 'top priority' ranking. But the point is that there's only so much capital budget available for new ideas. If there's a business plan then proposals that most closely support it, are likely to be the ones that get this commitment.
Delivery Commitment
Now we have budget, we have to confirm that spending it doesn't equate to wasting it. Our flexible and engaging technology involvement during approval should have been used to inform this step - i.e. there shouldn't be many surprises in form of investable proposals that aren't deliverable.
For what it's worth, I think the IT department's focus predominantly on this point forward is one of the major causes of the business/IT communication gap. If a Product Manager has gone to all the trouble of building a business case, influenced and persuaded their political masters, and stood sweaty-palmed in front of the CFO to ask for the money, no friends will be made when IT starts whining about lack of resource/engagement/skills/etc.
But let's assume we've done our job - we've not got overly hung up on requirements, we've added plenty of value to the proposal, updated our enterprise models in preparation for more promotional activity and when we saw this proposal we could happily make a commitment to delver it. The Promotional Database Project is officially doable.
Implementation
Now we have to do it. From business analysis (detailed requirements only remember, we have a reasonable grasp of this from our consultancy work to assist with the business case) to architects, to developers, to testers, projects managers, sys admins, dbas, etc we have to make this thing work without breaching the tenets of the previous checks of business, investment and delivery - if the business changes, the costs go up or our ability to deliver is affected too much we have to either re-plan or stop.
Once complete, our business gate is to go-live or not to go-live. I've seen projects put back months at this stage simply because the amount of change going into operations is too great. If too much change goes live ahead of our promotional database we may even have to re-engineer it to fit the as-is architecture.
And that's it. It's not process or governance. It's both. At appropriate stages we checked that our proposal was good for the business, then that we could afford it, then that we could do it. As these questions were answered we continually asked them to make sure the goal posts hadn't moved without us knowing.
So what about Architecture and Service Governance? Well for me they're buried in the description above. What I mean by that is they shouldn't be overtly visible to the business. The process by which a proposal is defined, sized, costed, assigned big-ticket technology approaches, and the process to deliver doable projects might generate services definitions and contracts and give rise to non-functional requirements but to the business it should just be part of doing business.
I think sometimes IT gets too 'IT' about these things and pretends there needs to be all these layers of bureaucracy to make things seem more sophisticated and safe. But I've not met one business person who gives a monkey's about SOA. They would say that it's simply IT's job to deliver solutions that meet those four pillars and to do so with as much longevity built in as their unpredictable business world allows. And they're right.