Operational delivery mike bracken

Mike BrackenExecutive Director for DigitalGovernment Digital Service@MTBracken

Create GDSFix publishingFix transactionsGo wholesale

GDSGDSMike Bracken

@MTBracken

PublishingSearchIdentityMetrics/MIAnalyticsAssisted digitalDigital inclusionDomain managementTicketing/SupportTransaction ProcessingAppointment bookingHosting

That involves a lot of detail

GDSGDSMike Bracken

GDS

But there are six main programmes:

GDSMike Bracken

GOV.UK

GDSGDSMike Bracken

GDSMike Bracken

Identity

GDSMike Bracken

GDSGDSMike Bracken

Technology

GDSGDSMike Bracken

Measurement and analytics

GDSMike Bracken

Capability

GDSMike Bracken

GDSGDSMike Bracken

Transformation

GDSGDSMike Bracken

25 of the most important transactions in government, making services significantly, noticeably better for people by 2015

OpenAgileMultidisciplinary teams

GDSGDSMike Bracken

Led by skilled and empowered service managers

GDSGDSMike Bracken

Within the civil service

GDSGDSMike Bracken

GDSGDSMike Bracken

Driving and transport Benefits

Businesses and self-employed Employing people

Passports, travel and living abroad Education and learning

Working, jobs and pensions Housing and local services

Crime, justice and the law Money and tax

Births, deaths, marriages and care Disabled people

Citizenship and life in the UK

Services and information

How government works

Worldwide

Policies

Announcements

Departments and policy

Departments

Topics

Publications

Help Cookies Contact Cymraeg Built by the Government Digital Service

© Crown copyright

GOV.UK

Guidance

Agile digital and IT projects: clarification of business

case guidance

Updated 11 April 2014

Contents

Existing guidanceAgile spending project approval process

Is there anything wrong with this page?

See more information about this Guidance

All content is available under the Open Government Licence v2.0, except where otherwise stated

Search

To help with efficient planning and approval of spending proposals for agile digital and IT projects, the following

clarification of business case guidance has been produced in collaboration between HM Treasury and the

Government Digital Service. This should release the potential of the agile approach to produce better systems

more quickly and cheaply than conventional IT planning and project management while maintaining effective

business planning and spending control processes.

This should enable a controlled early release of resources for the Discovery and Alpha phases of agile projects

and enable a proportionate process of planning and control that delivers value for money without excessive

bureaucracy.

Existing guidance

All current Treasury guidance on production and approval of business cases, the guidance on Treasury approval

processes, the Treasury’s Departmental Spending Limits rules and the supplementary Cabinet Office controls

on digital and IT operated through the spending mechanism remain unaffected by this.

Although this supplementary business case guidance focuses on projects that require HMT spending approval,

it is expected (as with all current HMT business case guidance) that it will be understood as best practice and

applied to all projects requiring spending approval including those falling within DEL.

Agile spending project approval process

The approval process for agile projects should be adapted to suit each project’s spend and the risk to the

programme within which it sits. There are 3 categories for which different variants of the approval and business

case process are appropriate as follows:

All agile Discovery and Alpha work is regarded as initial research and, subject to a limit of £750,000, would

normally be undertaken from departments’ DEL budgets subject only to CO controls. Agile projects are

frequently part of wider business programmes to be delivered for reasons of either business transformation or

business continuity. Even before Discovery and Alpha, departments should have a clear justification for why

such scoping is financially and strategically worthwhile. This should be submitted in the CO control form.

The Discovery and subsequent stages are learning phases that feed back into the evolving project business

case and into the wider Programme Business Case of which the project is a part.

The relatively low level of spending involved, the need for GDS approval of digital projects and the existence of

an overarching programme business case (which defines the business scope, the outputs, their timing and the

likely resource allocation of the agile project), allows the business case and approval to be streamlined and

tailored to suit the needs of the programme and project. Thus, the classical three stage approval process (SOC,

OBC, FBC) can be adapted to support something more suited to agile. This guidance clarification recommends

more use of PBCs for programmes and project approvals using a light touch OBC only (this may be iterative).

HMT and GDS have agreed that departments can spend up to £750,000 from within their own DEL budget on

Discovery and Alpha as a research and scoping activity subject only to CO IT/digital controls. If a particular

project requires more than £750,000 this can be agreed by the overarching programme, in consultation with

the relevant approving authority, which in many cases will be the HMT spending team.

Projects that are above DEL spending limits or which are novel or contentious require Treasury approval at

these stages but the process should be adapted to suit the case and set out in the PBC.

Larger projects costing above £10 million (for the whole life of the project to the end of two years live running) or

which pose significant risk to the programme should be approved by the Treasury through the project approval

process but using an agreed plan of monitoring and approval points set out in the management plan of the PBC

rather than through a classic three stage process.

Smaller projects costing below £10 million that are not high risk to the overall programme can be approved and

