IT governance and/vs. Innovation – A digression

Governance vs. creativity… Doesn’t it sound a bit like the eternal fight between good and evil?

I suspect that this entry will simply be an introduction – but God knows! This field is extremely vast; I will simply jot down here some unorganized notes, hoping that I will be able to work on the different items separately.

This post was triggered by a discussion I just recently came across (started in a LinkedIn group), about this very old question, albeit somewhat updated & refurbished for the sake of times & subject. Shortly put, it reads: “Does IT governance stifle innovation?”

I have to acknowledge that, initially, my reaction (somewhat driven by the course of the debate at that moment, I guess) was probably a bit too straightforward, along the lines “That’s a pure matter of balancing competing needs and the problem is restricted to the right way to do it – mixing in it the right factors, to maximize value”; “Respect and follow the process till you have a new one – there are mechanisms to propose, assess, approve and carry out changes: use them!”…

I realized that most contributors had in mind the opposition (often ‘contradiction’, in terms of TRIZ) between control and innovation, i. e., between the need to ensure predictable results and the drive to improve things, between the drive to avoid the repetition of past mistakes and the push to explore new possibilities, etc.

Then I gave it a second thought, and found that the question had probably more potential to trigger reflection than I had initially considered. As I see it now (and ‘now’ means ‘as I write this’), there are several more questions in the mix, and I do not think that there is such a thing like a ‘right answer’. We could link this, for instance, with a number of considerations, e. g.:

• The ‘not always fully synergistic’ needs of organization and individuals working in them
• The effects of external regulations on the ability of an organization to improve itself, to boost performance, and do things creatively
• The impact of external ‘authoritative opinions’ (e. g., external industry analysts & experts, media and others) on the organization’s ability to decide. You can include here the ‘frozen’ or ‘consensus’ opinion represented by de facto standards and IT management frameworks such as ITIL, COBIT, CMMx, TickIT, ISO27001 and many others)
• Is the environment, the ‘ambience’ more important to drive innovation, or is it the corporate processes, the tools, the resources (people, money, time)…?
• There is innovation at all levels, from creating new businesses to deploying tools and changing internal procedures. You could have actions and effects at all management levels.
• Measurable improvements and intangible improvements, It is probable that the biggest boosts come from not easily quantified/quantifiable proposals (there you need vision).
• The potential value of driving entrepreneurship and stewardship among employees WITHIN the organization (and the difficulties of doing it)
• …

In this post I will concentrate on what seemed to be the focus of the debate I mentioned above, namely, the specific point of IT daily operations (maybe there will be other entries on the other aspects… and maybe not!), and how the drive to enforce controls and follow the change control processes may interact with the push (and the need) to change things, improve applications & processes, adopt new tools, empower the users, etc.

Before proceeding to the point, however, let me make a short digression (I tend to digress quite a bit, in case you still did not notice it) on the issue of regulations.

Note that, although there are very many definitions of IT governance (here you have the one from ITGI), the more or less explicit consensus is that its aim is to make sure that there is the right accountability for decision-making around the ‘right use of IT’ in the best interest of all stakeholders. Well, this is a certainly potential catch-all term, isn’t it? Investors, business users, government agencies, employees, clients, customers… and the overall society at large are all potentially considered as such, which opens a very vast field for ‘interests that should be protected’ (read: an excuse to introduce regulation which, in turn, ends up requiring even more governance rules) [1].

Fortunately, in practice the focus is on ensuring that IT supports the efforts of the corporation to observe all regulations that affect it. Depending on the industry (and the moment), legislation affecting shareholder rights, environmental regulation, personal data protection, price-fixing, etc. may be more or less central.

IT governance, as commonly understood nowadays, can be considered a derivative, extension or implication of corporate governance: shortly put, when you consider the obligations implied by corporate governance (e. g., Basel II, Sarbanes-Oxley), you realize that they have to cascade down through the information systems and the people who run them – simply because current business operations cannot be understood without them. Therefore, the key forces compelling us to act and do it one way or the other are:

• Public regulations of all kinds regarding industry, customer rights, environment protection, personal data protection…
• The stockholders (owners) themselves

Corporate governance and, as a result of it, IT governance, can include also items not (yet) regulated, but that respond to trends in public opinion. Quite often, not heeding what the public says can be very harmful, especially for big corporations and governmental bodies (e. g., everything related to child labor: if you are a multinational manufacturing company with factories overseas, you better make sure that no kids work there – even if you outsourced the actual fabrication). If you think this raises a question as to what is real leadership, and what simply holding an executive position, I’m with you there.

It may be worth discussing to what extent government bodies should regulate operations of private companies, how to assess (from a technical point of view) such regulations and related stuff, but I will not discuss it here (not this time, at least). Besides, this is an almost endless discussion – do not rule out, however, that some comments be made at some time. For the moment, you can refer to any of a myriad of specialized think-tanks, such as @CatoInstitute, @Heritage, @FP_Magazine, @amprog, @thefabians, @BrookingsFP, etc.

