Common Housing Register (CHR) - building a register: a practitioner's guide

SECTION NINE: USING ICT TO RUN YOUR CHR

What is ICT for in a CHR?

Information and Communication Technology ( ICT) is a tool to help you achieve the outcomes you want to see from your CHR. It is an instrument that should deliver the CHR and its objectives. Technical issues should not define your CHR or direct its development in any significant way.

You should not focus on ICT requirements too early in the process but should be well down the road to finalising your CHR model and how the CHR will operate before identifying your ICT needs. By the time you talk to ICT consultants/staff, you must be able to clearly explain what you want your CHR to do.

However, it has become clear over recent years that ICT considerations cannot be left to the very end of the process. For example, it is important that you consider the likely cost implications of the ICT system required for the CHR model you are developing. The model may need to be reconsidered at a later date if ICT costs are too high for the partnership. Indeed, there is a danger that if you do not consider ICT issues early enough in the process you may have to rework your business model as a result of ICT being undeliverable, overly expensive, or a due to limited buy-in from all partners making the model unworkable.

Clearly, a simpler CHR model is likely to result in simpler and less costly ICT requirements. There may be opportunities to keep the process simple where a partner's existing ICT system can be used to take the CHR forward.

What are the options: For sharing information?

The first key component of a CHR is a single route for applicants to different housing providers in the area. Sharing applicant details through a common database is one way of doing this. But there are other options for the shorter term.

At the most basic level, partners that are inputting applicant information individually need to ensure that each partner sees the applicant information. This could involve technologically simple options such as faxing or photocopying and posting or hand delivering the application to other partners. Alternatively ICT can be used to speed up the process by scanning and emailing applications between partners.

These options do not deliver the core CHR component of a common database of applicants, although may be part of an interim phase towards this. And while sharing information in this way keeps ICT costs to a minimum, there is duplication of effort with staff at each of the participating landlords re-inputting the same applicant information. The technologically simple solutions are likely to require more investment of staff time and associated costs. Partners also need to consider whether these options provide sufficient security for the transfer of data.

Example: Using ICT for a single application route

Partners in Midlothian did not feel that it was necessary to set up a common database with applicant details in the first instance. They felt that they could operate a common form simply by sharing information through email and passing hard copies between offices.

Each of the three core partners therefore accepts the common application form. Midlothian Council and Castle Rock Edinvar Housing Association both scan and share the form by email. Although Midlothian Council needs the whole form, Castle Rock Edinvar only needs the first page, which includes applicant details. It then asks applicants to register separately for choice based letting. Melville Housing Association keeps the hard copy. Midlothian Council and Melville Housing Association have offices on the same street, and so simply pass forms between offices. Any other evidence is also scanned and shared, or passed between offices. In practice, Midlothian Council has been receiving the majority of the forms and passing these on to the associations.

Both Midlothian Council and Castle Rock Edinvar were already set up to scan and share documents, and so no new investment in ICT was required. The Council did purchase the CHR module for its housing management system, in case a common applicant database was required in the future. The partners all have excellent relationships, and they "just put their heads together" to come up with an ICT solution. For example, Midlothian Council offered to meet the cost of Melville Housing Association purchasing scanning equipment if required.

The arrangements for scanning and sharing hard copies works well. All of the partners are able to easily and simply access the information they need for processing applications and making housing allocations.

So far, the main benefit of the CHR has been for applicants in terms of making the process simpler and clearer. The partners have seen some increase in their workloads relating to applications and allocations in the initial stages of the CHR.

What are the options: For creating a common database?

Where the CHR is delivering a database of applicants the ICT options relate to how information is inputted and the level of automation and access to the database.

Inputting of information can be done either by some or all of the partners, or by a nominated partner or central processing unit. There are clear cost implications for establishing a dedicated central processing unit and resource implications for any partner that undertakes all the data inputting for the CHR. Participating landlords will have to weigh-up these costs with the cost in staff time of sharing the burden of inputting - and the ICT costs of developing remote access to the central database.