managed against the PBC without needing a separate OBC.

Project level approval for larger agile projects should use a light touch OBC and try to minimise traditional

detailed IT planning documents. Instead, they should focus on user needs, business outcomes, costs and

milestones within the context of a wider programme business case. This project approval process should be

agreed as part of the wider management plan of the wider PBC. We recommend that management review

meetings should use digital service demonstrations and agile artefacts (e.g. burn charts , backlogs ).

Relatively inexpensive agile projects, which are not high risk to the programme within which they sit, can be

approved as part of the programme approval process. That approval process should be planned as a part of the

PBC (currently branded as the Strategic Outline Programme and due to be rebranded later in 2014).

In some cases a programme will have numerous agile projects, each of which is below £10 million spend but

which in aggregate cost over £10 million (this typically happens in a department wide transformation

programme). In this case, a PBC should be used rather than multiple OBCs, but the PBC should contain a

significant degree of economic scrutiny proportionate to the spend. It is also particularly crucial when managing

a programme of agile work to schedule regular reviews and to use the service demonstration, burn charts and

backlogs to give the approving authority a high level of visibility and control over the speed of progress and the

prioritisation of tasks.

Using the SOP/PBC process has the advantage that as well as being relatively light touch for the agile project it

also highlights clearly how the agile work fits into a wider programme by flagging dependencies.

Walkthrough of the process to obtain agile spend approval

This can be done before the business case for approval is complete based on an outline brief containing the

business outputs required, the timing needed and likely scale of funding available because it qualifies as

research and feeds back to inform the options appraisal in the business case.

At the start of Discovery, if external approval will eventually be required departments should contact the HMT

spend team and MPA (if they haven’t already done so) to plan the engagement described in the next paragraph.

Low Spending projects: where spending on agile is relatively low and external approval of the project business

case is not likely to be required, the PBCs provides a more streamlined vehicle for managing external spending

and approval where project spending is below £10 million.

The PBC currently known as the SOC - template here, see pages 8-19 - is a good vehicle for managing spending

planning and approval where the agile spend is relatively low but is a vital enabler of a larger, wider programme

with a total whole life programme spend above £10 million.

Higher Spending projects: alternatively, if the whole life agile project spending is likely to be above £10 million

an OBC is needed. The programme team should work on the business case and the MPA Project Validation

Review at the same time as the agile team complete Discovery and Alpha phases. The completion of the PVR

and PBC is not a pre-condition for this work to begin. The programme business case should include an agile

spend envelope with some sensible allowance for contingency. HMT must sign off a business case before you

can move into Beta. If the expected project cost is £10 million or if the project poses high risk to the delivery of

the programme, a project business case is required, but it does not need to take the form of the Full or Final

Business where procurement is taken care of through the use of pre-competed digital frameworks .

This assesses the service against the Digital by Default Service Standard.

CO Spend Controls and HMT (for projects above delegated spend limits) both look at the proposed agile Beta

spend. In general, HMT’s main focus is economic / financial (especially affordability, delivery and value for

money); CO’s focus is more on the appropriateness of the technology choices being made. CO Spend Controls

will only approve Beta funding to projects for which a working Alpha can be demonstrated.

During Beta and Live agile delivery, updates by the department to HMT and MPA should normally focus on a

digital service demonstration accompanied by agile artefacts (e.g. burn chart, backlog) rather than

conventional technically detailed and lengthy IT project documents. The department should agree with HMT

and MPA what arrangements are appropriate to monitor, review and approve Beta and Live spend in each

particular project. Review and approval points should be planned and agreed at the outset as part of the

programme management plan and be aligned to selected reporting points and delivery appropriate to the

particular service (e.g. every 6-12 months).

Assessments take place before a service is available publicly on the internet in Beta, and again before the

service can be branded as “live”. These assess whether the service achieves all the points of the Digital Service

Standard, and hence give a sufficiently high quality user experience to enable that service to become digital by

default.

If departments have further questions about how to apply this guidance, please contact your HMT spending

team (or GDS/MPA as applicable).

Initial research and scoping stages of all Agile projects – Discovery and

Alpha

Larger projects costing above £10 million

Smaller projects costing below £10 million

1. Apply to CO Spend Controls for Alpha and Discovery funding

2. Do Discovery and Alpha

3. Develop and write a project business case and/or input to a PBC (in parallel

with, and informed by, Discovery and Alpha)

4. Alpha digital service assessment

5. Apply to CO Spend Controls to release Beta funding

6. Beta and Live agile delivery

7. Digital service assessments

HM Treasury










Worldwide

Policies

Announcements


Departments

Topics

Publications


© Crown copyright

GOV.UK

Guidance

Agile digital and IT projects: clarification of business

case guidance

Updated 11 April 2014

Contents

Existing guidanceAgile spending project approval process


See more information about this Guidance


Search

To help with efficient planning and approval of spending proposals for agile digital and IT projects, the following

