Let’s Legitimise Rogue Behaviour.

In my short time in the blogosphere I’ve noticed a common theme around CIOs, IT Architects and others in the IT community concerned with “Rogue” behaviour.

I say rogue behaviour because some posts refer to rogue users, others to rogue solutions, rogue IT etc.

The common point is that if the IT function does not serve the business with what it needs, then you can absolutely guarantee that some rogue behaviour will emanate from the business.  Usually the IT function doesn’t even know about it, until the rogue solution falls over and the business calls in the IT guys who are suddenly landed with a mission critical “system” to mend and support.

So how do we square the circle here?

Ramon Padilla at Tech Republic reckons it’s about governance and, to be fair, the ability to execute.  His fundamental and very interesting point is that the level of rogue behaviour is directly proportional to the level of business needs unfulfilled by the IT department.

I’ve mentioned more than once in previous posts of an IT Project Manager friend of mine on a CRM upgrade asking the users if they had “any odd change requests” he could throw in as part of the project only to be stunned to receive a list of 250 items.  Now that is a dam waiting to break into a flood of rogue behaviour.

The problem with Ramon’s views in my mind is that no IT function can possibly hope to deliver everything that the business needs.  Therefore rogue behaviour is inevitable so IT has a choice to turn a blind eye to it or to try to stamp it out.

But taking a leaf from Tony Blair’s management workbook I am going to propose a third way and that is for the IT function to positively encourage rogue behaviour.

However, there still needs to be governance, auditability, change control, security etc.  So how about if we roll out tools that have a degree of central control but allow local maverick or rogue solutions to be built by the business community?

One area I know quite a lot about is tactical, or robotic integration methods that enable users to build code free interfaces that can be stitched together into business processes.  In this way, clerical processes fragmented by the use of multiple heterogenous systems can be mended.  There are a number of tools, (including Blue Prism’s) that provide this ability but combine it with central controls that can remain in the IT domain and meet enterprise security and auditability demands.

There must be other examples of using tools as enablers for the business to deliver its own tactical improvements on a local and incremental basis.

Of course this is not the pure, ideal and long term solution.  But until IT can deliver the longer term strategic solution why should the users be constrained?

So in summary, let’s legitimise rogue behaviour because failure to do so will not stop it but merely drive it underground.

Leave a Reply