The common database will be held at a core ICT system. This central system will have the capacity to produce shortlists of applicants as required. The greater the commonality between partners, the less work will be required of the ICT system to produce appropriate shortlists. Hypothetically, if all partners in a CHR have agreed a common allocation policy the system can produce shortlists pointed to the one policy each time a landlord has a vacancy. The more landlords with separate pointing systems that are fully linked into the system, then the more sophisticated the system will need to be in order to be able to repoint the database according to a range of policies.

One option which simplifies the ICT specification, but sees some double inputting, is for a partner without an integrated policy to request a shortlist from the core ICT system which is pointed according to a similar allocation policy (for example in a buddying arrangement). This shortlist is then manually inputted to the partner landlords ICT system for pointing according to their own policy.

In addition to automatic pointing the CHR partnership will need to consider the level of access that is desirable. The system will be able to produce either manual shortlists for partners without a link or full partners will be able to view the shortlist through secure access to the database.

Example - potential ICT models

The ICT Advisory Service for CHR Partnerships based at the SHBVN have developed schematic diagrams showing the systems that have been developed after partners have considered the issues relating to inputting, access to the database and automation. In the diagrams below, partners with a link to the core ICT system are represented in blue while those without are shown in purple. Option One is based on the proposed system for the North Lanarkshire CHR where partners with a secure link to the system input application data themselves. Partners without an ICT link are forwarded applications to input to their own system.

Option Two is based on EdIndex where a central processing unit inputs application details. Clearly these options are not exhaustive but give a sense of how an ICT solution will look where partners have different ICT status.

Option One

Option Two

How do we decide which option is right for us?

When CHR partners are considering ICT options decisions will be influenced by:

• existing ICT arrangements;
• the number of housing allocations they are likely to make; and
• the potential size of the common database.

These issues will underpin any assessment of costs and whether a particular ICT solution represents value for money. For example, partners who only allocate a small number of homes each year may not want to spend significant amounts on establishing an automated ICT link. There may be cost savings in using an existing ICT system. An example of this has been seen in HOME Argyll where the CHR is hosted on the Council's pre-existing housing management system.

The CHR partnership will need to decide how complex the core ICT system needs to be. Issues that will influence this decision include:

• the level of commonality that has been achieved;
• the number of landlords involved in the CHR;
• the number of landlords with high levels of allocations and who are therefore more likely to need a link to the core system;
• potential resource savings from shared administration; and
• potential resource savings from automated matching of vacancies and applicants.

The ICT solution will be somewhere along a scale, running from the most simple to the most complex. Developing a comprehensive, complex system will require the highest initial capital costs. The most complete ICT system would be capable of:

• giving the correct level of priority to applicants according to any partner's allocation policy;
• reordering the database according to several different allocations policies;
• allowing electronic access to the database by a range of partners form different locations; and
• providing an automated property matching function.

Clearly such a system will be costly to develop. Greater commonality of policies and procedures will reduce the level of complexity and ICT costs. Partners will also have to assess the costs of developing the ICT system against potential benefits of reducing staff time spent on administration/allocations.

Example: Keeping it simple

Fife took the existing Council system and amended it. The Fife Housing Register partners agreed to host their common applicant database on a specifically designed allocations module within the Council's existing housing management system.

The system is located on the Council's network which allows all the partners to access it in real time. All forms are input by a team which is managed by Fife Council on behalf of the partners. The system automatically points the applications based on Fife Housing Register's common assessment of need. The system also includes a register of properties, and users have a range of criteria to match applicants with available properties.

The partnership explored a range of different ICT options but ultimately the existing system was seen as the best option. It was already in use and already had in that the Council system already had a number of the capabilities that the Fife Housing Register required. The Council also had the skills in-house to support the amendment of the system as necessary to meet the needs of all partners. Fife Council had previously worked with the software provider and they developed the concepts and functionality together. The key was to keep the ICT system as simple and stable as possible. The choice to develop a CHR that would run on proven technology was regarded as the safer option relative to other options that were considered at the time.