clarification of business case guidance has been produced in collaboration between HM Treasury and the

Government Digital Service. This should release the potential of the agile approach to produce better systems

more quickly and cheaply than conventional IT planning and project management while maintaining effective

business planning and spending control processes.

This should enable a controlled early release of resources for the Discovery and Alpha phases of agile projects

and enable a proportionate process of planning and control that delivers value for money without excessive

bureaucracy.

Existing guidance

All current Treasury guidance on production and approval of business cases, the guidance on Treasury approval

processes, the Treasury’s Departmental Spending Limits rules and the supplementary Cabinet Office controls

on digital and IT operated through the spending mechanism remain unaffected by this.

Although this supplementary business case guidance focuses on projects that require HMT spending approval,

it is expected (as with all current HMT business case guidance) that it will be understood as best practice and

applied to all projects requiring spending approval including those falling within DEL.

Agile spending project approval process

The approval process for agile projects should be adapted to suit each project’s spend and the risk to the

programme within which it sits. There are 3 categories for which different variants of the approval and business

case process are appropriate as follows:

All agile Discovery and Alpha work is regarded as initial research and, subject to a limit of £750,000, would

normally be undertaken from departments’ DEL budgets subject only to CO controls. Agile projects are

frequently part of wider business programmes to be delivered for reasons of either business transformation or

business continuity. Even before Discovery and Alpha, departments should have a clear justification for why

such scoping is financially and strategically worthwhile. This should be submitted in the CO control form.

The Discovery and subsequent stages are learning phases that feed back into the evolving project business

case and into the wider Programme Business Case of which the project is a part.

The relatively low level of spending involved, the need for GDS approval of digital projects and the existence of

an overarching programme business case (which defines the business scope, the outputs, their timing and the

likely resource allocation of the agile project), allows the business case and approval to be streamlined and

tailored to suit the needs of the programme and project. Thus, the classical three stage approval process (SOC,

OBC, FBC) can be adapted to support something more suited to agile. This guidance clarification recommends

more use of PBCs for programmes and project approvals using a light touch OBC only (this may be iterative).

HMT and GDS have agreed that departments can spend up to £750,000 from within their own DEL budget on

Discovery and Alpha as a research and scoping activity subject only to CO IT/digital controls. If a particular

project requires more than £750,000 this can be agreed by the overarching programme, in consultation with

the relevant approving authority, which in many cases will be the HMT spending team.

Projects that are above DEL spending limits or which are novel or contentious require Treasury approval at

these stages but the process should be adapted to suit the case and set out in the PBC.

Larger projects costing above £10 million (for the whole life of the project to the end of two years live running) or

which pose significant risk to the programme should be approved by the Treasury through the project approval

process but using an agreed plan of monitoring and approval points set out in the management plan of the PBC

rather than through a classic three stage process.

Smaller projects costing below £10 million that are not high risk to the overall programme can be approved and

managed against the PBC without needing a separate OBC.

Project level approval for larger agile projects should use a light touch OBC and try to minimise traditional

detailed IT planning documents. Instead, they should focus on user needs, business outcomes, costs and

milestones within the context of a wider programme business case. This project approval process should be

agreed as part of the wider management plan of the wider PBC. We recommend that management review

meetings should use digital service demonstrations and agile artefacts (e.g. burn charts , backlogs ).

Relatively inexpensive agile projects, which are not high risk to the programme within which they sit, can be

approved as part of the programme approval process. That approval process should be planned as a part of the

PBC (currently branded as the Strategic Outline Programme and due to be rebranded later in 2014).

In some cases a programme will have numerous agile projects, each of which is below £10 million spend but

which in aggregate cost over £10 million (this typically happens in a department wide transformation

programme). In this case, a PBC should be used rather than multiple OBCs, but the PBC should contain a

significant degree of economic scrutiny proportionate to the spend. It is also particularly crucial when managing

a programme of agile work to schedule regular reviews and to use the service demonstration, burn charts and

backlogs to give the approving authority a high level of visibility and control over the speed of progress and the

prioritisation of tasks.

Using the SOP/PBC process has the advantage that as well as being relatively light touch for the agile project it

also highlights clearly how the agile work fits into a wider programme by flagging dependencies.

Walkthrough of the process to obtain agile spend approval

This can be done before the business case for approval is complete based on an outline brief containing the

business outputs required, the timing needed and likely scale of funding available because it qualifies as

research and feeds back to inform the options appraisal in the business case.

At the start of Discovery, if external approval will eventually be required departments should contact the HMT

spend team and MPA (if they haven’t already done so) to plan the engagement described in the next paragraph.

Low Spending projects: where spending on agile is relatively low and external approval of the project business

case is not likely to be required, the PBCs provides a more streamlined vehicle for managing external spending

and approval where project spending is below £10 million.

The PBC currently known as the SOC - template here, see pages 8-19 - is a good vehicle for managing spending