Finally, I do believe that, from the purely internal point of view of the companies affected, there is an upside to regulation: it does certainly force you to exert your imagination, and many areas in the organization will be challenged to reinvent themselves, tweak their processes, exploit or create new technologies, diversify… in order to overcome the impact of regulation (all regulations are per se detrimental to the performance of organizations: companies simply keep evolving and finding ways to mitigate the effect of them [2])

It is probably worth thinking a bit about the question of: “Can my organization generate some value from IT governance derived duties, and not simply comply”? For the moment, however, I will not touch this here.

End of (explicit) digression!

On the other hand, leaving aside IT governance, as depicted above, we have IT management frameworks, as described in various models (such as the ones mentioned above). These focus on risk management, predictability of costs and schedule, quality assurance, etc. In general, it is more about the ‘technical stuff’, the day-to-day work of your data center folks, project managers, developers, testers, configuration management teams, database administrators, etc. All of these, along with systems users, are expected [3] to respect a good number of well-defined processes such as (as per ITIL nomenclature) event management, incident & problem management, request fulfillment, etc., and adhere to good (often referred as ‘best’) practices.

Now, in the normal course of things your people will have many suggestions for improvements, and good ideas in order to improve how things are done – and, for the most part, they will be measurable [4]: they could reduce time to market, cut down errors and time waste, improve customer service, etc.

They are important for them for several reasons (in no particular order, mind you!):

1. Simple wish to do things better
2. Self-interest: I want to avoid rework, repetitive, boring tasks, unexpected calls at night, etc.
3. Wish to create something new, and see the effects of it
4. Recognition (and visibility)
5. Once you ‘see the future’ that could come with an improvement, it is simply impossible to ignore it
6. Drive to have fun at work
7. …

For most people it is easy to sympathize with this inner drive for improving things.

Now, which difficulties do we typically encounter to foster this kind of internal, self-ignited innovation? I see several ‘sources of frustration’ in employees proposing improvements in operations where they are somehow involved:

1. The administrative, bureaucratic procedures to record, prioritize and approve the proposals
2. The ‘high mortality’ of initiatives. In short, ‘nothing gets ever done, so why care?’
3. The lack of feedback and explanations for NOT implementing (even something backed by a favorable cost/benefit analysis)
4. The lack of recognition for coming up with good initiatives

On the other hand, if you are responsible for ensuring that operations run smoothly, you could understandably come up with a number of remarks:

1. ‘One should not fix something that works’ («If it ain’t broke, don’t fix it’)
2. Proposals have to be validated, right? Many do not have a clear, well-articulated benefit attached to them, others are costly to implement, or depend from several, difficult to coordinate areas
3. “We do not have the resources to implement this” (one alternative reading is: ‘we have our hands full with ordinary work – and so should you!’) [5]
4. “We cannot devote so much time to analyze proposals of changes” (NB: this tends to create an initial filter based on: ‘who is proposing this?’ Gaining credibility carries you a long way here; see point (7) below)
5. ‘Improving the way we do our work is part of your job’ (though it is now widely accepted that incentives are needed even for doing correctly your daily work. Incentives at large are a huge theme.)

This simply reflects the fact that there has always been, and will always be, some sort of opposition between two competing needs: control and innovation.

Control, in itself, tends to rely on predefined processes & operations and well-known responsibilities, in order to guarantee an expected result and prevent unexpected (because undesired) things from happening. Its ‘responsibility’ is to ensure that the organization does not break something that is working. You could metaphorically say that the reason why control opposes to innovation is the same reason why you are discouraged to drive creatively when commuting between office and home.

… And the experience tells you that you are  usually in some sort of balance: if you enforce controls, procedures, approval mechanisms, etc. in an overly strict way, chances are that your ability to innovate and contribute to create value for your business from your IT function will be, say, ‘limited’  (and the other way round you just dive into chaos).

So, this is a typical scenario you may have in mind when talking about the subject I picked on the forum:

Your people, the ones who have the technical knowledge, and the hands-on experience with your detailed procedures, who are familiar with their hiccups, who constantly talk with users, etc., will be ‘discouraged in advance‘ to come up with any ideas.

That is quite logical: if you require tons of documentation, going through numerous approvals and quality controls that demand (what the individual considers to be) an unreasonable effort (i. e., the ‘personal cost – benefit analysis’ does not bode well), then they will simply skip it.

Another digression, for those loving to have an upside and a downside:

The good thing: you can be sure that, should any initiative go through that filter, then you can be pretty confident that either the idea is so important as to be worth the effort OR you have in your organization some folks who are, definitively hard to discourage. Both are good news, aren’t they?

The bad thing: your folks will get frustrated, will eventually lose any inspiration and drive to do new things, will get bored, will not like their work, will lose enthusiasm and productivity or quit («whichever is worse», you better think), will be blamed for not creating value… That sounds a bit like a real ‘con’, doesn’t it?