"We had a choice of either a high risk, high cost, unknown environment, or a CHR that was running with technology that we already know, in house."

Partners feel that the key to having a successful ICT system is to keep things simple in terms of knowing what it is you want the system to be able to do, and to find the best way of achieving that. Very often it could be that the existing ICT system can be used, or adapted to save on costs.

"There is no point in getting a system with bells and whistles if you don't need them, or won't use them."

Example: Problems with complex ICT requirements

In Renfrewshire, it was agreed that the preferred solution for the ICT system would be to link a module to the Council's new housing management system. At the time of this decision, the Council had just purchased this system and it had not yet been introduced.

But the process of moving to a new ICT system for a large organisation such as a local authority takes a significant amount of time. This meant that Phase One of the CHR was launched in 2003 using the Council's existing ICT system to share information between partners. The system was enhanced to accommodate the common application form, and to give all partners remote access.

Each partner input the application forms they received into the common ICT system so that the others could see them and also into their own housing management system for shortlisting applicants. This double inputting was inefficient and created significant backlogs of applications. This was exacerbated by increases in demand, creating difficulties administering the system. It also reduced customer service for many partners and negatively impacted on the time taken to let properties.

As a result of this, work began to develop a data transfer interface where information could be downloaded directly from the ICT system into individual RSL systems. This would mean that there was no need for double inputting. The Council's IT department worked closely with each of the partners to develop an interface and help with the transition to the new system. This was a positive period of strong joint working between partners.

Partners were integrated onto the system between December 2005 and May 2006. Although there were some operational issues, partners were pleased that the system was working and was moving forward as a functioning CHR: "It gave us an indication of how a CHR could work."

Partners were getting used to working on the system and were gaining confidence in the CHR. But the Council's transition to the new ICT system was due to go ahead in October 2006 and this meant that the CHR database would also be transferred. The CHR was temporarily hosted by the new ICT system but shortly after its introduction it became clear that the system was not able to handle the complexities of the partners' different allocation policies. With hindsight, this area of functionality should have been explored before this system was selected.

It was agreed that further development work was needed, and the RSL partners reverted to the Council's old ICT system. Renfrewshire Council has continued to use the new system for its housing list. There were concerns that the process of transferring data between the Council's ICT systems had corrupted some of the information, with a number of inaccuracies becoming evident on RSL partners' housing lists. Eventually, the partners all reverted to using their old ICT systems, and the CHR was wound down.

Partners would now advise others to make sure that any ICT solution developed within a CHR is fully tested before going live.

How do we pursue our preferred option?

• Developing an ICT specification

CHR partners need to be absolutely clear about what they want their CHR to deliver before they bring in ICT specialists to develop the system. This means putting together an easily understood list of everything that you need the system to do to make your CHR work.

The term ICT specification sounds technical but putting the list together is not a technical exercise. The ICT experts should take care of technical issues. The task for CHR partners is to think about everything the system will need to do in order to deliver your CHR objectives.

An example system specification for a comprehensive, complex CHR is given at Appendix Three. This gives a good indication of the range of elements you may wish to consider including in a specification.

• Tendering

The partnership may choose to develop the CHR with an off-the-shelf ICT system, or decide to build the CHR on a housing management system currently in operation with one or more of the partners. In either case you will need to involve ICT specialists that are best able to deliver an ICT solution that meets the specification.

If this means bringing in external consultants you will need to develop and advertise a brief for the CHR ICT system. The ICT brief should clearly explain the background to the CHR, the purpose and objectives for the CHR, the CHR model chosen, and the detailed specification outlining the ICT requirements. The brief should also outline your expectations in terms of training for staff and ongoing support.

• Managing your ICT provider

The relationship between the CHR client, i.e. the partnership and the ICT provider is an important element in making sure your CHR is delivered successfully. The relationship should be built on a robust specification and a clear understanding of responsibilities.

When you have appointed an ICT provider they become another partner in the development of the CHR. You are working towards the same goal and are not on opposing sides. This understanding needs to be established at the beginning of the process and will rely on involvement of senior staff within the partnership and at the ICT provider.