planning and approval where the agile spend is relatively low but is a vital enabler of a larger, wider programme

with a total whole life programme spend above £10 million.

Higher Spending projects: alternatively, if the whole life agile project spending is likely to be above £10 million

an OBC is needed. The programme team should work on the business case and the MPA Project Validation

Review at the same time as the agile team complete Discovery and Alpha phases. The completion of the PVR

and PBC is not a pre-condition for this work to begin. The programme business case should include an agile

spend envelope with some sensible allowance for contingency. HMT must sign off a business case before you

can move into Beta. If the expected project cost is £10 million or if the project poses high risk to the delivery of

the programme, a project business case is required, but it does not need to take the form of the Full or Final

Business where procurement is taken care of through the use of pre-competed digital frameworks .

This assesses the service against the Digital by Default Service Standard.

CO Spend Controls and HMT (for projects above delegated spend limits) both look at the proposed agile Beta

spend. In general, HMT’s main focus is economic / financial (especially affordability, delivery and value for

money); CO’s focus is more on the appropriateness of the technology choices being made. CO Spend Controls

will only approve Beta funding to projects for which a working Alpha can be demonstrated.

During Beta and Live agile delivery, updates by the department to HMT and MPA should normally focus on a

digital service demonstration accompanied by agile artefacts (e.g. burn chart, backlog) rather than

conventional technically detailed and lengthy IT project documents. The department should agree with HMT

and MPA what arrangements are appropriate to monitor, review and approve Beta and Live spend in each

particular project. Review and approval points should be planned and agreed at the outset as part of the

programme management plan and be aligned to selected reporting points and delivery appropriate to the

particular service (e.g. every 6-12 months).

Assessments take place before a service is available publicly on the internet in Beta, and again before the

service can be branded as “live”. These assess whether the service achieves all the points of the Digital Service

Standard, and hence give a sufficiently high quality user experience to enable that service to become digital by

default.

If departments have further questions about how to apply this guidance, please contact your HMT spending

team (or GDS/MPA as applicable).

Initial research and scoping stages of all Agile projects – Discovery and

Alpha

Larger projects costing above £10 million

Smaller projects costing below £10 million

1. Apply to CO Spend Controls for Alpha and Discovery funding

2. Do Discovery and Alpha

3. Develop and write a project business case and/or input to a PBC (in parallel

with, and informed by, Discovery and Alpha)

4. Alpha digital service assessment

5. Apply to CO Spend Controls to release Beta funding

6. Beta and Live agile delivery

7. Digital service assessments

HM Treasury

GDSGDSMike Bracken

The tools for doing this are already in the open...

GDSGDSMike Bracken










Departments

Worldwide

Topics

Policies

Publications

Announcements


Government Digital Service

Listed below are our design principles and examples of how we’ve used them so far. These build on,and add to, our original 7 digital principles.

Start with needs*Do lessDesign with dataDo the hard work to make it simpleIterate. Then iterate again.Build for inclusionUnderstand contextBuild digital services, not websitesBe consistent, not uniformMake things open: it makes things better


© Crown copyright

GOV.UKLast updated 2 July 2012A L P H A

Design Principles

123456789

10

Hide examples

Start with needs**user needs not government needs

The design process must start with identifying and thinking about real userneeds. We should design around those — not around the way the ‘officialprocess’ is at the moment. We must understand those needs thoroughly —interrogating data, not just making assumptions — and we should rememberthat what users ask for is not always what they need.

We use ‘needs’ as an organising principle since people come to our sites to accomplish tasks and tofulfil needs, not just to hang out. Focusing on needs means we can concentrate on the things thatdeliver most value for money.

1

If we start from the wrong placethere’s no chance we will get thedesign right. Before we begin anyproject we spend a long timeworking out what the user needsare. This blog post explains a bitmore about how we do that.

Examples of how we start with needs. T R I E D & T E S T E D

This VAT page is a good example of a design that results from thinkingabout user needs. Most people will arrive at this page after a search forVAT rates. The answer most people are after is 20%, so we’ve made thatthe largest, clearest piece of information on the page. You can get theanswer you are looking for incredibly quickly. There is more to VAT thanjust one rate so we’ve included this but clearly designed as secondaryinformation. There’s a slim chance you’ve arrived at the wrong page sowe have links to genuinely related items in the box on the top right.

The page is simple and clear but contains all the different information youmight need.

Be clear T R I E D & T E S T E D

Show examples

Do lessGovernment should only do what only government can do. If someone else isdoing it — link to it. If we can provide resources (like APIs) that will help otherpeople build things — do that. We should concentrate on the irreducible core.

We’ll make better services and save more money by focusing resources where they’ll do the mostgood.

2

Show examples

Design with dataNormally, we’re not starting from scratch — users are already using ourservices. This means we can learn from real world behaviour. We should do this,but we should make sure we continue this into the build and developmentprocess — prototyping and testing with real users on the live web. We shouldunderstand the desire paths of how we are designing with data and use them inour designs.

