Digital Thirst: Platforms

I have been struggling to articulate this one to be honest. Of my original 4Ps it is the most technical in nature and while I knew exactly what I meant I haven’t really been able to find the words.

Thankfully the new Government Digital Strategy has done it for me. Action 11 states;

Cabinet Office will lead in the definition and delivery of a new suite of common technology platforms which will underpin the new generation of digital services

Now for some of us this Cabinet Office suite of platforms will not be readily available but that doesn’t mean we shouldn’t look to learn from (or share) as much as possible from them. All of us need flexible, stable tools on which we can build digital services that live up to the expectations of our users. Presently it is far too common to be locked into technology solutions that offer no such flexibility and are essentially sealed black boxes that cannot easily be modified or updated (either due to the technology or the contractual arrangements surrounding the technology).

The digital world moves quickly and we need platforms that at least give us the possibility of keeping up!

It is also important that they used the plural – it is platformS not platform. This is not the age of the ‘one size fits all’ solution. Much as I love WordPress and treat it like a digital Swiss Army Knife sometimes it is not always the best answer. That is the same for any CMS you can think of. The key is the ability to be able to build around, extend, integrate to provide the best product for the job (which is where all the API stuff comes in but that is for proper technical types to write about.)

Digital Thirst: Process

Of the 4Ps I mentioned in my original post this is actually the one that I am finding hardest to define and articulate. Most of my thoughts are about what doesn’t or hasn’t worked rather than a way forward and I am trying to avoid that. Alot of this seems to bleed into the idea of Products not Projects but we’ll see where we get to.

In my career I have been all sorts of PMs except the big one. I have been a Project Manager, a Production Manager, a Programme Manager and a Product Manager. I have studied & used Prince2, Scrum, DSDM and MSP and various other bespoke interpretations. Each and everyone had its strengths and weaknesses and to a great extent each of them depended on the manner they were implemented and adopted for their success. Prince2 doesn’t *have* to be a bureaucratic, paperwork creating monster, Scrum can quickly become as bogged down with external issues as anything else.

I do think the ‘agile’ movement was one of the first attempts at something that really was targeted at modern web/software development and thus does have a whole lot of benefits. The guys at GDS have just written a great post about how they used agile. I very much enjoyed my time at Jiva working in a Scrum team – it was certainly the most productive I ever felt and the near instant gratification of ideas > code > production was an eye opener.

The thing is though in my (relatively limited experience) this kind of Agile (bit a big ‘A’) only works when you have those kinds of multi-disciplinary teams working closely together – preferably in one physical location. [I realise companies do run distributed Agile teams but even then they are teams working on a common goal with a common employer.] The simple fact is most of us in my corner of the public sector are never going to have that luxury. Teams consist of 3 or 4 people and if you are lucky one of those is technical. As I mentioned in my People post it is helpful if people have picked up additional skills but the reality is things like in-house specialist web designers or UX people are rarer than hens-teeth. These roles are out-sourced and with pressure on budgets these days they are only out-sourced when projects are already tightly scoped.

The fact is procurement and the processes that surround it remains as big a part of my job as the delivery of my actual objectives and is almost the polar opposite of ‘agile’. Things like the G-Cloud are very welcome but they haven’t really filtered down to many of us yet and so the challenge is how do you act in an ‘agile’ way when weighed down with procurement rules designed for the purchase of particle accelerators.

So my thinking of how to be more ‘agile’ (with a small ‘a’) has increasingly been about turning it on its head a bit and taking a new look at how we scope and then communicate these pieces of work that we need done.

I was very much inspired by a post I read a while ago from Gez Smith about ‘How to Buy Digital Engagement Software‘. It could easily have just been titled ‘How to Buy Digital..’

There is alot of great stuff in the article but for me thing that clicked, and synched up with my desire to be more ‘agile’ within my own reality was this one;

3: Write user stories, not lists of functionality.
At the end of the day, what are you looking for in buying software; a bunch of functionalities, or a series of ways for real people to do real things? Sometimes, people seem to think they’re protecting themselves by writing a detailed list of things software must do, as they have a checklist to compare against the final outcomes. But if you try to play that slightly legalistic game, then you actually make it easier for people to use semantics to do things the way they want. Instead, give potential suppliers a list of goals you want people to be able to achieve by using the software, and let them explain how their software will meet these goals in return.

One of the things as a Product Manager/Owner in Scrum I found most interesting and fulfilling was writing user stories. The ‘As a user..’ template most commonly used forced me to boil things down to the really core needs and get away from the traditional shopping lists of functionality & capability that so often end up dominating. Combining this with the ‘lean’ concept of data driven decisions and you end up for user stories that you can back up and are more useful for both the person writing them and the eventual supplier delivering the solution.

Doing things this way also allows suppliers to offer you something you might never have thought of yourself. The fact is there are always people out there more expert than you and if you give them space to be creative you will often get unexpected but improved results.

