In support of the Local Digital Declaration

At Hackney we are working hard to provide our residents with digital services that are so good, people prefer to use them. By harnessing the power of digital technology, data and service design it is now easier than ever before for Hackney residents to check their rent accounts quickly from their mobile phone, get support to find opportunities for employment and skills development, access the Council’s help to reduce the risk of homelessness, and find opportunities to provide a foster home for a child.

This is just the start and there is much more that we want to do. We believe firmly in working with our residents to co-design our new digital services and we also believe in the importance of working collaboratively with our colleagues in other councils so that we can share the benefits of each other’s work and deliver progress together more quickly and at lower cost.

Much has been written and said about how digital collaboration in local government should be done. Suggested solutions range from formal shared services, where councils come together through joint structures, through to less formal joint working across councils based on identifying shared opportunities. The challenge is to make sure that we can continue to respond to local needs, minimise bureaucracy and set a clear and purposeful direction that will deliver at pace over the medium and long term.

We welcome the new Local Digital Declaration (http://www.localdigital.gov.uk/declaration) and we believe that this sets out principles that are consistent with our values in Hackney.  We are pleased that this is being developed in partnership with councils across the country, not imposed from Whitehall; we support the focus on service design, digital skills and the underlying technology foundations that need to be in place; and we share the commitment to open and collaborative working across the sector so that we can learn from one another.

We also calling on our current and future suppliers to commit to the principles in the Declaration. From our experience in Hackney we have seen how working with innovative digital suppliers can help us deliver exceptional results and we know that their expertise can also help us develop our in-house skills for the longer term. We need to work with suppliers who will adopt the best of modern digital technology, commit to open standards and can demonstrate their ability to deliver services of the standard that our residents rightly expect. You can read our open letter to suppliers here: http://hackit.org.uk/work-with-us/suppliers/an-open-letter-to-suppliers.

We are looking forward to playing a full role as part of the local government digital community to help realise the vision set out in the Declaration and we are confident that this will benefit our residents in Hackney as well as citizens in other areas of the country.

The Mayor of Hackney sets out our commitment in this video:

Developing our API strategy

TL;DR

One of the decisions at last week’s ICT management meeting was to confirm our commitment to an API strategy:

  • Ensuring that all of our key datasets are available via a REST API so good, that people prefer to use it
  • Replacing existing connects with REST APIs that can be used independently of each other
  • Developing our skills to ensure we can use the modern programming languages, development techniques, tools and services necessary to deliver high quality services
  • Developing our cloud-first approach, ensuring we’ve got a sustainable digital architecture that supports continuous deployment and continuous integration
  • Ensuring our code remains secure but is open source

Background

Last year, we were considering options for renewing our CRM. We reviewed the CRM market and also experimented with lowcode and, in particular, Outsystems which seemed to be the best on the market. We built Pay My Rent in just 12 weeks using Outsystems, connected to data in Dynamics, and it’s been working well ever since.

However, when we began developing the housing repairs service, we found that lowcode was a barrier to working with suppliers. They would have to spend time learning lowcode. Most of our suppliers were expert in Ruby on Rails, a modern, lightweight programming language – but not one we knew. We also learnt that whilst lowcode helped us develop apps quickly, we were still reliant on data in legacy systems for managing the end-to-end journey.

We also learnt that if we connected new services to legacy systems using the integrations we used to write (SOAP webservices and direct database connections) then we would have to re-write them when we were ready to migrate from Universal Housing. So we experimented with developing a REST API to support online repairs. Previously we would have built an integration that put data directly into the database, which:

  • Would be hosted on-premise (for security) so unusable to anyone outside Hackney
  • Was impossible to monitor availability in realtime – so we’d have found out it was broken when part of the service failed
  • Could not be re-used, and would have had to have been re-written if either the application or the database changed

We called this work a ‘prototype’ because there were a number of questions we couldn’t yet answer:

  • Did we have sufficient skills in the team to write REST APIs?
  • What were the benefits of writing REST APIs?
  • Could our existing technology support an API-driven approach?
  • Could we get the best from existing software (lowcode, CRM) whilst increasing our capacity by working with local agencies?

Over the last six months we have been trying to answer these questions.

Work to date

We deployed the ‘Hackney API’ that enabled repairs, and started adding more data to it. It was underpinned by a draft set of standards so that we could develop future APIs to a consistent format.

The API was hosted on-premise as a short-term workaround, and the code was on a private repository of GitHub initially. We then re-wrote (‘refactored’ in the jargon) the API to individual APIs that work independently of each other. That means changes to code won’t create problems in other parts of the API and enable us to continuously develop the services.  

The development team has made a strong start in developing their skills. We began by co-locating our developers with partners in agencies. We got some great feedback from our agencies about the speed with which our devs learnt.

The NHO team adopted the API-based approach and began developing a more flexible approach so that they could better meet user needs. The team, and the income collection team were both able to benefit from the API built for Pay My Rent, because they’re using the same data. So they developed the idea of a suite of APIs that could be used by any team.

Our emerging standards were adopted by the Business Index team.

We’ve also shown that we can build APIs on our own. Sachin, Sandrine and Tapan, working with Tejus developed a suite of APIs to support the LLPG.

What we’ve learnt

Writing great APIs demands we use a range of techniques to improve the way we write code. Pair programming, test-driven development and coding in the open are all important attributes of writing great code and therefore making our APIs reusable outside Hackney.

Our developers are learning a lot, but need help, support and time to increase their skills. There are too many demands on their time, so we need to get better at prioritising what they do.

You can’t just deploy cloud-based applications which seamlessly connected to on-premise, legacy systems. And you can’t publish open source code that’s reusable if you haven’t got the security sorted out.

There are lots of tools that can help us – from Platform as a Service such as Heroku to software tools such as Swagger, for documenting APIs, and TeamCity/Circle CI for continuous integration. However, none of these are shortcuts to writing good code.

We need to be able to continuously deploy code, ensuring it works and connects seamlessly to our systems and infrastructure. Our change control process enables this, but we’ve got more to do to support reliable, secure access between cloud software and our legacy applications.

 

What we will do now

We’re making a clear commitment to an API-based approach. We believe it will:

  • Enable us to re-use data and connections as we develop more digital services
  • Provide the potential for third party applications to connect to our data and (potentially) us to use more third party apps and services
  • Reduce our dependency on large systems and reduce the risks of switching between applications
  • Increase the visibility of integrations between systems, reducing the costs of support and maintenance
  • Improve the security of our systems by having a secure OAUTH system in place

However, we recognise that this won’t be straightforward. We’ll need to:

  • Work closer together, ensuring our digital design team, developers, architects, infrastructure and data teams can all contribute to the approach
  • Support colleagues in their continued learning and development
  • Learn from experts to ensure that our API products are high quality
  • Track our capacity to ensure that new services are improved continuously but that our legacy applications continue to be well-supported
  • Track the cost and benefits of this approach to ensure it delivers a better IT service for residents, businesses and colleagues

We’re already working with MadeTech to provide support and challenge for our API strategy. We’ll now be drawing on a range of experts to support the whole team in understanding best practice. We want to increase the number of opportunities available for people to learn coding – whether through our new learning platform, secondments into the team or secondments into projects to develop new services. And we need to work harder to open up our work, so that we:

  • gain from other people’s wisdom (their input can help improve the quality of our code) either indirectly, or through recruitment
  • make a valuable contribution across local government by helping other authorities who are starting out on a similar journey / don’t have the resources that we do play a part in resetting the local government digital landscape, helping the sector to unlock itself from the traditional oligopoly

There’s a lot to do – but the opportunity has never been greater. We’re in a unique position in Hackney to make this work.

Delivering digital change for the long term with apprenticeships

We’ve been thinking hard about how we can best make sure that we have the skills that we need to help Hackney continue to improve the services we provide for our residents and businesses.

Having an in-house ICT and digital team means that we can be lower cost, more agile and service focused, and can avoid wasting time on contract change controls when we need to respond to the changing environment we work in. But to make this work well it’s critical that we invest in our people’s skills and learning, and that we plan for the longer term. We are also acutely aware of the importance of encouraging more diversity in the technology sector and see ourselves as having an important role to play in that.

Part of this is putting in place well thought out training opportunities for our teams, including having our people work alongside the expert agencies who are helping us deliver a wide range of exciting projects so that we can learn from them. Getting our training approach right is a priority for us and something we have committed to as part of the restructure that we completed recently.

Another key component of our workforce strategy is using apprenticeships to bring in our next generation of skilled people. We also think this will help us to keep our thinking fresh across the whole service by bringing in new ideas and understanding.

Hackney have had a long standing commitment to offering apprentice and trainee opportunities and we are building on this by taking advantage of the opportunity presented by the apprenticeship levy. We’ve now created 18 new ICT and digital apprenticeships (based on level 3 and level 4 accredited apprenticeship qualifications) across a range of roles covering:

  • Applications management
  • Data analysis
  • Development and integration
  • Digital service design
  • ICT infrastructure engineering
  • ICT support

This represents more than 10% of the posts in our team and we think that this will be a really big step forward for us. We start the recruitment to these roles on Monday 18 June and we expect to have our apprentices joining our team after the summer holidays.

Doing this in Hackney is particularly exciting. The borough’s schools have had an amazing transformation and now count among the best in the country. This gives us a great pool of local talent and skill to draw on and we hope that having the opportunity to contribute to improvements in their local borough will be something that makes our roles an attractive proposition for local young people.

Hackney also has a thriving tech sector with world leading business (large and small) based in the borough. On Monday 11 June we invited local employers to meet with us and discuss their ideas for ways that we can make our apprenticeships a success. Lots of really good suggestions were put forward, including:

  • Making sure that apprentices are given specific projects to deliver so that they can build their own personal portfolios of experience
  • Supporting our managers with the skills they will need to manage people who are at an early stage of their careers and have limited experience of the workplace
  • And also a willingness to work together in future to share ideas and look for further opportunities for us to work together

We’re really looking forward to getting our digital apprenticeship programme started and working to deliver great results for the apprentices and for Hackney as a whole.

An open data standard for planning applications?

We’re working to find out what a digital planning application service would look like if it were “so good, people prefer to use it”. However, one of the early things we learnt was that high quality data is the key enabler of providing a better digital service. 

We need to ensure our work on planning applications considers the opportunity for an open data standard, so that multiple authorities can benefit. Such a standard could support working across multiple planning authorities, e.g. for applications on borough boundaries. It could support interoperability within a future digital planning ecosystem, including front and back-end systems, centralised portals and registers.

To that end Hackney convened a session with colleagues from MHCLG, iStand UK, Future Cities Catapult and the GLA, to help us explore the idea of such a standard.

We (SB and TP) attended as members of the Data & Insight Team at Hackney, with an interest in the development and use of open data standards. Here’s an outline of what we learned…

Scope of the problem

Building a domain model is complex because of the interrelationship of policy, application types, land types, and different stages of decision-making.

Different planning authorities have different processes and timeframes, using different terminology, as well as different technology (for some insight on the fragmentation among local planning authorities, see Molly Strauss’ account of the GLA’s ongoing efforts to improve London-wide planning data). Some issues are only relevant in certain areas (e.g. radon gas).

In addition, much planning application information is contained within unstructured documents. In the digital planning portal, used by a large proportion of applicants, data is often entered into free text fields without validation against definitive registers. It is hard to tell how much of this content could become formalised and we must expect that some of it will remain unstructured. Similarly, much of what goes into planning decisions isn’t exposed as data yet (for example, local plan policies are not always rendered into spatial data).

Previous related efforts

We heard about efforts to consolidate data across local planning authorities. This seems to have been focussed on publishing unified planning application registers for counties including Hampshire and Surrey, via planning “hubs”. Among the challenges mentioned were:

  • Authorities using the same planning management software, but in different ways.
  • Difficulties agreeing on nomenclature.
  • Licensing restrictions, e.g. Surrey provides an API licensed only “for non-commercial and personal use” apparently due to use of Ordnance Survey “derived data”.

See the LGA schema produced as a result of this work.

Methodology

We were reminded that a sustainable open data standard is more likely to emerge if we follow a few general rules:  

  • Start small. We should aim for a compact standard that could be extended later, following the ‘plugins’ approach of Open Source projects.  
  • Allow a lot of time. The standard should emerge from the model, not the opposite. It is also dangerous to pursue a definitive standard too early: when it starts being adopted, it becomes harder to change it.
  • Involve the right stakeholders. A standard is more ‘believable’ if it has been shaped by many diverse stakeholders, including from government entities. If not, it is likely to be reflecting the needs and culture of a limited group.
  • Plan for governance: in order to last and evolve, a standard needs a proper governance structure, led by a credible entity and offering a channel for stakeholders to propose changes.

What’s next?

Work on a minimum viable product for a digital planning service is about to start, involving the partner boroughs and Snook and Hactar. Using the advice outlined above, the aim will be to keep the data model as lightweight, high-level and open as possible, so it can be a good candidate for evolving into a standard.

This will only happen with input from a range of people with different perspectives. Hackney Digital Team would love to hear your ideas and learn about similar initiatives.

By Sandrine Balley and Tapan Perkins

How are we protecting the data and privacy of our residents and staff?

The closer we get to 25 May, the more emails I receive reminding me that the General Data Protection Regulation (GDPR) is coming soon. Some of these give the sense that the changes to our data protection laws will be apocalyptic and many of them don’t actually seem to have understood the new regulations at all! This is made slightly more dramatic by the uncertainty about when the UK’s new Data Protection Bill will actually be passed into law (so we can’t be 100% certain what the requirements will be – although we do have a good idea).

At Hackney we have been reminding ourselves that the fundamental principles of data protection remain the same – we need to look after the data and privacy of our citizens and employees and we need to make sure that we are using data in ways that are consistent with our legal obligations for delivering services to the borough’s residents and businesses.

Part of the change in the law is to increase transparency – making sure you know what we are doing with your data and what your rights are. And in line with the principle of transparency we are working in the open, so that others can benefit from the investment we’re making in complying with the new law if it would be useful to them.

If you’re a business then you’re likely to find that the exact details of work you need to do to comply with the GDPR will vary depending on the type of organisation you are and the types of data you hold, this summary might provide some useful pointers for your own compliance planning.

In summary, the work we’re doing covers the following areas:

  • Our training is designed for anyone we have reviewed & refreshed our data protection and information security training. We are working with local agency, Helpful Digital, to develop an online ‘Data Awareness Training’ tool. There is a basic level for those handling data, and an intermediate level for those making decisions about data. We’ll be sharing this, so that any other organisation can use it (a community volunteer that maintains a list of other volunteers, for example).
  • Information Asset Register – we’re building a register of what information we have, where it is, what controls are around it, who is accountable for it, where we got it from, who we share it with and what our lawful basis for processing it is. That will make it easier to respond to requests and ensure we’re complying with the law. We have been fortunate that the Local Government Association has made a ‘Record of Processing Activity’ tool available through their LG Inform Plus subscription service which we are using to help us build our register. This details all local government activities with the recommended lawful basis for processing and the underpinning legislation that relates to the power or duty (where it’s indicated that data is processed due to a legal obligation or public task).
  • Policieswe have refreshed our policies that relate to information management and security. Just as we are sharing products we are creating, we are also using good work of other organisations where permitted. In this case we based our new policies on those of other councils, saving Hackney time and money. These updated policies are clear and concise, and will have supporting technical standards and guidance.
  • Retention & disposalexisting data protection law already requires that we only keep data for the time that we need it for the purpose it was collected for. This doesn’t change with the new law, but we do need to tell individuals how long it will be kept for when we collect it from them. We have also been hard at work reviewing our older data archives and have made some policy decisions about email, have been reviewing the paper records that we store and plan to dispose of historic data that is no longer needed over the coming year. As part of this review work, we’ve been working with our colleagues in the Hackney Archives to make sure that any important archive records are retained for future use.
  • Privacy noticesthe new law extends individuals’ right to be informed, and we are now required to provide a large amount of additional information when we ask for data explaining why we need it and how it will be used and stored. We are following the guidance from the Information Commissioner’s Office to take a ‘layered’ approach. This means that we will provide be a short summary paragraph in Plain English at the time that we ask for the data (eg when someone completes a form) and this will point to a more detailed notice on the Hackney Council website, with additional detail for each service. We will be sharing these in an online document, licensed under Open Government Licence, so that they can be reused by others, free of charge.
  • Identity Managementwe have been exploring how we can minimise the number of times that we ask for ID documents from residents across multiple services through using technology that can simplify managing identity. This would not only save us money by avoiding the need to repeat steps across different services but would also make it easier for citizens to access services without having to prove who they are every time that they use a new service. We’re working together with the Government Digital Service and Tower Hamlets to see if there is potential to use the GOV.UK Verify service to achieve this.

Different organisations will need to take different steps, depending on what data they have and how they have managed it previously. We hope that by sharing details of the work we’re doing, by working in partnership with others and making our work open it will help you understand what the GDPR involves and help other organisations with their own preparations.

If you run a business or other organisation / group that processes personal data then we’d recommend you take a look at the information that the Information Commissioner’s Office have provided online https://ico.org.uk/for-organisations/business/. You can also contact their helpline which is able to offer advice if needed: https://ico.org.uk/global/contact-us/helpline/. You may also find this cyber security guidance from the National Cyber Security Centre useful https://www.ncsc.gov.uk/smallbusiness.

People first: managers are users too!

I thought I would share some learning from the Income Collection Service transformation project which seeks to build a new service to improve how Hackney collects arrears owed.

What did we learn this week?
In our most recent project review (retrospective), the project team took a moment to ask how we were doing against the HACKIT Manifesto . We decided we weren’t doing enough to engage the ‘wider team’ (i.e. including our stakeholders). As it turned out, the Income Collection Team Managers agreed.

[Warning: jargon] Experienced lean UX-ers and agil-ers only
When we are experienced at working in modern agile teams, its easy to brush over how quickly our colleagues can learn our process. Despite how many times we may explain it, it only becomes alive when someone participates and feels the benefit. It’s easy to forget to bring people along with your work when you are under a lot of time pressure to get things done. As it turned out, despite being through a 4-week DISCOVERY that was faithful to our process, the feedback was that we had not done enough to engage the Income Collection Team Managers. They didn’t yet trust us or our approach! {Shock}.

Single-minded focus on users
During DISCOVERY there is a lot we need to learn and do in a short period of time. As with most user-centred design approaches, the team was focused on understanding our users as quickly as possible. However, this meant we prioritised talking to income collection caseworkers and residents over team managers in the first 4 weeks of our project. While user-centred service design is crucial to our success, we had mistakenly de-prioritised our engagement with the managers of case workers who we realised later were a group of users in their own right.

Smell of success
The hallmark of success (and central to our manifesto) is recognising our failure quickly and doing something to correct our course. What we were most glad about was that our stakeholders were sufficiently enough engaged to actually tell us they were not happy.

A little less talk, a little more action…satisfaction guaranteed…
As though perfectly on cue, the same week we recognised the oversight, we started to work on paper design prototypes of the new service screens. Whereas we may have previously focused on workshopping those prototypes directly with caseworkers, the team agreed we should immediately validate the prototypes with Income Collection Managers, as well. As soon as they saw what we were planning (what was in our collective heads), our relationship completely changed. Within a day and with a small pivot, we had changed the culture of the project.

Show-and-tells are not enough
We have now agreed with Income Collection Managers to reserve an open weekly ‘working session’ for an hour around the HSC 4th floor ICT standing tables. This helps us optimise our time together and we can use the session for anything from user testing to workshopping the arrears prediction algorithm to demonstrating what we are currently building for immediate feedback. The Income Collection Team Managers are also happy they have a weekly touch point with us outside the show-and-tell.

We have also agreed with the Income Collection Managers on a nominated group of case-workers who they can keep in touch with and who we can engage in the regular weekly session. This was so crucial to us because we know user testing is vital to ensure we are building the ‘right thing’.

The manifesto is alive!
We have immediately felt the benefit of holding ourselves accountable to the HACKIT Manifesto with a practical check-in during our retrospective. Maybe it was a little hard to admit we weren’t putting a key group of stakeholders the centre of our process (people first!), but we have definitely felt the benefit of making changes so we do.

 

Standing on the shoulders of giants

Hackney Council is prototyping an API-centric digital architecture.  The HackIT manifesto tells us to ‘learn more’ by  it was important for us to learn from experts who has successfully implemented a WebAPI in a government environment on a larger scale.  So HMRC was the best candidate to visit and provide our developers with a unique opportunity to learn from the experts.

The visit to the HMRC office, based at Shipley was really useful and gave us a deep understanding of how they implemented and maintain their API platform.  The team took us through their development journey for their API platform and provided us with insightful information to support us on our journey.

The journey of the API-centric development at HMRC has started in January 2015 with the involvement of 3 teams initially.  After 4 months of recruiting people with the right skills, they have started their API development, taking 2 years to publish the first public APIs. The most requested API was from taxpayers for self-assessment module. The team had SMEs and contract developers to deliver the first set of APIs and gradually the team expanded based on user needs.

Key things learned from this visit:

  1.     Overall Technical Architecture: HMRC has an in-house developed application which monitors the ongoing management of subscription, authentication, authorization and metrics processing for requests coming via client requests. In retrospect, they mentioned that it would have been better to go with the external vendor instead of building the in-house application which resulted in additional efforts to support it. However, they also explained the reason for using this approach to avoid vendor lock-in. Adopting a similar strategy would be very beneficial for Hackney to be able to monitor and maintain the WebAPI efficiently.  They also use multiple level of abstractions in their infrastructure, such as proxy servers, gateways etc in order to make the API secure.Most of their infrastructure is hosted on AWS.

This inspires us to revisit our API architecture and create layers of abstraction before deploying our API public so that it is not subjected to vulnerabilities.  It also prompts us to begin thinking about how we can host our API platform in the cloud. There will be some challenges around connectivity to our back-office systems, but products such as Direct Connect offered by AWS do give evidence that this hybrid platform is a viable solution.

It is also noted that they follow the DevOps approach for service delivery whereby one or two infrastructure staff are included in development teams for API delivery. This is a brilliant concept of having a platform team heavily involved in the Continuous integration of the WebAPI.

  1.     Product management and understanding user needs:

Even though they develop APIs, they still follow a user-centered approach for development, where the client developers are considered to be their users.  This extends their API-First approach where the endpoints are developed to meet user needs and not around the workings of back-office systems.

This approach makes us think “are we going in  the right direction when it comes to WebAPI?”. We believe, adopting a similar “API First” approach where we develop our end-points to the users (developers) would be beneficial to create a flexible, standardized WebAPI.

They have design clinics every month for introducing and discussing design principles and they often hold Hackathons, inviting external developers to work with their API as part of their user research. This is something we are currently doing as part of Show and Tells however we can expand this on a wider scale by inviting external agencies who are interested in our Web API.

  1.     Skills and Capabilities: Any skills not available internally are outsourced.  These skills are then introduced and shared within and among teams; this way skills are retained. As mentioned earlier there was a sense of having clear standards set up and it was embedded within the team by having the same taxonomy followed throughout.  We have adopted a similar approach of working with external companies but could do more around the transfer of knowledge and skills, possibly by highlighting key new skills in project retrospectives.
  2.     API Service Standards: They also mentioned that they are building their own API standards which based on GDS standards. The standards have been gone through a well-thought process with a lot of scrutiny in place and consultation with various teams including Technical architects and Enterprise architects. There is a separate team for API Standards and Assurance who is responsible to review the changes in the API and also make sure it follows the standards they have set in. This well embedded process itself is something we are lacking on. We are currently working on our own Hackney Development Standards which will ensure that same taxonomy is followed throughout our API and new developers coming on board can easily understand it.

In all, it was truly a well-spent day with HMRC API team with so much to take on board since they have a massive API implementation. We did realize that it would have added even more value if we were to invite our platform colleagues along with us to get more information on their infrastructure; maybe next time.

 

Assessing a service against the Standard

We’ve just launched a private beta of a new service with a small pilot team. The service will enable our neighbourhood housing officers to work in a more mobile way. So now seemed a good time to do an internal assessment of how well our design and development of the service measured up against the local government digital service standard.

To do this we worked in groups of 3 or 4 with a mixture of roles: UX researchers and designers, developers, and project management roles. Some were involved in the development of the new service and others were not. Each group assessed different points of the standard and then we came together with the Head of Digital to share our assessment.

What we found

Working as an Agile multidisciplinary team with a product owner who’s able to make decisions and prioritise user stories, has enabled us to iteratively improve the product based on user needs from our user research and feedback from testing with users.

Rotating ‘show and tells’ at the users’ local offices has helped build the profile of the product and contributed to users understanding of it before the launch of private beta with a pilot team. This has contributed to the building of a simple and intuitive product and reduced training time to use it. User feedback suggests it is a clear improvement on their previous mobile working tools and the pilot team are engaged and eager to use it.

Our developers have a clear understanding of the tools and systems they use, they’ve reused existing components where possible and made code available for others through Github as well as meeting internal standards on data management.

The new product provides improved data capturing, more monitoring capability and improvements on data security than previously.

However, we need to show greater clarity on how the the product has been iterated based on user research findings and no specific research has been done on assisted digital user needs.

On project management, risks need to be identified and reported more clearly and user stories need to have defined acceptance criteria that can assist the product owner in signing off the product.

Some constraints with the technology platform have been found which are hindering providing the experience that the users might expect. While security meets acceptable standards more rigorous testing needs to be done. In addition, more automated testing tools could be used to ensure the product works well in different environments.

Our next steps

We will continue to review where we are against the standard and where we need to improve our working practices. We also need to do an accessibility review, a privacy impact assessment and ensure good standards are part of future developments.

We need to plan for ongoing user research to continue to improve the product, develop performance indicators and monitor user uptake and satisfaction with the product.

We also need to share findings about the technical platform used and create design patterns that could be reused.

Our business continuity and communications plans need to be developed and use made of the Council’s existing process if the product is unavailable. We also need to find a way to involve our Council Members in the work that’s been done.

Doing an internal assessment now has provided us with additional guidance in designing and developing a user-centred service.

 

Holding a great show and tell

We’ve been running show and tells for nearly a year, and in that time we’ve run 57 by my count, across 7 different services. That’s enough to have a model about what makes a great show and tell. Here’s what we’ve learnt:

1. Names don’t matter
Some people read ‘show and tell’ in their diary and don’t know what it is and assume it can’t be important. We put people first, so if ‘show and tell’ doesn’t work, we can call it ‘project update’ or ‘workshop’, ‘knowledge share’ or even ‘project board’.

2. Timing does
The optimal show and tell lasts half an hour. If attendees want it to last longer, it can continue. But we should prepare about 15 minutes content.

3. Venue
Make it easy for people to get there. Ideally, allow people to find out about it as it starts. Make it inclusive. Show and tells in meeting rooms don’t get noticed.

4. How to begin
The beginning of the event needs four things:
A welcome – it’s just polite
Thank you for coming – a show and tell is only valuable if people turn-up
The vision for the project – show and tells grow so often people are hearing it for the first time. Remind people what we’re trying to achieve.
The purpose of the event – a good show and tell will repeat back to people what they already know. You need to explain that’s for them to check we’ve listened and learnt, and identify any outliers or gaps.

5. The structure
There are two main parts to a show and tell: what we’ve done, what we will do. For some groups, we will need to create a third for their questions – but ideally the feedback has already started.

6. The presentation
Everyone has a role. A good show and tell is a team presenting its work. Everyone should have a role in explaining part of the story.

Show the product, don’t talk about the process.

Less jargon. Do people really need to hear ‘sprint’ rather than ‘fortnight’?

Remember to talk about us, our, we and team. Colleagues aren’t ‘them’, ‘the users’ or ‘officers’.

7. The message
Most listeners will remember 2-3 key points, and little more. Know what you want to say before you write a word on a slide. Have prompts ready to stimulate discussion, should you not get much feedback.

8. The deck
A slide deck is useful for people who couldn’t attend, and starts to collect valuable assets for your Service Standard assessments (screen grabs, personas).

Most rooms have a screen big enough for 10 words or part of a screen. Prepare lots of slides rather than one slide with lots of content.

9. Preparation
A show and tell is an important presentation, often to senior leaders. Practice – at least once, preferably as a team. Get a second pair of eyes on your presentation. Know how the projector works.

Prepare your attendees. Email them to remind them that you’re looking forward to seeing them. Explain that you’ll start on time because there’s a lot to cover. Remind them their input is important. Tell them biscuits (fruit?) will be provided

10. Plan B
Presentations go wrong. Plan B might be huddling around an iPad. Maybe the attendees get out their phones and open a URL. Don’t spend their time waiting for you to make the computer work.

11. Feedback
Capture feedback – ideally visibly. Write it on a post-it and put it on the wall. Don’t just nod. Get people to write their own thoughts – for example, annotate drawings. Feedback matters – so show it.

12. Thank you
Thank people for coming. Remind them that their input will make a better product. Remind them you’ll be back in a fortnight.

13. Learn
Retrospectives are for another blogpost, but should always happen after a show and tell. Reflect on what you’ve done and what you’ve learnt. Re-plan what needs to happen next. If the next fortnight looks as you anticipated the previous fortnight, you haven’t learnt enough.

By the end the year we’ll have passed 100 show and tells, and will have a more developed model. But in the meantime, if you follow this, you’ll learn more.

Working with suppliers to develop better digital services

Some of the best work we’ve done in the last year has been in partnership with our suppliers. In Hackney we’re particularly fortunate to have some of the world’s best digital agencies on our doorstep, many of whom have been helping us explore opportunities to redesign the Council’s services.

Whilst there’s an expectation that suppliers will work hard to fit in with our needs, we can produce better work at lower cost if we’re good to work with. We’ve been advertising tenders for individual pieces of work on the government’s Digital Marketplace which is a transparent and fair process, through which it now takes a couple of weeks to purchase a service, rather than traditional procurement exercises that run for months.

We invited a group, comprising leaders of agencies with which we’ve worked, to help us explore five questions. How might we:

  • Reveal our core challenges / opportunities and digital pipeline so that agencies can identify emerging opportunities to do business with Hackney?
  • Procure for user needs whilst enabling suppliers to build capacity to support us and plan resourcing?
  • Work in collaboration with agencies to get the most out of the skills they have to offer?
  • Ensure we develop long term expertise amongst colleagues, whilst remain focused on immediate delivery?
  • Identify emerging opportunities that we don’t yet know we need?

We learned four key things that can help us work better:

Think aloud

It’s important for us to think aloud, at an early stage of our thought process, so that suppliers can understand the aims for a Council service, and therefore how an individual piece of work contributes to those aims. Thinking aloud is more transparent and efficient for all (avoiding lots of individual conversations) but it also offers the prospect to approach something differently – whether in partnership with others or building on other work.

Planning ahead

We’ve been purchasing in an ‘Agile’ way. We advertise an opportunity as soon as we’re ready to start (ie once we have the need, people and budget aligned) and aim to complete the buying process in a couple of weeks for a job that is likely to take less than three months. Agencies find out about the opportunity when it’s posted. But running any profitable client services business means staff will be deployed on fee-paying work around 85% of the time. So whether or not an agency has the capacity immediately to Hackney, or put its best team on the job, is down to chance. We need to signpost earlier, without losing our agility.

Categorising opportunities

One of the key things suppliers want to know, is why we’re looking for support. Is it a non-core job that we want to get out of the way, something of strategic significance, or a small but innovative exploration? And it would also be useful for them to know how confident we are in the work. Have we set our technology direction, or are we open to new ideas? Are the people they’ll be working with seasoned digital practitioners, or are they still learning how to work in new ways? This will help them understand what resources to invest and what we’re trying to achieve.

Sizing jobs

We’ve been advertising for individual phases of work (typically, discovery, building a prototype, expanding into beta, then building a live service). These jobs are relatively small, especially at the discovery and prototype stages, and the costs of bidding are relatively high. Stuff that’s been working in the initial stages then has to stop mid-flight for procurement. We need to look at how we might tender for bigger opportunities so that we get a more seamless delivery, but we also need to make sure that we don’t make our projects so big they exclude smaller vendors or lose the ability to ‘fail fast’ where that’s the right thing to do.

Conclusion

Our goal is to work with high quality suppliers through which we support local businesses and residents in employment, to build better services for residents. We’ve made a good start, and listening to our suppliers’ perspectives has helped to give us a clear focus for where we should focus to improve further. Over the next couple of months we’ll be experimenting with different approaches to address these issues and then making the ideas that work, core to our approach.