This is the great advantage of digital services — we can watch and learn from user behaviour,shaping the system to fit what people naturally choose to do rather than bending them to a systemwe’ve invented.

3

Show examples

Do the hard work to make it simpleMaking something look simple is easy; making something simple to use is muchharder — especially when the underlying systems are complex — but that’swhat we should be doing.

With great power comes great responsibility — very often people have no choice but to use ourservices. If we don’t work hard to make them simple and usable we’re abusing that power, andwasting people’s time.

4

Show examples

Iterate. Then iterate again.The best way to build effective services is to start small and iterate wildly.Release Minimum Viable Products early, test them with real users, move fromAlpha to Beta to Launch adding features and refinements based on feedbackfrom real users.

Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. This avoidsthe 200 page spec document which can turn into a bottleneck. This, again, is the core advantage ofdigital: we’re not building bridges — things can be undone.

5

Show examples

Build for inclusionAccessible design is good design. We should build a product that’s as inclusive,legible and readable as possible. If we have to sacrifice elegance — so be it. Weshouldn’t be afraid of the obvious, shouldn’t try to reinvent web designconventions and should set expectations clearly.

We’re designing for the whole country — not just the ones who are used to using the web. In fact, thepeople who most need our services are often the people who find them hardest to use. If we thinkabout those people at the beginning we should make a better site for everyone.

6

Show examples

Understand contextWe’re not designing for a screen, we’re designing for people. We need to thinkhard about the context in which they’re using our services. Are they in a library?Are they on a phone? Are they only really familiar with Facebook? Have theynever used the web before?

We’re designing for a very diverse group of users with very different technologies and needs. Weneed to make sure we’ve understood the technological and practical circumstances in which ourservices are used. Otherwise we risk designing beautiful services that aren’t relevant to people’slives.

7

Show examples

Build digital services, not websitesOur service doesn’t begin and end at our website. It might start with a searchengine and end at the post office. We need to design for that, even if we can’tcontrol it. And we need to recognise that some day, before we know it, it’ll beabout different digital services again.

We shouldn’t be about websites, we should be about digital services. Right now, the best way todeliver digital services is via the web — but that might change, and sooner than we might expect.

8

Show examples

Be consistent, not uniformWherever possible we should use the same language and the same designpatterns — this helps people get familiar with our services. But, when this isn’tpossible, we should make sure our underlying approach is consistent. So ourusers will have a reasonable chance of guessing what they’re supposed to do.

This isn’t a straitjacket or a rule book. We can’t build great services by rote. We can’t imagine everyscenario and write rules for it. Every circumstance is different and should be addressed on its ownterms. What unites things, therefore, should be a consistent approach — one that users willhopefully come to understand and trust — even as we move into new digital spaces.

9

Show examples

Make things open: it makes things betterWe should share what we’re doing whenever we can. With colleagues, withusers, with the world. Share code, share designs, share ideas, share intentions,share failures. The more eyes there are on a service the better it gets — howlersget spotted, better alternatives get pointed out, the bar gets raised.

Partly because much of what we’re doing is only possible because of open source code and thegenerosity of the web design community. So we should pay that back. But mostly because moreopenness makes for better services — better understood and better scrutinised. If we give away ourcode, we’ll be repaid in better code. That’s why we’re giving away all this...

10

FeedbackThis is an alpha release of the principles and we would like your feedback. Is there anything youthink we should add that would make these principles more helpful? You can email your feedbackto [email protected].

All content is available under the Open Government Licence v2.0, except where otherwisestated

Search

GDSGDSwww.gov.uk/design-principles

http://www.gov.uk/design-principles


Digital by Default Service Standard Start using the manual Feedback

Government Service Design Manual

From April 2014, digital services from the

government must meet the new Digital by Default

Service Standard.

Read the standard »

Think differently about digital delivery

Discover what it means to be part of an agile, user-focused and

multidisciplinary team, delivering digital services in government.

Start building digital by default services

Making a service

Learn about the different phases of service design and get guidance

for the phase you're in now.

Discovery

A short phase, in which you start researching the needs of yourservice’s users, find out what you should be measuring, and exploretechnological or policy-related constraints.

Learn about the discovery phase

Alpha

A short phase in which you prototype solutions for your users needs.You’ll be testing with a small group of users or stakeholders, andgetting early feedback about the design of the service.

Learn about the alpha phase

Beta

You’re developing against the demands of a live environment,understanding how to build and scale while meeting user needs. You’llalso be releasing a version to test in public.

Learn about the beta phase

Live

The work doesn’t stop once your service is live. You’ll be iterativelyimproving your service, reacting to new needs and demands, andmeeting targets set during its development.

Learn about the live phase

Retirement

Even the best services may eventually reach retirement. That shouldbe treated with the same care as went into the building andmaintaining of that service.