EOD

Here are some considerations/recommendations (they are based on personal experience and have always helped me a lot, but you know best what works for you):

(1)   Try to have in place a formal process to gather, document, get feedback and manage the workflow associated with the initiatives… but only if you do believe in it and are committed to run it seriously. Otherwise, do not bother: you will just generate frustration and lose credibility (NOW: if you think that you do need to do it but do not yet feel like you must do it, then try to have someone convince you by showing his results).

(2)   Report on and communicate successes, metrics (number of proposals received, implemented, discarded – by reason -, etc.), feedback received, etc. This is important (a) In order to show that this is real (b) To motivate your folks (c) To create a push to improve

(3)   Recognize contributions. You may not have money to give away, but you can surely send emails, post on the intranet or your group pages, comment in your group meetings, etc. Be specific, articulate the value, explain the challenges. Use it in your appraisal mechanisms.

(4)   Try to put aside time (or may I better say allocate?) of your folks to work on improvement initiatives, even if it is not as much as you would like, and enforce that work is done and results are delivered. This will help you in a couple of ways:

1. If you have specific objectives, deadlines, deliverables… you are way more likely to get results
2. People (quite naturally) tend to attach credibility to tasks with a budget  attached to them
3. You eliminate excuses for not contributing

(5)   Include discussions in your regular group meetings, allocate time and do not skip them. Only in the same conditions as in point (1).

(6)   Know your processes and analyze how they (seem to) interfere with innovation. Do all see how a specific control requirement adds value? What if it were removed?… Force people to be specific when describing how it is stifled by processes. There may be things to improve, but there may also be good reasons for having them: you may also drive good value from people understanding WHY things are done this way… and get ideas as to when they should be changed. I once worked at a client that kept for years a guy dedicated to processing a special tax… years after it had been eliminated. Also, they will see that there is also value in OLD THINGS (why else keep we doing them, man?)

(7)   Build up credibility for delivering your ‘normal work’: this will gain you room to undertake improvement initiatives. If you and your team are well-known for reliability, chances are that your bosses will not spend unnecessary time looking into how you do things. But if you and your team fail, then their eyes will be on you and, “how dare you waste time in ‘other things’?”

(8)   Have your people discuss regularly with fellow employees (e. g., business users of the systems and applications they support) as to what improvements they would like to have, what kinds of issues they see in their daily work. Ask them from time to time (what do they say? Who said that? When did he say it? What do you think we could do about that?) in order to track how they are doing in that respect. This will (a) give you relevant ideas and (b) help you gain support.

(9)   In prioritizing work and qualifying initiatives you may well encounter that there are way more of them that you can undertake. And there is an obvious question: ‘if every one of them has a good return, why we do not them do all?’ Maybe it is a good opportunity to also attach value and put an ROI label on things YOU ALREADY do. Note that normal operations are often undervalued: be sure that if you do NOT drop something that you already do, it is because of its cost/benefit (including mandatory stuff, of course).

(10)  Reserve for yourself the attribution to approve initiatives, even without an obvious CBA attached to them – you are the leader, after all, and many good ideas are not so straightforward, but do NOT reject proposals unless with a clear decision path for doing it. That would sound pretty much as laziness or arbitrariness (whichever looks worse).

As a final reminder, three things need to happen in any context where communication plays a role, regardless of the mechanisms, channels and people involved.

(1)   ‘Doing the thing’: if you do not actually, tangibly foster innovation, then do not bother to pretend you do (just because that’s what someone expects you to do)

(2)   Showing that you do it, and care: if something remains hidden from people, it is exactly the same as if it did not exist

(3)   Make sure your people see and realize. Very often people will not pay attention to internal bulletins, blog posts, etc. You may have to explain what has been done, the results obtained, how the improvements were received in actual meetings or conferences. People need to feel that this has something to do with them

Overall, I am convinced that management frameworks are not, per se, an obstacle to creativity, but you need to take BOTH control and innovation seriously, use common sense, and always have in mind what is the maximum value you can get from your people’s brains – which is usually a lot.

NOTES:

[1]   Of course, one initial problem is that there are very many potential implementations of such generic definitions, and in practice, and real life observance, can be interpreted in widely different ways. For the moment I will leave these considerations out of the discussion.

[2] Curiously, when legislation intends to favor companies – e. g., granting them some privileges – the long-term effect is negative, due to the accommodation that comes with lighter circumstances

[3] This assumes a minimum level of maturity (such as CMMI Level 2)

[4] Of course many proposals may just be the result of people wishing to try new stuff, deploy and practice with new tools, etc. You will probably have to refer to point (10) at the end of the article for these cases. However, in the IT domain is normally not so difficult to figure out metrics and ways to measure them.

[5] This is probably related (at least, partially) with the fact that the organization sees some things as necessary that for the individual employee may look like discretionary, and the other way round. This point is probable worth commenting separately.