10 tips for future-proofing gov.uk against mistakes it made before

The UK Government Digital Service (GDS) has just had a reboot.

However will it be value for money and deliver its objectives?
Will the Budget 2016 changes be implemented efficiently and effectively?
Read on to find out more.

Background

First of all, some background and context about where the Government Digital Service (GDS) came from and why it's building Gov.uk and doing it in an agile way.

In the beginning Government used to do waterfall projects. The seven stages of a waterfall project are usually as follows

Waterfall, the original model

However after a large number of high profile expensive IT failures, the seven stages often unfortunately looked a bit more like this. It wasn't always this bad, but sometimes it did feel like this!

Waterfall, when it goes wrong

Add in the hugely expensive and long procurement process, the massive documentation few people actually read, the lengthy complex contracts and change control process. All in, you can see this is not one which embraces flexibility, speed, quality for the citizen and value for government. Projects were frequently late and significantly over budget. By the time the product was delivered, the requirements were out of date. This was a culture dominated by meetings and paperwork rather than working software and value for money.

There was a groundswell in support for Agile following the Agile Manifesto in 2001 and Government sought to embrace the agile movement to minimise the likelihood of more big IT failures. This led to agile values being part of the 2010 transformation of Directgov into GDS - The Government Digital Service. Agile is about following the values in the agile manifesto which are valuing

• Individuals and interactions over processes and tools, 
• Working software over comprehensive documentation, 
• Customer collaboration over contract negotiation and 
• Responding to change over following a plan.

Although there is value in the items on the right, there is more value in the items on the left.

GDS - The 2010 launch

Shortly after the Conservative / Liberal government took office in May 2010, a report was commissioned by Martha Lane Fox on the then DirectGov service and this resulted in the report revolution not evolution.  Within 6 months, alphagov had launched (May 2011). 9 months later (Feb 2012) the beta was launched and the full service went live in October 2012. It was great to meet up then with my former colleagues and commemorate the previous 8 years.  The past had achieved progress, but better progress was to yet come.

GDS - 2012 - 2016

This is what agile in government feels like sometimes.

Lipstick on a pig gets a new look

The government is trying really hard to be agile but is often hampered by the slow waterfall behaviours of ministers, politics and some third party suppliers. A slow body (government) trying to move quickly with a speed-up rocket being the proverbial silver bullet. This is not only potentially dangerous, but when you get there, it's still a snail. This is doing agile rather than being agile.

If Henry Ford had asked his customers what they had wanted, they would probably have said faster horses. It took one visionary, not a democratic consensus to think of the mass market car. If Steve Jobs had asked his customers what they wanted I doubt they would have come up with the iPod (ridiculed at launch) or the iPad (who would have thought of that?). Doing things right is a combination of not only understanding the market and end users but also strategic vision and being able to launch in a relevant time-scale.

What went well at GDS?

Before I look at what didn't go so well, it's important to reflect on what went well. Overall GDS has made a great start. We have:

• A far more usable website than the one which preceded it
• Much easier to use services
• Cost savings
• A standard to aim for  
• A better way of working.

What didn't go so well and what needs to be fixed

However GDS has often been busy singing its own praises without reflecting openly on where things didn't work so that the wider sector benefits from this knowledge. In agile, you deploy early then inspect and adapt. You fail fast and when things do go wrong you move forward having not expended a fortune finding out what doesn't work. You learn about what works and what doesn't. You have retrospectives which allow an open opportunity to reflect on what works and what doesn't - these are absolutely not a blame game but instead an opportunity to learn from previous work in a productive and constructive way. The bad news is sadly not very apparent on the GDS blog, which does seem rather self-congratulatory, instead the press have been left to pick it up. Here's a selection:

