Back in August I wrote a post about the Digital Workplace project that I’d been invited to participate in as Product Owner, and I promised I’d share updates along the way. In that post I also mentioned that I wanted us to use a solution selling model as a way to drive adoption across the University, and that’s the element I want to touch on today. I also want to point out a couple of things that the solution selling model doesn’t quite nail, and talk about how important it is for us as a project to address those shortcomings.
I’m extremely fortunate to have a really good boss right now. Not only is she good in the standard things that all bosses need to be good at, she’s also good at giving me enough rope in most situations to well and truly hang myself, which is something I need in order to let my creative side get a decent run. Possibly my favourite thing about her though is that she is, by her own admission, an overt skeptic of some of the innovations I try and drive. I appreciate this because it is a skepticism that gets put clearly on the table for me to think about, with no hidden agendas, and always with a good story behind it to back it up – and I respect that. The latest one was:
The boss, yesterday
“I was in a meeting the other day when we tried to bring in a presenter through <tool x> and we all sat around for the first fifteen minutes of the meeting while the person at our end tried to get it working, and that’s been my experience with using these online tools.”
Yep. I’ve seen it countless times before (including several times in the last month in meetings I’ve been involved in), the reality of easy and effective online engagement falling a country mile short of the promise. For the skeptics, these experiences all feed their confirmation bias that the only way to get people really interacting is to have them in a physical room together – period. Very often the tool itself is the thing blamed for the failure, but the reality these days is, in my experience, that there are a range of factors commonly at play in a failure like this.
Not that it matters to most. As a cyclist and motorcyclist, I’ve had many years of seeing confirmation bias at play first hand. One of us does something stupid, inconsiderate or dangerous, and every discussion forum thread in the universe lights up with the hackneyed criticisms that we’re all irresponsible louts who should be locked up or turned into hood ornaments. The point is that in any group like this where confirmation bias is at play, the actors need to make sure that their behaviour is beyond reproach, for they will unwittingly do far more damage by demonstrating poor form than to just themselves.
In a similar way, every time a substandard online interaction occurs in an environment where the culture is one steeped in face-to-face meetings, emails and shared Word document attachments, all it does is reinforce the confirmation bias that all this stuff is a neat idea, but it’ll never work here.
Which brings me to the strengths and limitations of the PUCCKA solution selling methodology I mentioned last time in relation to what we’re trying to achieve in the Digital Workplace. I’ll go through this step by step, starting with…
Pain
The first step in the process is identifying and articulating the pain being felt by end users to highlight the need to do something differently. While it is probably safe to say that many staff aren’t fans of having to edit multiple versions of the same document, or they hate how hard it is to get access to a shared network drive, or they lament that they have to trudge all over campus to go to meetings, all these pains are at least familiar. This now starts to wander into the realms of privilege, or as Wikipedia puts it:
…a special right, advantage, or immunity granted or available only to a particular person or group…
Wikipedia, ‘privilege’
These pains might exist, but the previous organisational structure never made them much more than a niggle, which is now all changing – but I’ll talk about that later.
Interestingly, the privilege group here is the reverse of what some might think. For some, the thought of being able to work from home, or from somewhere other than their normal workplace every day, probably sounds like privilege. Having been largely mobile for the last couple of months, I’ve seen the other side of this coin – the exclusion which happens when you work in an organisation that has a cultural blind spot to workers based away from the physical workplace. Those based full time ‘in the office’ have historically been able to work on their regular tasks in the knowledge that the people, processes and technologies they experience were all set up to work well in a largely static, physically co-located organisation. Note here that I’m not suggesting the individuals are privileged in this situation – I’m saying that the way we work is geared up right now to create an environment of privilege, and as tends to happen in such situations, you don’t really see it unless you’re outside it (I’d love to hear perspectives from some of my colleagues who work away from Main Campus to see how true this rings).
Privilege aside, wherever I go I hear the symptoms of pain getting worse, but rarely do I hear understanding of the root cause (which I’ll talk about in the ‘Compelling Event’ section), and the need for us to change the way we work.
Highlighting the pain is still a critical step, but so is the need to explain why the pain isn’t going to go away, and that in fact it’s going to get worse unless we change something.
Unique Selling Proposition
This is where a lot of our energy in the project is going right now, and it needs to. The product we release needs to be able to show that it can reduce pain, not add to it. This is where my heart sinks when I hear about poor experiences by staff from the kinds of tools we’re trying to promote, as I know that each poor experience is another piece of confirmation bias that we’ll have to chisel away in future, regardless of the causes, the context or the tool.
There’s another whole post in this to be done later, but for now I’ll summarise some of the key elements that make up our USP for the Digital Workplace, namely:
The Digital Workplace must be:
- inclusive of all users, regardless of their varying levels of privilege or capability;
- integrated, so that the tools work as much as possible as a unified suite, rather than a disparate set of point solutions;
- supported, both in terms of adoption and ongoing support;
- targeted, in the sense that it doesn’t try to be all things to all people, but instead aims to fix only the most common and ubiquitous challenges around workplace communication, coordination and collaboration;
- stable, both in the sense of reliability, as well as not having elements swapping in and out on a regular basis; and
- effective – if it can’t be shown to make life easier for those using it in very concrete terms, it has no value.
Plenty more to it than this, but this at least touches on the main criteria of our USP.
Compelling event
I hinted at this aspect in the Pain section earlier, and this is a critical one for the Digital Workplace. As some of you know, Flinders went through a major restructure of professional services in the last couple of years, culminating in a ‘go live’ date in February this year. In the old model, support teams were primarily located (physically and structurally) around one of fourteen Schools and/or four Faculties, and most of the work that went on was quite self contained in each of these. The different areas of the University (from what I saw anyway) didn’t talk all that much to each other, and to be fair they didn’t need to.
In the new model (and I could wax lyrical about how this all aligns with Marginson’s analysis of the evolution of Australian Higher Education, but I’ll save that one also for another post in another few years), professional services teams report through to ‘central’ groups, but are embedded in one of six Colleges in a matrix model, with consistent roles in place across all Colleges for each function. In my case, I now have seven teams spread across (I think) ten office locations, and a need for these teams to work much more closely with each other than they ever would have needed to in the previous model. These groups all need to collaborate, coordinate and communicate with the other services teams in their Colleges and their opposite numbers in other Colleges as part of their ‘matrix family’, and to be prepared that all actors in this scenario might be moving quite regularly between teams and locations.
This new model needs people, processes, technologies and a culture which are all flexible, responsive to regular and rapid change, and which work effectively in a physically distributed environment. The success of the whole model relies on this happening, it isn’t something that’s just a ‘nice to have’.
This is our compelling event, even if this is still only dawning on many of us.
Champion
Yep, you can guess the answer to this one. Enough said.
Key players
There are two broad kinds of key users at play in this situation.
Firstly, the business users. The ones who will benefit the most if we get this right, but who also need to take the lead in changing the culture across the University to show that there are other ways of working that can be effective. This is where the solution selling model falls a little short, as the end game of that process is to make a sale, whereas ours in this project is much larger – it is about changing the way we work. It is about changing our culture, and that is a much harder, much longer job.
As I mentioned in the first post in this series, the first group we’ve tried to tackle this with (outside of the project team) is the Project Governance group, and so far this feels like it has worked well. People now know that our meetings are all virtual, our documents are all edited live and online, and our planning is collaborative. In time, we need to use this group to drive more culture change at leadership levels across the University – we need to walk the talk at senior levels if we want to see the change spread. Our group of key players will expand over time, and will be just as much change champions as I need to be.
The second key group is our IT department. Whether it be the suitability of each tool from a technical perspective, the capabilities required to support it or the management of the overall platforms, we’ll succeed or fail on the quality of the services the IT groups can provide, including the vendors that will sit behind them. A good chunk of our time is looking at how we can build a model which we can transition the whole shebang to a business-as-usual model as part of our ‘exit strategy’ for the project, and I hope that this work will avoid the ‘throw it over the fence’ experience I’ve seen in so many other IT projects.
Aligned purchase process
Of all the steps in the process, I think this is the one where the biggest gap exists, sort of. In the PUCCKA post I’ve referenced earlier, this step is described as:
…your customer is ready to buy when you’re ready to sell
PUCCKA solution selling model
Perhaps this is less of a gap, and more of a case of understatement. In many sales situations, not only is the pain much more apparent, but also the ‘customer readiness’ is much less nuanced than what we’re looking at here. Remember my mention of culture change before?
We actually have a spectrum of needs here ranging from organisational to individual, and spanning elements such as cultural readiness, infrastructure readiness (particularly minimum specs of end user computers), process readiness, user knowledge readiness, support readiness and platform readiness. Right now our organisational maturity across many of these elements is extremely variable, and all of these are contributors to both the individual (the customer) and the organisation (the seller) being classed as ‘ready’. This, in itself, is a major piece of work, and (you guessed it) is something I’ll blog about later.
The road ahead
As I read the post above I’m filled with a slight sense of terror of just how long this process could take, and whether or not we have a decent chance of success. There are early indications of success though. We have a high-performing team using an agile methodology applied to a business context. We have the bones of an evaluation, deployment and support model for tools that we want to adopt as a formal part of the Digital Workplace. We have the first of our tools close to being signed off and ‘launched’ to the University, one which has been met with great enthusiasm by pretty much everyone who has used it. We have a governance group who are using some of our ’emerging’ tools effectively, and working in a way which models the kind of team interaction that we need to promulgate right across the University. We learn something new (and I’m not exaggerating here) almost every week as a team, and about ourselves.
We’re making progress, and only time will tell how far we can go.