Democratising the Enterprise Software Portfolio

As I have worked in one fashion or another with the various challenges of broad and diverse enterprise software portfolios over the last decade, it has become clear that there is one undiscovered and very fundamental barrier to effective portfolio governance: very few portfolio governors have realized that they are not in control.

Systems acquisition is traditionally a key aspect of the enterprise IT organization's self image. This leads to the illusion that the portfolio is predominantly or exclusively composed of systems which went through the formal acquisition process. Let's remember again why we are interested in mapping out our systems portfolio: it's because these systems reflect, support, and extend the processes which constitute our core business.

It's a very comforting thought, that our systems portfolio consists of only the specific systems which have been through our formal acquisitions apparatus. The perceived determinism gives us the illusion of control.

The truth however is that our systems portfolio is broader and less kempt; it's only a matter of degree. The accountants will have Excel workbooks with embedded logic. The product development team will be running a guerrilla wiki, hoping to keep it under the radar so as to not lose productivity. The marketing people are using Dropbox instead of the VPN.

So what can be done about this problem?

Well let's begin by not seeing it as a problem. A lot of organizations aspire to employee creativity and empowerment. If the employees are able to independently identify and satisfy information systems needs this is actually a happy circumstance; it means that we are hiring the right kind of people.

Of course, it's not difficult to see the proliferation of "unauthorised" software in the enterprise as a problem if the mandate which has been handed to the IT department is one of command and control. To command the rest of the organization's relationship with technology and to control acquisition.

That, however, is an obsolete software portfolio philosophy, even if it is still in widespread use.

In a modern IT organization, the mandate revolves around dialog, visibility, maturing, and support. Dialog with the organization, granting visibility to the systems people use, helping the rest of the organization mature the way they use the systems they use, and eventually transitioning the "rogue" systems into the software portfolio as acknowledged and approved members, relieving the other departments of the need to support software while still enjoying its benefits.

In a modern IT organization, the users are prototyping new software. It is our role to be aware of this prototyping, to monitor its boundaries, to support the experimentation, and to identify when it is time to transition the experiment into something more permanent or to help the user decide to scrap it. The users are not breaking the rules, they are prototyping and experimenting for the advancement of the organization's ability to leverage increasingly appropriate software.

The software portfolio is only a reflection of top down acquisition and architectural policy if its purpose is to represent an incomplete view of the enterprise's employment of information technology. And an incomplete software portfolio is not a useful software portfolio.

Do we lose some control like this? Probably. But command and control IT management is not the way of the creative enterprise.

This article was originally published on LinkedIn.