1. Users shun new digital service and full digitisation plans were withdrawn.
2. Up to £180m in fines per year due to a botched examplar service and again here. Perhaps in future an examplar would be defined after launch and be dependent on what people think of it? How do you know it's an examplar before you build it and people use it?
3. All the great expertise built up in GDS will not be deployed to help local government  despite this being a good idea and a local government remit being announced in March 2015.
4. Turf wars where GDS stepped in as the "police" to fail an already successful site. Following a standard should not be at the expense of creating user dissatisfaction.
5. Failing to meet the standards. All services must publish performance statistics.  However all the data stops in September 2014.  Where is the more recent data?
6. GDS puts services live that don't pass. GDS prefer to call a fail a "not-pass". Here's the data of all live services including those that not-passed (failed) and went live anyway. 
7. Some services have had an embarrassingly low number of users. Dozens of services are listed on the dashboard at less than 100 users per year. Is this really a good use of money?
8.  £1.3Bn needs to be spent on improving HMRC's Digital IT.  How do you even begin to spend that much money in an agile project? If this is the Minimum Viable Product, then what is the full spend?
9.  Universal jobmatch is the most used service but still looks like a 1995 horror story with usability to match and jobseekers are compelled to use it rather than better designed competitor sites. If I was looking at user needs, I'd have tackled this one early on. It's thought to be necessary to track job applications - what if applicants actually get jobs without applying? What if the job is just on LinkedIn? Why is the most used service still so appalling to use and why do I need a government gateway ID? This has been designed for civil servant needs, not end users.
10. Sometimes it's so bad, even the BBC were calling for the site to be rolled back to 2009.

After all the issues it's now been announced that GDS admits it’s not as good as it could be. It took 4 years to find this out? That sounds like waterfall deluxe, not agile. Agile is about fail fast, not 4 years later and have a £450m budget.  Look at the site for a moment, this cost £58m in the last year. Sure it's saved money but at a cost of £58m a year?

Retrospective lesson: no one's going to be perfect, but as part of being agile you should be open and accepting about your problems early on rather than having the press do the job for you. 

Stock photo models want more from GDS too!

GDS - The 2016 reboot

On 9th March 2016, a reboot was announced of GDS. Ironically, the slides are also available in PDF format which is something that we really should be doing without in the mobile age.

The aims are now

1. provide coherent services that are easy to discover and use
2. make government participative, open and accountable
3. help government communicate with authority and trust
4. make great digital and user-centred publishing easy
5. make government content easy to re-use and build on

10 top tips to take the reboot even further

1. Optimise government too. GDS assumes people want easy to use services. It isn't actually about services and it isn't about easy to use. The ideal service is one I don't need to use at all.  GDS needs to work with government and feedback where government itself can be simplified and a simplified government becomes a strategic objective. Government needs to simplify. Just doing it at the digital level is missing the point. Legislation is too complex. Services are too complex. Simplifying it at the digital level is not feeding back to government to optimise the root cause of the complexity.
2. Optimise the speed of delivery. There's nothing in the objectives about being lean and fast or time to market. At the rate GDS is migrating the old directgov estate, the technology will have moved on so fast it will have overtaken what GDS is really trying to do. In the 1960s we filled in forms and sent them in. In the 1990s we filled in forms and contacted a contact centre who filled in forms. In the 2000s we filled in online forms. In the 2010s we fill in user friendly online forms. We already have the technology to say to our mobiles "hey Google, tell me my tax due to HMRC". Automated voice recognition, available now. Automated ID verification available now. No forms, no website. A computer in the background just making life easy for me. "Hey Google, tell me how much money I owe HMRC and pay it to them so it arrives on time". Isn't that a better future than a website only focus? Digital is a platform; websites are just a service on that platform for when a written interaction is necessary. GDS themselves put an alpha live, now you need to complete an alpha and an internal beta. This means you're not learning early on in service about what large numbers of users need or even if the service will be usable for them - farmers probably don't want a digital service if they don't have access to broadband for instance.
3. Ensure there is a clear demand and this influences priority. How about users voting for what service they need most and GDS implementing it? An open backlog where we can see the pipeline of work? GDS has made a start, but ironically for an organisation oriented towards user needs not really in a way that makes sense to end users.
4. Ensure there is genuine value for money. Don't spend money on services people don't use or which aren't cost effective.
5. Think about the citizen first. The new GDS aims look like they were written more for government's benefit. Customer centric organisations put the customer at the centre of all they do.  When you do this, then the government will benefit from it. 
6. Fix the worst bits first. The  pain points, such as Government Gateway ID and people not having a memorable login, for universal jobmatch need to be addressed especially as this is the main service for citizens. 
7. Use the best tools to help people. If want to get more people using website services then provide video tutorials to help people and then let them try things out in a safe environment to practice. That way fewer people will need to call contact centres for help.
8. Only relevant content. Please personalise Gov.uk. I live in Scotland and so I should be able to tell you this and not get content which is for England only. If I'm a Welsh speaker, prioritise content in the Welsh language as well.
9. Truly embrace agile. Stop doing big projects with no flexibility and public dates which are infeasible. Start small, prove the concept and then grow so no more universal credit type failures. Figure out the minimum viable product and think like a start-up.
10. Learning is two way. Up to now, GDS is being seen as the "gov.uk police" and the centre of excellence. This is great but as time passes this should become more federated. Departments such as HMRC and DWP are setting up centres of excellence and as they are closest to the citizens they serve they might find out things that would not only benefit them but GDS and wider government. Command and control is not an agile concept and GDS should collaborate and learn from government departments and be prepared to listen and adapt.

