IT governance under attack as collaborative tool use goes ballistic: A way forward
Picture it now. The head of IT security has just been informed the whole company is moving to Working from Home (WFH) over the next week. All of a sudden, Microsoft Teams or Zoom or Webex or Slack (or put your favoured collaboration tool here), has to be rolled out post haste. Those carefully crafted roll out plans spanning the next couple of years now have to happen in the next couple of weeks!
For those charged with managing the IT infrastructures of major corporations, this is the nightmare scenario; Ground Zero. We know the story. The executive is all on board for rolling out new tools to help the organisation collaborate more effectively. But just one leaked document, stray toxic message, unwanted digital guest; who do they come looking for?
IT Governance in an Uncertain World
Over a decade ago I published a book on “IT Governance in a Networked World”. Up to that time I had spent the major part of my career in IT, performing a breadth of roles including Infrastructure Systems Manager, Systems Engineer, Business Analyst, Researcher and Management consultant. Early on I had witnessed IT governance models that mimicked a “cathedral” where each organisation owned its own hardware and mostly developed its own software. The IT leaders were the high priests and the end user community was the unwilling congregation.
Over time, the IT environment has morphed significantly. Computer hardware services are now exclusively provided by outsourced providers. Increasingly, those providers have now become cloud service providers. Software became packaged and also provided by external vendors. The marketplace moved from an “ordered high street” to a “bazaar”, with vendors of all types and sizes competing for attention. All along, the IT function remained the front door to the organisation, with the challenging task of navigating the bazaar and ensuring IT services could be safely delivered to their respective business partners.
My motivation for writing the book at that time was that I felt the IT world was at a tipping point. Governance methods designed for the “cathedral” were no longer appropriate for an increasingly networked marketplace. My research into business networks, I believed, offered a way forward for the embattled IT function in dealing with this increasingly complex new world. Increasingly, IT was being expected to not only manage the IT infrastructure but also be on top of the vast array of business applications becoming available.
Over the past decade or more I have been working outside the IT function; on the other side of the fence, if you like. Working with clients around the globe, plying my organisational network analysis trade, the story was the same. The IT function was regularly one of the most disliked functions in the organisation; usually battling with HR for the dishonour. It was hard not to be defensive of my former occupation; but even my network analyses were showing the most hated functions were also the most closed and insular ones. These functions typically sustain a culture more aligned with their occupation than the organisations within which they sat. Regrettably the IT cathedral is still alive and well!
But being a tight network is not a bad thing; it’s how groups develop deep competencies, sometimes called “Deep Smarts”. I can still vividly recall one of my former facilities management colleagues boasting with a sense of pride that “for over 30 years I have never lost anyone’s data”. Likewise, that security manager would also develop pride in building the fortress that can repel the ever-present security incursion threats.
However, as network science has proven time and again, tight networks need to be balanced with a healthy dose of external connections i.e. a diversity of experiences, if exceptional performance is to be achieved. We have all experienced the stifling bureaucracy of entrenched silos in organisations. But it’s in times of crisis that we start to see unprecedented co-operation across previously warring functions.
Moving Outside the ‘Comfort Zone’
Ironically, it’s a network of another type that is the ‘burning platform’ that will force the issue of IT governance in the COVID-19 (and likely post COVID-19) WFH era. The common COVID-19 tag line of “you are not alone” should also now apply to that IT security manager, IT infrastructure manager and IT Applications Manager. Now is not the time to bunker down behind the IT functional walls. Now is the time to reach out to your business colleagues; learn where the new risk/reward lines can exist and ask that the risks now be shared equitably.
As an IT Manager, ask yourself:
How many of your ‘friends at work’ are outside the IT function?
How many groups do you belong to that you are the only IT representative?
When was the last time you addressed a group of workers (not managers) on why a particular software function had been disabled, using words they understood?
When was the last time that your physical work space was outside the IT function? (excluding WFH)
As a non-IT Manager ask yourself:
How often have you managed to work with IT to overcome a governance barrier, rather than to simply complain about it?
How many IT discussion groups have you looked to become a member of?
When was the last time you invited an IT staff member in to attend one of your regular staff meetings?
How often have you sourced your own IT solutions to avoid IT governance regulations?
Reaching beyond the comfort of your own work group is not easy. But unless we do, the cathedrals walls can only get stronger.
A Way Forward
IT Governance is no longer just complicated; it’s now complex, bordering on chaotic. In our recent Microsoft Teams Benchmarking report, we offered the Cynefin Framework as a means for thinking through this new complexity. In the complex space there is no one right answer. As World Health Organization epidemiologist Dr. Michael J Ryan has recently stated "the greatest error is not to move" and "speed trumps perfection" when it comes to dealing with an outbreak such as coronavirus”. The same can be said for IT governance in the current environment.
The Cyefin framework calls for a “Probe, Sense and Respond” approach in complex situations like these. In other words, lead with (failsafe) experiments. In the current context these need to be short, sharp and numerous. Monitor these experiments closely, looking to amplify the good and closing down the bad.
To help make this more real, let’s put this into the context of a rapid Microsoft Teams roll out. The ‘governance’ issues that typically need addressing when rolling our Microsoft Teams include:
Who can create a ‘Team’ and what prior groups should we be migrating to Teams?
How do we manage ‘Teams bloat’ if anyone is allowed to create a Team?
Who should take ownership of Microsoft Teams? Who are the key stakeholders? Who should be administrators with the power to set permissions for Teams and individuals?
What external applications should be allowed to be accessed through Teams?
What if we already have some of the Teams functions sourced elsewhere e.g. electronic meetings?
Should we be using naming conventions to help people find things?
What about archiving? Who decides what is kept and what can be deleted?
What processes can be stopped now that Teams is available. How can we avoid ‘double work’?
What training should be provided? Should it be mandated before use?
Any of the above points could justifiably take weeks or months to agree on in normal circumstances. There is a rapidly growing knowledge based on ‘best practices’ for Teams, many of which we capture in our recent Microsoft Teams benchmarking report. It is fair to say though that in the current time-compressed COVID-19 environment, even the operational governance decisions itemised above have become ‘Complex’, and therefore need to be addressed appropriately:
Probe:
1.Select a number of teams of differing types e.g. small self-directed (< 10 members), single leader project teams, communities and forums that are low risk i.e. if the experiment fails, no lasting damage will occur. For those with SWOOP for Teams these are the Team Personas.
2. Enable Teams for these groups, with no options turned off.
3. Nominate a team ‘coach’ to oversee their Teams usage. This coach should not only be proficient with the technology, but also have some working experience with the team type being overseen.
4. Time box the experiments to 2-3 weeks maximum.
Sense:
6. Use analytics to monitor Team interactions. These (available in SWOOP dashboard) should be at a minimum:
a) Overall activity (messages) for the Team over time (at least weekly but for more active teams, daily)
b) People to People engagement levels (look for reciprocated two-way interactions)
c) Isolates (those members that are not engaging). What is the proportion of active to inactive members?
d) Relative use of chat vs threaded discussions vs calls vs meetings (not currently in SWOOP but can be reported through the Teams Admin panels)
e) Dependence on document sharing. Look at the tabs added to Team Channels. How prominent were SharePoint? OneNote? Non-M365 applications?
6. Closely analyse each Team’s use of the different communication channels. Focus particularly on the channels you see a perceived risk i.e. that are candidates for being turned off e.g. video meetings, external members etc..
Respond:
7. Bring the ‘coaches’ together to compare notes. Look to identify the high performing Teams as positive case studies for use in the roll out. Offer guidance to those teams that struggled.
8. For those Teams making use of ‘at risk’ functions, invite them to a group session (can be online) aimed at identifying the risk/reward frontier i.e. what damage to the business would occur if this function were to be disabled? Where a convincing case can be made by the Teams to support a function, document the Team, its context and the supporting analytics into a case file.
9. Collate the results (both high performing Teams and Teams using at-risk functions) for presentation to the executive sponsors for Microsoft Teams, identifying the risk/reward resolutions made. Where enabling a function incurs added costs e.g. bandwidth increases or added security functions, include this as a business case.
10. Go forward together with confidence!