Most people reading this will probably just think this sounds obvious and would have been doing it for years. The fact is though this still seems radical to many in positions of power and so to even try it on something of any scale it again comes back to having people sufficiently high in the hierarchy to support the concept and push it through.

Digital Thirst : People

I think it is easy to get into a state of mind where technology becomes the be all and end all of any digital strategy. The new CMS is going to make everything better….or Twitter is….or that iPhone app you are working on. The reality is though that when push comes to shove it all comes down to having the right people in the right places at the right time. Good, innovative people will find ways to do good work even if the technology they are using is restrictive junk – getting the tech right just improves their success rates.

I’ve written before about my dislike of the term ‘digital natives’ and how I prefer the ideas the came out of the TALL team at Oxford Uni around the concept of ‘digital residents’. It isn’t about age or education it is about having people around who live and breath this stuff. People who understand the possibilities and equally important can see how those possibilities fit in with their own professional environment. Increasingly though it is clear that understanding things alone isn’t quite enough – you need to be able to *do* stuff as well. I’m not in the ‘everyone should code’ school of thinking but more and more I believe you need to be able to contribute in a practical manner – especially as budgets get squeezed. Whether that is with HTML & CSS, a little PHP, some rich media editing skills or a deep understanding of Google Analytics I don’t think matters – there are jobs for everyone these days! I’d love to have a GDS style army of developers etc at my disposal but the reality is I have a team of two and we do what we can and then we juggle the budgets to bring in some talent to make us look good.

The outside ‘talent’ is vital I think. Having a roster of people who have the skills you lack, who understand what you are trying to achieve and who you trust (especially to point out better ways of doing things) makes such a big difference. I try to work with small, very specialist companies. Often just one or two people. I am able to build relationships with them and I know what they can do. There are risks with this approach for sure – single points of failure and the possibility things get too cosy but I remain convinced it is the best way forward. As soon as you start working with larger agencies etc your relationship starts to be with middlemen and that rarely ends well.

The idea of the ‘critical friend’ is one that I have really come around to in recent years. It is so easy to become overly evangelical about digital solutions – especially if you spend alot of time in the Twitter echo chamber. Like Maslow sort of said “if all you have is a hammer, everything looks like a nail”. I find having people around who aren’t naturally inclined to see a digital solution to every problem but also aren’t close minded and are willing to listen to arguments invaluable as they really keep you honest and force you to take a hard look at things. This often leads to better solutions digital or not and certainly lessens the chances of false starts.

Last but far from least is the need to have support from sufficiently senior people to get things done. I have little time for the JFDI way of thinking these days (though I certainly have been in the past and maybe will again) – it is unrealistic for so many people especially in the public sector. The fact is most people who talk like that *know* they have cover from above and it is that fact that empowers them. I still think the greatest achievement of the Government Digital Service was to recruit genuinely digital savvy people into properly senior positions.

Digital Thirst

[the title is a bit of a joke at my own expense – I can’t pronounce ‘th’ sounds so thirst and first sound the same when I speak!]

Like ‘digital by default’ the term ‘digital first’ has become pretty popular shorthand for a particular kind of organisation shift in recent years. The first time I came across it was in relation to the Guardian strategy but since then I have seen it used for a number of media companies and most recently in relation to the Department of Health strategy and in some recruitment ads for the Wellcome Trust (both of which are quite a bit closer to home career-wise.)

There do seem to be subtle differences between the ‘digital by default’ and ‘digital first’ strategies but to really identify them I’d need to spend more time re-reading various examples of strategy documents than I really ever intend to do so I’m just going to concentrate on my own definition of ‘digital first’. That boils down to;

Digital communication is the first thought not the afterthought – it influences all other communications channels rather than simply reflects (poorly) what has been done elsewhere.

As an organisation my current employers are quite some distance from any definition of ‘digital first’ but nonetheless I have been spending some time thinking about what it might take to change that and how much I can do to move things along.

At the moment I have this idea of the 4Ps which I am using as a framework for my thinking. I am going to try and write a series of blogposts focusing on each of the Ps just to sort out the jumble of ideas in my head and see if something coherent can actually emerge. I am trying to focus on these ideas being practical and realistic in my own environment rather than some unachieveable perfection. (An example of this being that having in-house multi-disciplinary teams doing development is once again seen as the best way forward – look at the success of GDS and the Guardian – however given restrictions on headcounts and budgets that is never going to happen.)

So these are my 4Ps;

People – Upper management buy-in, digital residents (not natives), critical friends, (access to) multi-disciplinary teams.

Processes – agile with a small ‘a’, lean minus the sleaze, access to decision makers.

Platforms – flexible infrastructure. a technical foundation that can be built on.

Products – discrete, definable, ‘shippable’ products not never-ending projects. Small things loosely joined.

Well thats the easy bit done 🙂 Now I need to do the hard graft and flesh out those ideas!