Bringing it all together into a strategy

1. Develop a strategic vision. What is the GDS of the future? What's the vision for how citizens, visitors and businesses will interact with government - how about as simply and easily as possible? Where's the GDS Start with Why?
2. Develop a target operating model. Realise that people would prefer to interact with government less, and optimise towards this. 
3. Ensure Digital by Default makes sense. Realise that Digital is only a channel and might not always be the most appropriate, easiest or most cost effective. For the nature of the service, the most appropriate channel should be chosen rather than assuming digital by default. 
4. Join up government. Government as a platform needs to extend to local services and join up. The UK government created the Council Tax, so why doesn't the UK government build a platform for collecting it rather than 300+ councils building 300+ solutions. How does that make any sense at all? When I change my address, I want to tell all government services at the same time - I don't care if they are provided by central government or not. Think about government as a platform across all of government, not just central government.
5. Use standards appropriately. Realise that one size fits all doesn't always work. Standards and processes should only be used to make things better, not worse.
6. Think beyond the service. Allow the user to connect with the relevant content which matters to them with the least possible effort. This includes personalisation, geo targeting and filters 
7. Simplify for the citizen. Do the complex behind the scenes work necessary to shield users from complexity. Users want simplicity. The renewal of the Car Tax disc - great! Let's have more clever thinking like this. Join up the legislative process and government thinking with what user needs are telling you so that there is optimisation all the way from top to bottom.
8. Measure, improve and optimise. Keep evolving quicker. Decrease your cycle time so that we don't have to wait 4 years for a review. Measure your service deployment time from discovery to launch and work out how to do it quicker and cheaper for the same quality.
9. Look for big wins not just incremental improvements. Look for the 10x improvements which Google embodies. Start there and think about applying this to government to enable huge efficiency savings.
10. Keep up the great work! It's not all bad really!

Four things you can do

1. Please feel free to share this article on social media  using the links below
2. Please comment on the GDS blog if you want to feed back direct to GDS
3. Please respond to the survey.
4. Comment at the end of this article.

About the author

Craig Cockburn has worked across the public sector as a freelance Digital Consultant including Direct Gov, The Department for Work and Pensions, The Scottish Government, The Public Prosecution Service, The Department for Business, HM Revenue and Customs, The Scottish Tourist Board, The CIO Council and Southwark Council and gives his views here on whether the GDS reboot will be a success both for government but more importantly for the citizen. Finally, if you feel I can help you with related Digital Transformation work, please feel free to contact me via LinkedIn or by email on craig@siliconglen.com.

Many thanks,
Craig.

Agile restrospective, the last 10 years

Here is a slideshare presentation I gave on 19th April 2012 at the Agile Westminster Conference. A ten year retrospective on agile on behalf of the BCS Agile Specialist Group of which I am a committee member.

The presentation immediately preceding was particularly interesting for me, given by Andrew Craddock, technical director of the DSDM Consortium. He spoke about DSDM Agile Project Framework for Scrum™. This is a brand new White Paper that describes how DSDM's Agile focus on project organisation, structure and governance complements the recognised team-focussed product delivery Agility of Scrum.

