Don’t apply traditional IT portfolio governance to shadow IT.
Why? Start with two iron-clad rules of IT portfolio governance:
- No business sponsor, no project. With shadow IT, sponsorship is automatic. If nobody in the business cares at sponsorship levels the project wouldn’t be happening. A formal governance check is superfluous.
- The only legitimate outcomes are “no” and “when.” There’s no maybe, and no priority scoring. With formal IT, approved projects are those added to the master schedule, to start when the necessary staff are available to work on them.
With shadow IT, the whole point is that the business area undertaking the project isn’t willing to wait.
The entire reason businesses need so-called IT governance … really, business change governance … is because of scarcity. In most companies there just aren’t enough IT developers to satisfy the business appetite for change and improvement.
Scarcity isn’t part of the shadow IT equation. Rather than trying to get their slice of the IT developer pie, with shadow IT, business units own the whole pie.
Does this mean shadow IT should be governance-free?
Yes … but no.
“Governance” almost always means “a committee must review this.”
That’s the no. Just as we have to restrain our natural impulse to strangle idiots, so, in business, we should restrain the impulse to form committees.
The yes comes from what we might call the John B. Finch principle: “Your right to swing your arm leaves off where my right not to have my nose struck begins.” (Oliver Wendell Holmes usually gets the credit.)
Shadow IT projects (really, shadow business-change projects) have three noses in range:
Re-keying: Shadow IT tends to deliver “islands of automation,” unintegrated with the rest of the company’s applications and information portfolios. That often results in the need to re-key data from other systems into the shadow-IT system, and to re-key data from it back into the company’s systems of record.
The former isn’t a problem. If the department head decides re-keying into the system is just fine, it is, by definition, just fine.
But the latter? If the re-keying must be performed by employees who report elsewhere, the project might violate the Finch Principle. It doesn’t if they’re keying the data now and this just changes the source. But if one manager is shoveling new work into a different department’s inbox, it’s a Finch Principle violation.
Fortunately, there’s a committee-free solution readily available. All the manager whose nose has been put out of joint has to do is document the offense and its budget impact. The result: The Finch Principle violator has to bear the expense. The company budgeting process obviates the need for separate governance.
Data exposure: Imagine the point of a shadow-IT system is to facilitate working with an external partner. Now imagine it inadvertently exposes sensitive data beyond the walls of the corporation. It’s a clear Finch Principle violation.
Happily, there’s a committee-free solution to this too. It’s a policy, probably an existing policy: InfoSec reviews all systems that are used by or expose data to outsiders.
Data governance: A popular approach to IT integration is the “federated architecture” — an environment that looks like a unified whole even though under the covers it’s been assembled from a variety of COTS and SaaS solutions.
A major challenge for federated architectures is reconciling data definitions so that data entered into one system can flow into the corresponding fields in other systems without mishap. As those in the trenches know while those who rely on PowerPoint do not, semantic mismatch, not field-level synchronization, is the big challenge to systems integration.
Shadow IT systems will often ignore the usual controls for this because it’s an eye-glazingly boring problem. Unless, that is, you’re either responsible for the integrity of the IT architecture, or genetically predisposed to lexicography.
Even if integration happens through re-keying, semantic mismatches can pollute data in the company’s systems of record.
The solution, to the extent there is one, doesn’t require a committee, although regrettably, many companies rely on committees to handle data governance.
Companies that want consistent data create and maintain some sort of glossary (data dictionary or encyclopedia) for that purpose. Everyone who uses data relies on it.
Which in turn probably means you’ll need to create some form of “Glossary Police” to make sure even shadow IT projects adhere to its definitions. But please … don’t make the Glossary Police a committee.
You’re better than that.
Bob,
Your posts on shadow IT and governance are making me damned uncomfortable. Which probably means it’s a timely topic that warrants my attention and opening up my thinking.
In government, we have some unique constraints: the rules of corporate finance don’t apply. Attempts at governance through budget are ineffective, because of grant and categorically programmed revenue sources. Talk about a formula for inefficiency, data silos, and unsupportable systems!
We’ve spent a few years cleaning up the outcome of no prior governance by creating a process to vet new projects. It’s worked to reduce complexity, stop projects doomed to failure, and focus efforts. Maybe killed a few winners in the process as collateral damage. But now I’m struggling with the need to break free some innovation and agility without creating a too much of a mess.
As regards your three noses and committee free solutions:
* Rekeying – This budget approach just doesn’t work for government, where I can’t simply charge the other department/division. My default thinking is back to the committee approach, but I need to think about this some more.
* Data exposure – I think this is oversimplified a bit. For big transaction-oriented systems it makes sense. But for other stuff: Does Dropbox adoption expose company data to outsiders? How about other click-through terms of service SaaS solutions? Do the business innovators know the difference and what to bring to InfoSec for review?
* Data governance – This is a really good point. Hard to achieve in a large complex organization. There’s a real investment required in figuring out what data entities are in the dictionary, hearing from all the affected users/operations, and figuring out when to converge on a standard definition and when to declare a new data entity. Somewhere in there, there is a balance of “just enough” data governance.
Thanks for these challenging columns!
– Jim
Bob,
I think the InfoSec idea has to be used with great caution. “Security” is a very common reason for formal IT to say no and wrest back control — which just sends shadow IT further underground. It needs to be a proper risk management approach with a predisposition to saying “yes”, not a butt-covering “no”.
And the “Glossary Police” should be the role of the Information Management section. Too bad they have a similar tendency to step on non-approved recordkeeping systems rather than working collaboratively to make them work for the business.
You may not need a committee, but you may need ‘police’. Yes, there is probably a policy about sharing data with outsiders, but shadow IT could be oblivious to the policy.
Please explain what you see as the difference between a “committee” and an organization or function such as InfoSec or Glossary Police. To me it seems like a distinction without much of a difference.
Committees are composed of people who represent different constituencies and figure out compromises everyone can live with. InfoSec and the “glossary police” (probably IT’s technical architecture function) aren’t representative bodies – they’re staffed departments with a chartered purpose.
Committees meet on a schedule, usually monthly; departments have daily responsibilities.
Stuff like that. Make sense?
Haven’t even read yet.
Just want to bring to your attention that the ‘permalink’ points to last week’s article…
(laughing) I love your solution to rekeying.
I think that your suggestion for “police”–InfoSec for external connections, and someone to enforce consistent data definitions–is the best balance I’ve heard so far. It does strike me as amusingly ironic that these police will be most effective in companies with solid “traditional” governance.
Your reminder that IT governance should be synonymous with Business Change governance is probably the gem of the week though… At least for me. That should be obvious, but when I spend too much time looking at the trenches I tend to forget it.
– Kai
Thank you for advocating a simple data glossary! Including acronyms! It has been a personal pet peeve when I have arrived on projects to find that a common vocabulary is not in use. A particular word, phrase or acronym may speak volumes to “those in the know” whereas newbies or those on the periphery may have a very different view. At least with a glossary one can verify (or correct) one’s interpretation.