A digital maturity model and competencies – some ideas

At the moment many Departments are working out the implications of their digital strategies and how to follow up on the commitments that they made in them.

This is where a digital maturity model becomes useful since to implement such strategies it is handy to know where you are already and where you want to go. I could even use jargon and say – ‘you can set the direction of travel’. A maturity model might help become a map with a ‘digital compass’ for such a journey. Gruesome analogy, sorry.

Of course a lot of people have a good feel of were they are but what if you really want to nail it and say with confidence to someone else, yep we are good at x but not so great at y; and even say what level you are for different dimensions a fairly rigorous model can be an asset.

This is pretty well what I want to do myself and have a map that I can leave for others to follow.

Competencies

One strand of such a model relates to staff competencies something that I had a chat with Julia Chandler from Dfid @juliac2 earlier this week. I had a line in the model about staff capability – but what does this really mean?

But before we start what competency models already exist or might exist? Apparently GDS will be producing some in the future but not yet. GCN have some pretty good ones for communicators. However if we want to become, in DoH’s great phrase ‘Digital first’, that is not going to be enough. What competencies or capabilities will a policy team need for open policy making? What about a Finance team producing open data? Etc.

So these are Julia’s headings that map back nicely to my (I use the term loosely) maturity model.

  • Creative – writing, edit etc
  • Communications – tools, techniques etc.
  • Engagement – using an engagement life-cycle
  • Security/risk management – governance and propriety issues
  • Analytics – creating, using and interpreting metrics/data
  • Awareness/knowledge – of the digital environment etc.

Measuring competence

So how would we measure such competencies?

The usual Gold, Silver and Bronze might work well for each level and a nice badge would be handy.

So if you were a policy wonk and had followed some core training you could be given your Bronze badge (digital of course) and merrily go on your way to start doing exciting stuff.

These are just some thoughts that we wanted to share – so feel free to contribute or contradict. What is missing? Does this all map to the maturity model that we have so far?

Creating a new website – legacy issues 2

Here is a question to think about.

If you switched off your webserver now what services would stop working?

Well probably your website, but what else?

What about all those other bits and pieces that seemed a good idea to squirrel away because, well, we have a server.

So this is the other issue that troubled me when we rebuilt our website in March ‘what would stop working’?

Here is my list:

  • SNAP surveys because we were not using a cloud based service – we moved our account onto SNAPs servers which involved talking out our survey team colleagues.
  • Two private log in areas to transfer business information – not quite an intranet but fiddly to recreate in a new environment especially when there were a lot of different URLs in circulation.
  • A private page for office use when the web might be our only communication channel with staff – being recreated in email alerting software.
  • A custom built database of report recommendations – built in .NET and which does not work in our new environment – we are linking to a National Archives copy until it can be rebuilt.
  • Other odd bits and pieces like our Contact form – we built a new one then had problems with emails from GSI addresses
  • A toolkit built in flash that was not value for money to rebuild as it has been custom built – we put it on a .NET server, tidied it up and linked across to it.

I suspect this is only a small amount of issues compared to other organisations however dealing with these ‘legacy issues’ all added to the workload.

A digital maturity model

I have been thinking about a Digital Maturity Model for some time. For example Steph Gray @lesteph and I hosted a session at last year’s Govcamp where we covered this issue.

Since I have wanted to move things on a bit here I thought now is the time to revisit the maturity idea. At the same time Steph has also given an update on his thinking.

So based on some of his comments and my own thoughts I have started to draft the attached. It is a Google doc so it can be edited or you can leave some comments.

As you will see it has a few blanks so feel free to suggest what should go in the gaps. I have tried to make this very functional as I suspect that this is what most people need immediately.

However this does not rule out a more higher level overview perhaps in the spider format Steph has suggested. It will work well for briefing senior leaders – perhaps even your Digital Leader.

[googleapps domain=”docs” dir=”spreadsheet/pub” query=”key=0Ah0QJ7QYJgs3dGs0aUNGOE9fM0o2T0dMNXFXNTVyNXc&single=true&gid=0&output=html” /]

Creating a new website – legacy issues

In the middle of March we launched a new version of our website in WordPress. The other key elements being that it is hosted on Amazon Web Services and the code is in Git. All fabulous stuff.

Though this was a major project, I tried not to make it a ‘major project’. However I did learn a few lessons so why not share some of them, painful blow by blow.

Legacy issues

Ah, that fateful word in IT circles – legacy.

Things that are easily overlooked are:

  • which bits of your infrastructure do you actually own – are they on your assets register?
  • how do you (or someone else) decommission them and when?
  • which contracts exist – when do they run out – how much notice do you need to give of non-renewal?

I will almost guarantee that your contracts have different lengths. How do you get them in synch so that any switch over can be co-ordinated? Will you have to pay extra money to extend a contract?

How do you avoid insulting your existing suppliers when you tell them that you have ‘found someone else’.

In particular what if you want an element of contingency if something goes wrong and you need to revert back to your existing suppliers? Or you need the old suppliers to work with the new ones? Tricky huh.

So relationship management skills come to the fore.

What do your users want?

I often hear people saying, ‘I have a great idea, why don’t we do..’ or ‘I have seen a great website with this feature I want to do the same’ and variants thereof…

Indeed, I have been known to do the same myself.

However who are these things for, be they software, a service, or a product?

Are we trying to make our egos feel better; or have something ‘innovative’ to add to our staff reports; or do we just want to do something different because we can?

As a well known quote goes ‘with great power comes great responsibility’.

Or to put it another way ‘just because we can, it does not mean that we should’.

What about the user?

The who?

A user is the person or people who might want to use your software, service or product.

In another guise it could be one of us when we do our shopping online, buy cinema tickets, or download a new tune. We are all users at some point. Remember that site that drove you mad recently, or the one that worked smoothly? How many of these took their users into account.

So what can we do about it? What is our ‘great responsibility’?

Well a good start would be to look at this excellent piece of work by the Government Digital Service their Service Design Manual. GDS have drew up this manual to help government organisations design cost-effective, user focussed online services.

Have a browse, particularly the section on Discovery when user needs are researched before a new product is developed. It sounds so obvious but do we always follow these principles?

I am hoping to do use this manual more in the future so do not be surprised if when you say to me ‘I have a great idea’ that I send you the link above – you have been warned.