Link to Full conference agenda

Embdedded slideshare presentation:

10-Year Retrospective of Agile - BCS Agile

 

Craig

DSDM, Agile and PRINCE2

Following my previous articles on Agile in a PRINCE2 environment and Agile project management, I wanted to go into some more detail here on DSDM and some issue on adding PRINCE2 to an Agile project management method such as DSDM.

A little background for those new to the subject. PRINCE2 had its origins in the 1980s as an IT Project management method and in 1996 became a generic project management method. DSDM had its origins in 1994 as an IT project management method (specifically towards Rapid Application Development) and was designed to be fully compatible with PRINCE2. In 2001 when the Agile manifesto was signed, one of the original authors (Arie van Bennekum) was, and is, heavily involved with DSDM. Since 2007, DSDM has joined PRINCE2 in being a generic project management method, although still makes many references to its IT origins.

In looking at these two methods, which have co-existed for the best part of 20 years, we see many similarities, however there are also many important differences.

In most projects there are typically four key management roles to fill:

1. The project sponsor - the person who is paying for it and who is accountable for the delivery. 
2. The project manager - the person responsible for managing the delivery of the project.
3. Someone with overall responsibility for the project from an end-user perspective - including the business dependencies between the project and any other work in progress or implemented.
4. Someone with overall technical responsibility for the project - including the technical dependencies between the project and any other work in progress or implemented.

In the world of the UK public sector, there is typically a department as the customer and a 3rd party company supplying the technical solution. As a result, roles 3 and 4 evolved into the "Senior user" and "Senior Supplier" roles respectively. This fits nicely with the typical government model. In DSDM, the equivalent roles are "Business Visionary" and "Technical coordinator" as DSDM is typically used with fully integrated teams and does not assume a customer-supplier type of contractual set up. The differentiation in roles is simply a reflection of the typical roles PRINCE2 has been used on and the typical roles which DSDM has been used on.

The UK public sector as the "home" of PRINCE2 has invested a great deal of expertise in developing PRINCE2, training people in it and having it adopted across the public sector. Commercially at least asking all of this investment to be dropped in favour of DSDM is a big ask. It is therefore pragmatic for not just the UK public sector and also the wider PRINCE2 community to look at how the flexibility of PRINCE2 can be used to take advantage of Agile thinking and what role alternative management methods may have, specifically Agile management methods such as DSDM.

Let me address this by looking at the book Agile project management: running PRINCE2 projects with DSDM Atern by Keith Richards which is the principle book explaining how to make this integration.

The first few chapters of the book explain the rationale and advantages of DSDM and PRINCE2 separately and it is when we get to chapter 6 that we first see what bringing together these two methods might look like.

The integrated method described in Chapter 6 misses off the DSDM project stages and doesn't relate the PRINCE2 stages to their DSDM equivalents, namely the SU stage of PRINCE2 being approximately equivalent to the Feasibility phase of DSDM, the IP stage of PRINCE2 being approximately equivalent to the Foundations phase of DSDM and the CS/MP being approximately equivalent to Exploration and Engineering. This comes later. The more I look at this it appears to be PRINCE2 with modifications to incorporate DSDM techniques and it's still being called PRINCE2. In chapter 6, Keith actually says in 6.1.2.1 that Atern goes further than PRINCE2 in terms of delivery techniques, yet despite Atern adding value it's PRINCE2 effectively getting the credit.

In my view, developing a hybrid method means there is potential for confusion regarding the documents that are produced, their names and contents and also the team roles and responsibilities. The simplest way that works should be to either say you are doing PRINCE2 but incorporating principles and techniques from DSDM (specifically to help with Agile delivery where DSDM is stronger) or that you are doing DSDM and being agile, but adding elements of PRINCE2 to clarify some of the governance features which people coming from a PRINCE2 environment would be more used to. PRINCE2 is very "contract" and "sign off" driven, whereas DSDM incorporates Agile techniques that are really coming from a different place in terms of collaboration, minimal sign off, flexibility and dynamism. Is the culture of the organisation one which is using the "sign off" mindset or has it embraced the flexible world of Agile?

