Before you start

This methodology is rooted in the ‘double-diamond’ - a way of thinking developed by the International Design Organisation and used by global organisations to tackle problems and challenges. During any phase of work you may be considering lots of options, before converging on a solution. There’s no point when you’re solving a problem when you shouldn’t be open to new ideas. However, this is very different from a ‘waterfall’ approach when you spend the first part of a project defining the requirements, and the second part delivering these requirements.

This is particularly useful for:

• Long-term challenges where there have been multiple efforts to ‘fix’ the problem
• Problems where the solution requires changing people’s behaviour
• Reducing the risk of a technical project where the solution hasn’t been commonly used

The method breaks into four phases to provide stakeholders the opportunity to stop work or change direction. However, it can be used to guide work differently, depending on the challenge. For example, a ‘Google Sprint’ will use many of these methods in just a week, whilst many technology companies don’t have a ‘discovery’ phase but prefer learning through testing and evaluating live services.

We have developed HAL to explain how to develop a digital service, but a successful digital service relies on a business process that is efficient and simple, a consistent approach across other channels (phone, paper, face to face), and clear rules that could be automated. All of these issues will be identified during the research and testing and will need to be tackled through the prototyping, building and improving stages if the ‘end to end’ service is to truly meet user needs.

This method is particularly effective when we’re working to Agile principles. The Agile manifestostresses the importance of working solutions over comprehensive documentation. In Hackney, all IT projects are run to Agile principles so that we:

• Test and learn so that our services meet the users' needs
• Reduce the risk of finding out something doesn't work at the end of the project
• We can make decisions quickly and respond to change

Before you begin

Anyone in IT is encouraged to ‘fail in a fortnight’. That means, if you’ve identified something that you want to do, you can spend up to two weeks finding out how to do it and building a case to do it (current workload notwithstanding). However, when we’re building products for services, we normally need the input of colleagues. Therefore, before you begin, make sure you:

• Have a draft project brief
• Check with the Head of Service and Team Manager that the timing works for them
• If you're working with an agency, make sure you have used the checklist for onboarding an agency
• Have a draft project brief
• Update the Hackney ICT portfolio Trello board
All digital services in Hackney need to be assessed against the Local Government Digital Service Standard before being live for users. Follow whichever parts of the methodology help you successfully reach the Standard. This is consistent with our manifesto, particularly: People first, More doing, less planning. The manual can be followed at each step of the way and the project can still fail if it is not used in the right way. For example, if key stakeholders believe that there is an existing solution and it just needs to be implemented, then few of these techniques will have any value. The manual will continue to be improved in response to user feedback, so make sure you blog about your work at HackIT