Learn about the retirement phase

Service managers

Content designers

Designers

Developers

User researchers

Web operations

Performance analysts

Chief technology officers

Guides and resources for…

Browse all guides…










Worldwide

Policies

Announcements


Departments

Topics

Publications

Tell us what you think (opens a 3 minute survey on another website)


Build services so good that people prefer to use them


© Crown copyright

GOV.UK


Search the service manual

Digital by Default Service Standard Start using the manual Feedback


From April 2014, digital services from the

government must meet the new Digital by Default

Service Standard.

Read the standard »

Think differently about digital delivery

Discover what it means to be part of an agile, user-focused and

multidisciplinary team, delivering digital services in government.

Start building digital by default services

Making a service

Learn about the different phases of service design and get guidance

for the phase you're in now.

Discovery

A short phase, in which you start researching the needs of yourservice’s users, find out what you should be measuring, and exploretechnological or policy-related constraints.

Learn about the discovery phase

Alpha

A short phase in which you prototype solutions for your users needs.You’ll be testing with a small group of users or stakeholders, andgetting early feedback about the design of the service.

Learn about the alpha phase

Beta

You’re developing against the demands of a live environment,understanding how to build and scale while meeting user needs. You’llalso be releasing a version to test in public.

Learn about the beta phase

Live

The work doesn’t stop once your service is live. You’ll be iterativelyimproving your service, reacting to new needs and demands, andmeeting targets set during its development.

Learn about the live phase

Retirement

Even the best services may eventually reach retirement. That shouldbe treated with the same care as went into the building andmaintaining of that service.

Learn about the retirement phase

Service managers

Content designers

Designers

Developers

User researchers

Web operations

Performance analysts

Chief technology officers

Guides and resources for…

Browse all guides…










Worldwide

Policies

Announcements


Departments

Topics

Publications

Tell us what you think (opens a 3 minute survey on another website)


Build services so good that people prefer to use them


© Crown copyright

GOV.UK


Search the service manual

GDSGDSwww.gov.uk/service-manual

http://www.gov.uk/service-manual


Log in Create an accountDigital Services Store B E T A

BETA: This is a trial service - your feedback will help us to improve it. Find out more

Find out more

The Digital Services Store is where central government, local authorities,

devolved administrations, arm’s length bodies and the wider public sector

bodies can commission suppliers to work in an agile way on digital projects

via the Digital Services framework.

Buyers will be able to either contract with suppliers for individual roles to

join their existing digital teams, or create entire digital teams to work on a

project.

The Digital Services framework suppliers have been technically and

commercially evaluated to provide a comprehensive choice for agile

projects.

You have to register as a buyer to explore the suppliers listed. Registered

buyers can save their searches and be able to demonstrate a clear,

accountable audit trail, including searches conducted, filters applied and

evaluation taken while making your selection.

For more information about building digital services in an agile

environment, please consult the Service Design Manual and the Buyer’s

guide. For help with technical and commercial approach or running a

further competition contact [email protected].

What is the digital services

framework?

What can I buy?

How can I buy?

Explore the store

Please note you will need to log in.

The place to find digital service design and development companies who work in an agile way

About Digital Services Framework

Learn about the Digital Services

Framework and how to use this store

Read Our Blog

Buyers

Read a detailed buyers guide on how to

buy services using this store

Suppliers

Edit Company Information

Find out how to apply to supply services in

this store

Privacy Policy Cookies Accessibility Copyright

All content is available under the Open Government Licence, except where otherwise stated© Crown Copyright

GDSwww.digitalservicesstore.service.gov.uk

http://www.digitalservicesstore.service.gov.uk


Governance has been simplified too...

GDSGDSMike Bracken

New modelMission IT

(Technology Leaders)

Back Office(Next Gen.

Shared services)

Common Infrastructure

Services(Technology

Leaders)

Digital PublicServices

(Digital Leaders)

GDSMike Bracken

Performance ALPHA

Performance










Worldwide

Policies

Announcements


Departments

Topics

Publications

Performance

Activity on GOV.UKWeb traffic on our site, based on data from Google Analytics.



© Crown copyright

GOV.UK

13022users online now

Live service usageNumber of users currently on GOV.UK

Table view of “Live service usage” data Users over past 24 hours0

40k

0

40k

Site trafficUnique visitors to GOV.UK over the past year, compared with the previous year

Table view of “Site traffic” data

GOV.UK

GOV.UK(52 weeks ago)

Directgov(52 weeks ago)Business Link(52 weeks ago)

June July Aug Sep Oct Nov Dec Jan 2014 Feb Mar Apr

0

2m

4m

6m

8m

10m

1

2

3

4

5

6

7

8

9

10

Top contentMost pageviews in past 7 days

Find a job with Universal Jobmatch

Car tax: get a tax disc for your vehicle

UK bank holidays

Check if you need a UK visa