The book does not really explain what documentation is necessary other than some of the DSDM documents being added to the PRINCE2 documentation set which seems almost a step backwards - if as is stated you add the BAD and SAD to the PID, then presumably there are also elements of the PID which are no longer needed otherwise there is a document overload.

What would I suggest? Well in organisations that have multiple methods, I would suggest some sort of decision tree to decide on the best approach and also to understand the risks associated with that approach, dependent on the organisation's culture, awareness of the methods, the size of the project and its criticality.

Based on that decision tree, we could have a number of outcomes such as
- PRINCE2 as is or with some modifications
- PRINCE2 but incorporating DSDM techniques as advocated in the book
- DSDM with some PRINCE2 techniques (e.g. for 3rd parties using PRINCE2)
- DSDM, which by itself can deliver a project without PRINCE2
- Some other combination such as PRINCE2 with SCRUM or other agile principles.

In this I think there are a few different ways of blending PRINCE2 and DSDM besides those shown in the book.

I would suggest that unless the business and management are ready to do DSDM in the organisation that having a development team doing DSDM but a management board doing PRINCE2 is probably going to result in a conflict of culture and misunderstanding. It would be better if the board were fully engaged with DSDM at the outset. In that regard, I would suggest subsuming the senior supplier role into the technical co-ordinator role and also the senior user role into the business visionary role. If it is necessary to manage PRINCE2 workstreams within this (e.g. for an external supplier) then the DSDM/PRINCE2 boundary should be at the Project Manager level - this should be someone experienced in both DSDM and PRINCE2 and who on a day to day basis is closest to all the projects.


Further Reading:

• The DSDM Consortium
• The DSDM Consortium white paper DSDM and PRINCE2
• Information on DSDM on Wikipedia
• The DSDM group on LinkedIn
• The Agile Manifesto

Agile and PRINCE2

In January 2008, I posted an article on PRINCE2 and Agile which it seems has been #1 in Google for those search terms ever since and consequently has received a great deal of attention, comments and traffic.

More than 3 years later I have worked on 4 agile projects, become a PRINCE2 and MSP practitioner and qualified in DSDM (the Agile project management method mentioned in my earlier blog). I've also got a lot more experience - see my LinkedIn profile at http://www.CraigCockburn.com for further details - including 3 projects for Central Government (BERR, CIO Council and DirectGov).

Given the recent push to have Agile more accepted in government circles I thought it was time to update the blog.

A few things have been happening recently

1. The Agile Delivery Network are hosting a meeting later today. I am attending - the ADN appears to be a small developer led community promoting the use of Agile in government, especially from the software development perspective and working with the Institute for Government
2. This week we have seen reports in the IT media about the Government turning to small companies for help in introducing Agile and a number of important blogs such as Agile can fix government IT calling for agile to be taken seriously as a delivery method.
3. There has been a fair amount of debate about Agile in Government on the DSDM Group on LinkedIn and the DSDM group itself is also responding to the System Error report 
4. The government ICT strategy (March 2011) also states "Additionally, the application of agile ICT delivery methods, combined with the newly established Major Projects Authority, will improve government’s capability to deliver projects successfully and realise benefits faster. "
5. Increasingly organisations outside of government are deploying DSDM as a project management method rather than PRINCE2 as DSDM not only incorporates the benefits of Agile, but is also suitable for an environment that is regulated, compliance driven and is interested in meeting CMMI standards. Swiftcover (part of the AXA Group) won the award for "Most Agile aware organisation" at the inaugural UK agile awards in 2010.

So lots of change it seems. So where does that leave Agile, PRINCE2 and the appropriate choice of project management method in the new world of Agile government.

I am project management method neutral. I am not pro or against PRINCE2. What I am against is using PRINCE2 when it is either unsuitable for the project in question or that it is suitable, but there are more suitable methods. There is nothing in the PRINCE2 manual about producing reams of documentation although to be fair DSDM as an Agile project management method does go further and state that documentation should only be produced where it adds value. Neither am I going to recommend Agile when there are certain projects (especially those with risk to life) where you cannot adequately timebox testing and for which a pure Agile approach would be less than ideal.

