Tag: process

There are no digital silver bullets

In a fairly complex world, everyone yearns for a simple solution. The one thing they should do to make things better. The single solution to all their problems. Digital transformation is no different, and many of the marketers working in this space know it – that’s why they usually claim that their ‘platforms’ will deliver everything an organisation needs to change itself for the digital age.

Sometime people read a single solution into things when it isn’t there. A good example would be my post the other day talking about the uses of low code platforms. Several people got in touch questioning my assertion that it was the answer to all of local government’s problems. I replied pointing out that it wasn’t my assertion, and low code won’t fix everything. It might help for quite a few things though.

Overall, I am always very nervous of transformation programmes that have a single view of the operating model of an organisation, particularly when we are talking local government, which delivers such a bewildering array of services that it would surely be impossible to have just one way of changing and organising them all. Are there really that many similarities between running a theatre and processing benefits? Or picking up waste and community development?

Instead, part of laying the foundations of an approach to digital transformation should be developing an openness to trying new tools, techniques and technology, and an awareness of all the possibilities that are out there.

On the tools and techniques side, this means having a really good knowledge of ways of doing human centred design, innovation and delivery. Check out IDEO’s resources on this, along with the 100% Open toolkit, and of course the GDS service manual.

For technology, really consider the capabilities needed to deliver the outcome your users and your organisation want to achieve. See if you can match those to what you already have, but don’t shoe-horn them in. Think about the maturity of the capability you need: if it is really cutting edge, you may need to build it yourself (whether in-house or outsourced); for everything else there ought to be something on the market to suit. Whatever you do, don’t get bogged down trying to build silver bullets – a universal case management system for everything, or some kind of middleware utopia that makes everything talk to everything else. You’ll end up tying yourself into knots and running a huge IT programme, which is nobody’s idea of fun.

As I said, by all means re-use capabilities wherever you can. It might be that you do end up using one case management system for everything, because it works. Great! But find your way there by iteratively re-designing your way through services, matching capabilities to outcomes, and not through the implementation of a grand technology project.

So is there an operating model that can be applied to everything an organisation does? Probably not.

Is there a change process that can be applied to every service you deliver? Probably not.

Is there a technology platform that will enable you to replace every other system currently in use? Probably not.

Should you try things out, find some alignment between the outcome you want to achieve and the stuff you use to get there? Probably, yes.

Photo by Jens Lelie on Unsplash

Collaboration – 10 steps to success

collaborationDigital tools provide great ways to collaborate online. Whether working with a smallish team to co-create a document, or engaging the wisdom of the crowd to build a list of ideas, the net allows us to work with people at a previously impossible scale.

But how to do so effectively? There’s nothing more depressing than a collaborative project that nobody wants to collaborate with you on; or a popular collaboration that runs out of steam, or drifts off at tangents.

Here’s a ten step process I’ve come up with to help your project succeed.

1. Identify who might be interested

There’s no way you will pinpoint every person who might be interested in what you are collaborating on. However, you should be able to spot the people you are aware of who will definitely get things going. This might be because they have a track record of getting involved on this issue, or that they know their way around these kinds of processes. Either way, they are useful people to have around.

Reach out to these folk and let them know what you are planning to do. Keep the specifics around the tech side of things vague, but recommend they encourage others to get in touch, so you can use other people’s networks to create a bigger list of initial collaborators.

Also find out at this stage roughly what level of tech-savvyness there is among this initial gang. Find out how they like to communicate – do they prefer email, discussion forums, or are they happy getting their hands dirty with a wiki? This will help inform which platforms you choose.

2. Put a platform together

Bearing in mind what you found out in step 1, decide at this stage what system you want to use. The fundamental factor is to keep things as simple as you possibly can. Other issues include whether you want to host it yourself or are happy for the content to be sat on someone else’s server, and whether you need to restrict access.

On the first point, by and large hosted platforms are far easier to set up and use and often are more functionally rich than those which you manage yourself. On the second, make it as open as possible, so that there are few barriers for people to get involved.

Make sure your decision on platform and process matches the research you’ve done with your initial user group in terms of the way people collaborate. Are they happy editing other people’s work? Would they prefer commenting, or submitting ideas?