State Pension calculator

Student finance login

Visas and immigration

Driving and transport

Renew or replace your adult passport

Overseas British passport applications

1

2

3

4

5

6

7

8

9

10

Trending contentLargest percentage increase in pageviews week-on-week

HM Revenue & Customs contacts

Tier 4 (General) student visa

Entering the UK

TV Licence

Teaching schools: a guide for potential applicants - Detailed gu…

National scholarships for teachers and SEND support staff - De…

How to renew tax credits

Donate to charity

DVSA practical test business service

Complain about a further education college or apprenticeship

1

2

3

4

5

6

7

8

9

10

Top policiesMost pageviews in past 7 days

Early years foundation stage - Improving the quality and range …

Securing borders and reducing immigration

Renewable Heat Incentive (RHI) - Increasing the use of low-car…

Reducing obesity and improving diet

The United Nations Convention on the Rights of the Child (UN…

Making the State Pension simpler and fairer

Introducing Personal Independence Payment - Simplifying the …

Giving all children a healthy start in life

Creating a fairer and more equal society

PE and sport premium for primary schools - Getting more peopl…

1

2

3

4

5

6

7

8

9

10

Top announcementsMost pageviews in past 7 days

New international enquiry service for visa applications

Vehicle tax changes

Immigration fees: 2014 to 2015

£7600 to make your home more energy efficient

One million set to benefit from National Minimum Wage rise to…

Universal Credit: First year of welfare transformation and nort…

Help to Work: nationwide drive to help the long-term unemplo…

New scholarships for teachers and SEN support staff

Direct Debit and abolition of the tax disc

New rules when renewing your tax disc

How people access GOV.UKBreakdown of desktop, mobile and tablet usage on GOV.UK over time

Table view of “How people access GOV.UK” data

Total100% (364m)

last 52 weeks

Desktop69% (250m)

Mobile20% (73.6m)

Tablet11% (40.4m)

June July Aug Sep Oct Nov Dec Jan 2014 Feb Mar Apr

0%

20%

40%

60%

80%

100%

30 days 24 hours

Service availability

0.61smean for the last 30 days

100%for the last 30 days

Page load time

Table view of “30 days” data

Uptime

Table view of “30 days” data

7 Apr 14 Apr 21 Apr 28 Apr 5 May

0s

0.5s

1s

7 Apr 14 Apr 21 Apr 28 Apr 5 May

0%

50%

100%


GDSMike Bracken

GOV.UK blogs use cookies to make the site simpler. Find out more about cookies

Blog


When to use caps

around GOV.UK

Why do we write GOV.UK incapitals? And why is the URLwritten lower-case? You maywell have heard the reasons,but we’ve never actuallywritten them down. Let’s fixthat now.

Read more

Nextpage

2 of 55

Just doodling: telling the story with a few pen strokes

Giles Turnbull, 30 April 2014 — GDS team

One thing visitors to the GDS office can’t help noticing is the colourfulselection of cartoons and doodles stuck on the walls.

Read more — 1 comment

Weekend links: hackathons, time travel, glow-in-the-

dark motorways and more

Carrie Barclay, 26 April 2014 — Weekend links

Got a link you think we’ll like? Share it with us on Twitter – @gdsteam

Read more — 0 comments

User needs and revolutions

Padma Gillen, 23 April 2014 — Style, content and design

In 2010, Martha Lane Fox (the UK’s Digital Champion at the time) completedher review of the government’s web offering.


Weekend links: Next Generation Testing, UK Trade

and Investment, and more


Found a link you think we’ll like? Share it with us on Twitter – @gdsteam


GOV.UK hosting – simpler, clearer, faster

Carrie Barclay, 17 April 2014 — GOV.UK

Recently the Government Digital Service’s infrastructure team movedGOV.UK to a new hosting platform. Find out what happened …


Digital Inclusion Strategy launches today

Kathy Settle, 14 April 2014 — Digital inclusion

Last December, we published action 15 of the Government Digital Strategy toshow the government’s commitment to digital inclusion.


Getting approval for agile spending

David Wilks, 11 April 2014 — Uncategorized

Today, GDS and HM Treasury publish new clarification of business caseguidance. We needed to explain how government organisations getpermission to spend money on agile work.


The Performance Platform: open for business

Richard Sargeant, 7 April 2014 — Measurement and analytics

The Performance Platform is a tool for government to answer the question‘how are we doing?’. At present, the important facts are not accessible to theright people, at the right time, in the right way.


Weekend links: Environment Agency blog, weeknotes,

interning at FCO and more

Kim Townend, 5 April 2014 — Weekend links

If you find a link you think we’d like, message us @GDSTeam Take a look atthe recently launched Environment Agency blog. Learn about workexperience opportunities at the Foreign & Commonwealth Office. TheNational Archives just added more sections to their beta …


Digital marches on: rising take-up, falling costs

Richard Sargeant, 2 April 2014 — Digital strategy, Measurement and analytics

The Transactions Explorer has enabled government to track progress on itskey performance indicators for the first time.



The Government Digital Service(GDS) is leading the digitaltransformation of government.Find out more.

What we do

Select Category

GDS on Twitter

Watch this video from the GDS video archive: "user-centred design and developing e-commerce" bit.ly/1rsFg0F

GDS @gdsteam

Show Media

Ever wondered why we use caps when talking about GOV.UK? Read this: bit.ly/1rRvPIo

GDS @gdsteam

Expand

GDS

1 May

1 May

Tweets FollowFollow

Tweet to @gdsteam

Work for us

Current vacancies at GDSWe're looking for technicalanalysts, performance managersand more...

Follow @UKGovDigiJobs

Comments and moderation policy

Read our guidelines

All GOV.UK blogs GOV.UK All departments All topics All policies Cookies

© Crown copyright

GOV.UK

Search blog

Organisations: Cabinet Office, Government Digital Service

Topics: Government efficiency, transparency and accountability atom email alerts


GOV.UK blogs use cookies to make the site simpler. Find out more about cookies

Blog


When to use caps

around GOV.UK

Why do we write GOV.UK incapitals? And why is the URLwritten lower-case? You maywell have heard the reasons,but we’ve never actuallywritten them down. Let’s fixthat now.

Read more

Nextpage

2 of 55

Just doodling: telling the story with a few pen strokes

Giles Turnbull, 30 April 2014 — GDS team

One thing visitors to the GDS office can’t help noticing is the colourfulselection of cartoons and doodles stuck on the walls.


Weekend links: hackathons, time travel, glow-in-the-

dark motorways and more


Got a link you think we’ll like? Share it with us on Twitter – @gdsteam


User needs and revolutions

Padma Gillen, 23 April 2014 — Style, content and design

In 2010, Martha Lane Fox (the UK’s Digital Champion at the time) completedher review of the government’s web offering.


Weekend links: Next Generation Testing, UK Trade

and Investment, and more


Found a link you think we’ll like? Share it with us on Twitter – @gdsteam


GOV.UK hosting – simpler, clearer, faster

Carrie Barclay, 17 April 2014 — GOV.UK

Recently the Government Digital Service’s infrastructure team movedGOV.UK to a new hosting platform. Find out what happened …


Digital Inclusion Strategy launches today

Kathy Settle, 14 April 2014 — Digital inclusion

Last December, we published action 15 of the Government Digital Strategy toshow the government’s commitment to digital inclusion.


Getting approval for agile spending

David Wilks, 11 April 2014 — Uncategorized

Today, GDS and HM Treasury publish new clarification of business caseguidance. We needed to explain how government organisations getpermission to spend money on agile work.


The Performance Platform: open for business

Richard Sargeant, 7 April 2014 — Measurement and analytics

The Performance Platform is a tool for government to answer the question‘how are we doing?’. At present, the important facts are not accessible to theright people, at the right time, in the right way.


Weekend links: Environment Agency blog, weeknotes,

interning at FCO and more

Kim Townend, 5 April 2014 — Weekend links

If you find a link you think we’d like, message us @GDSTeam Take a look atthe recently launched Environment Agency blog. Learn about workexperience opportunities at the Foreign & Commonwealth Office. TheNational Archives just added more sections to their beta …


Digital marches on: rising take-up, falling costs

Richard Sargeant, 2 April 2014 — Digital strategy, Measurement and analytics

The Transactions Explorer has enabled government to track progress on itskey performance indicators for the first time.



The Government Digital Service(GDS) is leading the digitaltransformation of government.Find out more.

What we do

Select Category

GDS on Twitter

Watch this video from the GDS video archive: "user-centred design and developing e-commerce" bit.ly/1rsFg0F

GDS @gdsteam

Show Media

Ever wondered why we use caps when talking about GOV.UK? Read this: bit.ly/1rRvPIo

GDS @gdsteam

Expand

GDS

1 May

1 May

Tweets FollowFollow

Tweet to @gdsteam

Work for us

Current vacancies at GDSWe're looking for technicalanalysts, performance managersand more...

Follow @UKGovDigiJobs

Comments and moderation policy

Read our guidelines

All GOV.UK blogs GOV.UK All departments All topics All policies Cookies

© Crown copyright

GOV.UK

Search blog

Organisations: Cabinet Office, Government Digital Service

Topics: Government efficiency, transparency and accountability atom email alerts


GDSGDSgds.blog.gov.uk

www.gov.ukwww.gov.uk/design-principleswww.gov.uk/service-manualwww.gov.uk/performancewww.digitalservicesstore.service.gov.ukgds.blog.gov.uk

GDSGDSMike Bracken







http://www.gov.uk/performance

http://www.gov.uk/performance



Operational delivery mike bracken

Government & Nonprofit

Transcript of Operational delivery mike bracken