PRINCE2 by itself assumes a waterfall like approach where the requirements are signed off at some level and then handed to development. There's no principle in the usual PID of fixing the time, cost and quality and flexing the scope. However, PRINCE2 does afford the project manager quite a lot of freedom and flexibility. The project manager works within the tolerances of time, cost, budget (and possibly scope) that are set by the project board and these can be as wide or as narrow as is appropriate for the project. In that regard, PRINCE2 gives the project manager the flexibility to get on with the job as best they see fit within those parameters. I was programme manager on the BCS "IT Project Team of the Year 2010" award winning programme. This was run along these lines of light touch management and working within agreed parameters - something common to both Agile and also a sensibly run PRINCE2 project. PRINCE2 really can have as much or as little ceremony as you like, it doesn't have to be a bureaucratic monster that some make it out to be, but in differentiating it from Agile, PRINCE2 does assume you know a lot more up front and are prepared to spend longer in analysis having detailed requirements to "sign off".

DSDM, like PRINCE2, had its origins as an IT Project management method but has now become a generic project management method capable for delivering both IT and non-IT projects. DSDM does have a lot more to say about day to day activities at the delivery team level (e.g. daily standups) and as such is more of a how-to manual rather than PRINCE2 which is more of a process guide for managers.

There are therefore a few potential options in choosing the appropriate method:

Choice of Development methods:

1. PRINCE2 with a waterfall development method (the traditional way)
2. PRINCE2 with an Agile development method (quick win for the PRINCE2 advocates)

Choice of Project Management methods:

3. An Agile Project Management method with PRINCE2 and one of the development methods above - -- Hybrid as put forward by Keith Richards  - author of Agile project management: running PRINCE2 projects with DSDM Atern published by The Office of Government Commerce and Agile Project and Service Management: delivering IT services using ITIL, PRINCE2 and DSDM Atern (by Dot Tudor and also published by the Office of Government Commerce. 
4. An Agile Project Management method without PRINCE2 and one of the development methods above. Agile project management with a waterfall development method makes no sense, so the alternative here is a full top to bottom Agile Project management and development method such as DSDM Atern. (published by the DSDM consortium, not the Office of Government commerce!)

I am dismissing 3 as not very useful. I've read the first book. It flips between one method and another not particularly blending them in any coherent way and comes up with a management structure that has BOTH the PRINCE2 board and the Agile project management team - 5 managers. This seems like a double headed monster. Besides not combining the "Senior User" and "Business Visionary" and also the "Senior Supplier" and "Technical Co-ordinator" there is still the conflicting philosophy of Waterfall and Agile to deal with. The only merit I can see in this split personality approach is for people interested in Agile management but who can't or won't take the leap and abandon PRINCE2 completely. DSDM by itself is enough. It doesn't need to be helped or hindered by PRINCE2 to be a success. The DSDM manual states although the method can be combined with the likes of PRINCE2, "For most organisations, Atern is all that is needed" (P29).

So the front runners for project management techniques emerge as :

1. The existing practices of PRINCE2 and a waterfall development method
2. PRINCE2 incorporating Agile techniques
3. DSDM Atern (or equivalent) Agile project management with Agile development techniques

There is no particular good or bad here; the skill is in choosing the technique most suitable for the project, people, skills, organisational culture, involvement of 3rd parties and so on. In the main however, I think in the new world of government project management we should be starting with 3 as the default position and then move to 2 if there are good reasons not to use Agile project management and to 1 if there are good reasons not to do Agile development. I really think there are few projects which are genuinely in the last category of requiring exclusively waterfall developmentl however. For further information, please see the Agile suitability filter paper [PDF] or the Project suitability filter. Note that both DSDM Atern and PRINCE2 can work alongside methods such as CMMI, see this paper on CMMI and Atern. 

Once we have got a culture that is comfortable choosing the most appropriate techniques for a project, we should revisit the procurement process. This still seems to favour a waterfall like approach of fixed scope rather than an agile like approach of fixed time, cost and quality and having scope as the variable. Once that is sorted I think public sector project management will be in a much better place.

Comments welcome. See also the follow up article.

Craig