I scared an Agile coach this week.
I’ve recently taken on a project role as Product Owner for an IT project we’re calling the Digital Workplace project, which aims to more effectively leverage several collaboration technologies (such as live chat, document sharing/collaboration and project planning/management) across the professional services teams at the University. Although I’ve called it an IT project, there’s really very little new technology in it, and it should really be called a behaviour change project underpinned by accelerated technology adoption – or something. In fact, all three likely tech tools involved are already available to all staff, it’s just that very few people actually use them.
There are big chunks of the University who still live and breathe email as The Way to do business, with on-premise network drives as The Way to store documents. This comes with all of the usual trimmings – Word documents circulated for review and edits, with rapidly multiplying suffixes – ProjectProposal_v1.0_md_edits_final_FINAL.doc and the like, endless versions of Document1.doc on the share drive, shared email accounts aplenty and zero access to network drives from off campus or via a non-Uni computer (adding more weight for the need to use email as one great big filing cabinet).
My frustration in working this way has been gradually building, to the point that when I was approached to be the business lead on this project I nearly hugged the Associate Director who asked me. Good thing I didn’t though – HR would probably not look to kindly on that sort of business.
Then, of course, the reality hit of what taking this project on actually meant. How does one go about leading a technology adoption project in an environment which is well entrenched in a particular way of doing things, and which quite frankly is already struggling with change fatigue from many of the mandatory changes which have occurred as part of the organisational transformation of the last few years?
Even attempting to define what success might look like was tricky. Was there a specific way we wanted people to use the technologies, or was it enough that they were using them in meaningful ways to improve the effectiveness of their daily work lives? That said, while defining success was hard, defining failure was pretty easy – people still wouldn’t be using the technologies because they saw no value in them, or (possibly even worse) they were made mandatory and became Yet Another Bloody Tool That IT Is Forcing Us To Use Even Though It Just Makes Life Harder On Top Of All The Other Tools We Need To Remember How To Operate.
My broad strategy on driving this change crystallised into two main ideas:
- Use a Solution Selling methodology to drive adoption; and
- Use the project Governance Group as the primary test case for testing the platform, the implementation method and the support structures.
The first of these two warrants a blog post in itself, which I might do at a later date, but in general terms I needed to inject a little bit of sales thinking into the project team. Ok, those who have known me in any meaningful way can stop laughing now, and I’ll confirm that my head has not imploded from the pure irony of me writing that last sentence, given my track record with sales weasels. My point here is that using some variant of a solution selling process like this one can be valuable in terms of driving adoption, particularly when the drivers for using such methods are to help people understand that there are actually better ways of working (as distinct from doing it to earn a sales commission).
It was the second one though which freaked out the Agile coach, and made me wonder if I’d pushed too far. My idea here was that the project Governance Group, comprising a diverse group of mid-level to senior managers (me included) with varying levels of technical competency, would be the ideal group to test the platform and the support structures around it. The Governance Group would be Ground Zero for the virus of change. To do this, I asked that we all use the technology platforms to their fullest possible extent, including meeting virtually using the live collaboration tool, storing documents in the cloud storage environment, and managing project progress using the cloud-based project planning and monitoring tool. I proposed that we banned sending around email attachments in our collaboration efforts, and in fact that we’d try and avoid email in general in favour of live chat.
Hearing the Agile Coaches words, along the lines of ‘wow, that’s really, uh, brave – it’s making me very nervous, but I’m not sure why’ then morphed into pointing out the risks of using a group of influential staff members to test out a way of working and an implementation and support model that in itself was still forming, which was a fair observation.
But I pleaded my case with the project team. If this platform and our engagement model didn’t work with this group, then how on Earth could we sell it to the rest of the organisation as an effective and enjoyable way to work with each other? Should we not take the risk with an engaged group of people who we can at least be up front about in terms of them being guinea pigs? If this was going to fail, then wouldn’t it be better for it to fail fast and within a self-contained group? If it did succeed with this group, then what better group of advocates could we ask for to go out and sell the benefits of the new way of working and actually believe in it.
After some conversation and a few nervous looks we agreed that this was a risk worth pursuing, and we will now kick off attempting to use the test the limits of the new platform as a Governance Group. If this works, we start the roadshows to promote the better world of work that could open up if we start to use the tools at our disposal effectively. If it doesn’t, then we fail, and we fail fast.
Upside – at least I’ll have still managed to unnerve an Agile coach by being too ambitious, and I’ll take that as a win any day.