Getting this right is important, but it shouldn’t get in the way of starting your project. Pick something that will hopefully work, but be flexible to allow for change in the future.

3. Get the content on the platform

It’s very hard to begin a collaboration with a blank page. You do need some content to get people talking and give them something to work with.

This, depending on your starting point, can be a quick or a very labour-intensive job. Copying and pasting text from other documents is fine, but when it is from (say) a PDF some cleaning of the formatting is likely to be necessary. Make sure you factor the time in to get this done.

Don’t forget your users when adding content. Consider adding some consistent header text to the top of each page, explaining what the content is, how it can be edited or discussed, and how the project administrators can be contacted for help, etc. Ensure that you take into account what people told you at stage 1. If people say they like to respond by email, make sure there is an email address they can send comments to, and a process for getting those comments onto the platform.

Ensure that the navigation for the platform makes sense and that people will be able to find the bits they are interested in easily. Test it out on some of your initial group to get their thoughts. Maybe find a complete web-novice in your organisation to take a look and see how they get on with it.

4. Set the rules of engagement

Having rules is boring, but a lot of people like them. Part of this will come into the page heading text I mentioned in step 3, but it is probably worth explaining again on a separate page. Make it explicit who should have view and edit rights to the content and also how vandals will be dealt with.

It might also be worth explaining exactly what will happen to people’s content that they add, who it ‘belongs’ to and under what licence it is published online. These things shouldn’t matter to most people, but those that do care often do so loudly.

It probably is also a nice idea to explain what the aim of the whole exercise is – what is the eventual output likely to look like? And how will those who have collaborated on it be credited?

5. Invite and manage contributions

Now invite your initial group to come onto the platform to start collaborating on the content. Keep it to this gang as much as you can to start off with. Any problems in the structure of the site or the way content is made available will soon be spotted and fixed.

Other things will be bound to go wrong at some point. People will accidentally delete entire pages of content, for example, and panic about what to do about it. Make sure you and your team are keeping a constant online presence to monitor what’s happening so you can react quickly to a) calm down the person who has just ballsed things up and b) put things right so the project retains at least a veneer of professionalism.

6. Figure out some roles

As part of the initial work with the smaller group, take the opportunity to identify some roles on the project and fill them with some of your early volunteers.

Roles can include:

  • Community manager – someone to keep everyone engaged and motivated on the project
  • Social reporter – a content creator who
  • Curator – collecting relevant content and useful information from around the web and bringing it together into one place
  • Gardener – a person who likes to keep your project tidy, cleaning up formatting errors, ensuring links work, and navigation makes sense
  • Evangelist – someone willing to go out and recruit new people to come and collaborate on your project

7. Market it

To get people involved beyond your core group of volunteers, you need to get eyeballs. Post to relevant forums, blogs and mailing lists about what you are doing. Telephone other contacts and get them to sign up. Stick a link to the project in your email signature. Mention it in every letter you write.

Don’t forget that you are asking people to give up their time to help you out for nothing in return other than the kudos of actually being asked for their opinions. Some will jump at the chance, others will need more persuading.

8. Get everyone in a room

At the very least, have a party at the end of the exercise to thank everyone. But even better, have one towards the beginning too. Even online networking fanboys like me appreciate that to get trust in a community, you have to meet one another face to face first. OK, you don’t have to, but it really does help.

Maybe you could have a collaboration hack day – a big room with lots of laptops, wifi, flipcharts and post-its, where everyone does their best to get as many quality edits done as they can, chatting to each other and developing ideas in real life. Plenty of coffee and sandwiches would probably help too.

9. Let go

Involvement in any activity like this one will involve the acceptance of a significant loss of control and messiness in the way things develop. This is good, don’t try and fight it.

Do moderate offensive or stupid content – that does no-one any favours. But if things are developing in a direction you didn’t expect, or don’t like, let it. Have a conversation about it. Examine your own preconceptions and assumptions and see if things can be worked out another way. But don’t go round reverting pages because you don’t agree with them.

10. Get the output sorted

Finally, make sure there is a recognised output at the end. Hopefully this could be some sort of document that people who like documents can read. Make sure it is full of links back to the wiki so that people can see who developed what idea, and how that idea changed from the original.