It is essential that you have a single point of contact at the supplier that you will be able to contact throughout the life of the project. It is then important to establish an "escalation route" to deal with any issues arising as the project moves forward. You will need to have an escalation route within your own organisation or partnership and you need to know what the escalation route is beyond your point of contact within the supplier organisation. Since you are responsible for delivering the CHR you need to have the confidence to take control if barriers appear.

It is important to have a full project plan established for the development of the ICT system. This will set out a path to delivery including key stage dates and the go-live date. This should be agreed with the supplier along with escalation steps should dates be missed. Make sure you get regular progress updates from the supplier and make sure you feed back to them what other developments are taking place in the CHR.

• Example: Developing an innovative ICT system

Getting started

The Aberdeenshire and Moray partnership (Apply4Homes) started by exploring what they wanted the ICT to do. With ICT consultants, they developed a vision for the application system and developed a specification. The basic idea was that instead of filling out the whole application form, the applicant would only need to complete the necessary questions for the landlords they were applying for. This approach was very much driven by a desire to develop a system that was user friendly, without the need to agree a common policy. The partnership identified companies able to create an online application form through a tendering process managed by Aberdeenshire Council.

A web-based application system

Apply4homes is a web based application system.

"You can think of it as an application portal. It is simply a way of applying for a house."

"What we have done is like replacing ten different post boxes with one. The system then sends the information back to the ten other post boxes where it can be dealt with by the landlord. Nothing else changes."

As the partners are retaining their own allocation policies, they all need to gather different information from applicants. The Apply4Homes system will be designed to take account of these, but simplifies the process for applicants through the development of "intelligent processes". An applicant will input basic information - like their name and address - which is common to all landlords. Then they will select the areas they want to live in from an interactive map. The system will identify which landlords have homes in that area and the rest of the questions are tailored to the information only those landlords need.

Data management and ICT

Applicant information from Apply4Homes will be transferred to the partners' individual housing management systems overnight. This will involve a file being created which can then be picked up by each partner's own ICT system. Staff in each partner organisation will then look at the information each day before validating and accepting the information into their own system.

Each partner is planning a slightly different way of linking to the Apply4Homes system. Moray and Aberdeenshire Councils are developing an interface together as they both use the same ICT systems. This allows costs and development time to be shared.

Getting the new system to work with each partner's system has been extremely challenging.

"In theory it should not be a problem, but in reality it always is."

There are plans to develop a Service Level Agreement before the system goes live. It will set out protocols, how information will be shared and timescales for inputting data. A data sharing policy is also being finalised.

ICT costs

Some of the capital costs have been met by CHR funding from the Scottish Government, but additional capital development costs have been shared between Aberdeenshire and Moray Councils. Running costs will be shared across the landlords on a pro rata basis. Each RSL is then paying for the development of the interface needed to connect their own system with Apply4Homes.

The ICT has cost more than originally envisaged. But partners feel that it has not been as expensive as it might have been. Increases have largely been due to changes to what partners want from the system. From a local authority point of view, working across two geographical areas has had cost benefits, as they are sharing the development cost.

Challenges along the way

There was general agreement that the ICT development process has been very challenging, and has not as yet delivered what the partners had hoped for. The system is not yet as intelligent as partners had hoped, and there are still a number of issues to be resolved. The main challenges have been:

• ICT security - There have been concerns about the security of sensitive data held within the ICT system.
• Lack of commonality - Some partners suggested that starting with greater commonality rather than relying on the intelligent system to limit the number of questions may have been more effective and perhaps easier.
• Terminology and jargon - Some people involved felt that their lack of ICT knowledge had made the process more challenging.

"Everyone is ICT aware up to a certain level or point. But we do not talk the same language as the ICT developers sometimes do."

• Resources and timescales - Progress has been slow and early delays have led to further delays with the ICT supplier and the partners. It has been a resource intensive process, and some partners feel this led to some of the delays because most of the people involved have other responsibilities. There was also a sense that the partners may have underestimated the task in terms of its size, the length of time and its complexity.