2 of 8

What we discussed last week

There is a burning desire for a new approach to housing management technology.

The favoured procurement approach combined:

Option 1: tender for a full-suite HMS with an established provider (e.g. Northgate, Civica, Capita)

and,

Option 3: where feasible, look to procure or develop additional capabilities that can be added to the core solution (e.g. Jadu, SiteCore, low-code applications)

And we discussed some of the inputs we needed to make a final decision, incl.

User research on the pain points experienced
Shared business outcomes

3 of 8

What are we discussing in this session?

We’ll be exploring common ground - business objectives, users, requirements, timelines, etc.

Why focus on commonality? What do we know about ‘joint procurements’ (see guidance)?

Joint procurements aggregate demand across a number of boroughs
Large suppliers are very willing to work with collaborative purchasing groups, if they represent “a single voice”
The key task of any joint procurement is to map out what you have in common, and seek to minimise the differences

What does it take to speak to the market with ‘a single voice’?

Common set of key objectives for the procurement
Shared view of the key user needs
Common specification, that minimises bespoke requirements
Shared approach to contracting, that minimises alterations (for discussion next week)

�Key outcome: Planning how to take these work items forward together ahead.

4 of 8

Group Discussion

5 of 8

Discuss: What are the common objectives?

We need to define a set of key objectives that guide the procurement exercise and inform the assessment of suppliers.

Key objectives already discussed (see workshop, January 2020). �

Do we agree? What is missing? Do these capture the business value we are seeking, and our understanding of the market today?

Interoperability to enable data openness and system integrations (without charges)
Improved core product -- e.g. better customer journey or front-end interoperability
Improved performance -- e.g. to avoid systems running slowly through KPIs and service credits
Improved flexibility -- e.g. ability for system to evolve, particularly to changes in statutory responsibility
Ability to deploy in the cloud, either as a SaaS or PaaS solution
Improved maintenance -- e.g. announce releases in advance and ensuring they are properly tested
Improved management -- e.g. more responsive account management
Pricing and roadmap transparency at the procurement stage

6 of 8

Discuss: Who’s user needs do we need to map?

Has there been any user research performed to date? Are there any users that we understand pretty well already?

Who are the users that we don’t understand well, and are likely served poorly by existing HMS? How can we better understand their needs?

User Group (A s a...)	What are they trying to do and what barriers do they face?	What research can we do to assess needs?
Residents	Poor customer journey in: (i) applications process (ii) onboarding new tenants	Conduct ethnography to assess key process preferences, e.g. resident applications. Can we utilise any user insights from prior housing repairs user research?
Vulnerable people	Poor tracking of their interactions with council services: (i) adult social care (ii) homeless services.	Engage councillors to understand priorities.
Leaseholders	Poor information is provided to external leaseholders, and internal management team struggle with workflow.	Qualitative workshop to capture pain points.
Tenancy Management Officers	Need better processes for: (i) identifying residents with financial difficulties (e.g. voids)	Qualitative workshop to capture pain points.
Wider services related to housing	There are a range of internal (e.g. environmental officers) and external users (e.g. repairs and maintenance contractors, construction companies, housing associations) that are digital service users	Identify stakeholders and conduct qualitative workshops to capture pain points. Potentially could run a short survey to gather needs from a range of stakeholders.
Finance directorate	Need better processes for: (i) integrations and workflows vary across key payments and financial irregularity processes (e.g. tenants on benefits)	Conduct interviews across the business and directorates

7 of 8

Discuss: How do we create a common specification?

To speak with ‘one voice’ the tender specification should emphasise common requirements. Each borough can still retain bespoke requirements, but these should be minimised.

Today, it’s likely that each borough has a long and complex set of requirements. But, the goal is to reach a set of common requirements: e.g. functional requirements, technical requirements, etc. You should:

Define best practice
Simplify requirements
State a solution-agnostic ‘outcome’ where there is disagreement over a specific requirement.*
… ?

Specification input	What are the key sources of insight / information?	How can we agree best practice?
e.g. Functional requirements		e.g. Group workshop with ‘X’ users.
e.g. Technical requirements		e.g. Group workshop with ‘X’ users.
e.g. Performance requirements		e.g. Group workshop with ‘X’ users.
e.g. Future capabilities		Agree key principles (e.g. data sharing requirements).
E.g. Assessment criteria		E.g. social value