Make sure that a description of the process is included in the final document, and that everyone who contributed is credited. Go back to those forums, blogs and mailing lists that you punted the idea around on and let them all know how it finished. Make a fuss about the fact that this stuff works!

Do you have any tips for making collaborative digital projects work?

A red tape challenge for public servants? Or an internal GDS?

At the DH digital champions summit on Tuesday, during the afternoon open space session, an interesting discussion broke out. One among many, I’m sure!

Anyway, what was being discussed was the sheer unusability of government systems and processes. Only, not the ones that the public uses, but the ones that civil servants use.

I’ve worked in enough local councils, quangos and central government departments to know that the vast majority of IT systems in use are pretty dreadful. Clunky, and rarely fit for purpose, they seem to exist just to make life more difficult for those using them.

Likewise those processes yet to be digitised. How hard is it to bring in a temporary member of staff to get a job done? Sometimes the paperwork is so over the top, it’s quicker to do whatever it is yourself rather than get the extra body in.

It’s absurd and clearly must be a factor in the difficulty in getting stuff done within government.

The Red Tape Challenge is a crowdsourced effort within government to get rid of the burden of bureaucracy on businesses and citizens. It appears to have had some success in identifying areas where things could move a little quicker, smoother, and maybe with fewer dockets.

There’s also been a lot of focus – rightly – on the user experience for citizen and customer facing interactions. The work that GDS is doing in this area shows that it can be done.

I do wonder though whether a similar approach ought to be being taken to internal systems, across government. Maybe a red tape challenge style thing, where public servants can identify the particularly crappy systems and processes that make their lives a misery – and get them fixed.

Or maybe we need a black ops style skunkworks, wielding the knife on some of the more monstrous forms of obstructive paperwork and dreadful databases. Taking a similar user-focused approach to that which GDS – and many other public facing services – are using to such great effect.

There must be at least much opportunity here, to improve efficiency and save money, as there is in making things easier for the citizen?

Update: This here looks interesting – via @pubstrat

JFDI vs Being Boring

Light blogging recently, I’ve been gadding about talking at a load of events – which is fun and rewarding in its own way, but doesn’t really help with getting any work done, nor with writing here.

Last Wednesday I was at the LGComms seminar on digital communications, and had the opening slot explaining why all this stuff matters. I was on slightly shaky ground as I don’t really know all that much about digital comms, just the social bit. I’ve no idea how to run a proper corporate website, for example. Anyway.

My slides were the usual concoction, and they’re on Slideshare if you want them. My general message was that while the internet is undoubtedly important for communications, it’s a mistake to put all of this stuff in a box marked comms and assume it doesn’t affect or benefit other parts of the organisation and the way they work.

One slide I included was pretty new, and it featured a pretty crappy graph I threw together in Powerpoint:

JFDI vs Being Boring

Click it for a bigger version. The point here is that by taking a JFDI approach – to any innovative behaviour, not just social media use – you get a lot done quickly. The trouble is that it isn’t terribly sustainable, because it is often the work of one or two enlightened individuals and it isn’t terribly well embedded in corporate process, systems or structures.

The alternative is to be boring, and go down the route of getting the strategy and procedure sorted early, and developing activity in line with that. This is a lot more sustainable, as everyone knows what they are doing and what they are responsible for. There is a problem though, and that is that being boring is slower than JFDIing – your innovators might get fed up and leave, and your organisation might be perceived as doing nothing, when in fact it’s just moving rather slowly.

My take is this: it isn’t an either/or choice – do both. Just get on with it, choosing some small projects to prototype and feed the findings from that activity into the longer term process and system building approach. Keep the innovators happy by giving them some space to experiment, whilst building the foundations that will help the rest of the organisation understand and feel comfortable with.

Don’t let strategy and process get in the way of doing good stuff. At the same time, don’t JFDI and find yourself exposed.

Social processes

The following presentation was linked to by Dennis Howlett, who said:

The…slideshow from Mark Masterson makes the point that when dealing with exceptions, the best tools available to us are the knowledge that resides in people’s heads. Ergo – the argument goes: implement social software as a way of capturing that information for current/later use. I don’t have a problem with this except that as currently iterated, most of the tools represent yet another IT silo outside the process flow. Even so, I’d encourage folk like Mark to keep refining their thinking so that critics like myself stand a chance of being persuaded.