You’ve bought a new, shiny, all encompassing, truly amazing housing management system. Or at least that is what the supplier said at the conference. It can do this and that, it can change your life forever, it can transform the way you do things for the better. However, can it?

First up, of course it can. The above is not necessarily a dig at the suppliers. We believe ‘most’ of the systems out there are very good systems, and ‘can’ potentially deliver some improvements in your operations, improve your customer satisfaction, and give you more insight into your data, your performance, your service delivery.

We say ‘can’. There is that word again. Can.

We are saying that it ‘can’ do a good job, but only if it is implemented well. And that is the hard part; implementing well.

DtL Creative have been involved in many housing systems implementations. It’s what we do, and we could write a book on the subject (now there’s an idea). We have been doing it for a while now, and although systems have evolved, and are technically more advanced, the same old issues of systems transformation rear their very ugly head again and again.

As a consultancy, we find ourselves in the main getting involved in two lines of work with housing systems.

1. We get involved from the start.

2. We are brought in to rescue a failing project.

The second is usually needed after some or all of the areas below have occurred. So, we have, hoping some will take heed, set out five lessons in avoiding the classic mistake of ‘forgetting why you bought it in the first place’.

1. The need.

There has to be a need. Someone somewhere in your organisation has stood up and said we ‘need’ a new system because of, well, something.

We don’t want to focus on specific needs, but what we do want to say is that it never surprises us that landlords seem to lose sight of these as the project goes on.

They should be omni-present, and they should be agreed, documented, reported on, all staff/users made aware of, communicated to the supplier, communicated to a consultancy, third parties and so on.

Develop a reporting mechanism in your project that says, ‘Hey, we are implementing this system because……and we are going to make sure we deliver to this’.

2. Training.

Training is one area that surprises us. Why on earth do some of the suppliers carry out classroom training or train the trainer before the system is ready for it. They do it way too early in the project. It’s fine to train those involved as part of the project team, and its fine to give an initial system overview, but please do not attempt to carry out anything more than this until the very later stages of the project, and only do it on the actual final data set. It is then, and only then that it makes sense to the many who will use the system/s.

Finally, people forget. So, leave the training to as late as possible.

3. Teamwork and roles.

Our experience has shown us a few classic traits in systems projects relating to team working. They are:

· Landlords under staff their projects. Too often, there is not enough involvement from a project management perspective. IT, operational departments, and yes, you! the senior folks, the sponsors. Resource your project responsibly with the due care and attention something of this scale requires.

· Landlords lump it all on one person. Don’t fall under the trap of saying, ‘Alastair, you can do it, right? You once used a ZX Spectrum, so you know about these things’.

· There is no liaison. Make sure someone is available to be the main conduit to the supplier and that they talk to them. This should really be your PM. Make sure this person controls the communication and is the main conduit. Avoid multi-channel chat between the supplier and all your different staff as there needs to be control, otherwise it will all go haywire.

· Understand the roles. Don’t just rely on the supplier to create the project governance. Write your own PID, and get the Roles and Responsibilities detailed out. It will make a big difference.

4. Architecture

System’s architecture is the key to making the system shine. Any housing management system out there really only comes to life when it works well with your other systems. You’ll hear about things such as the finance system integration/interface ad so on. You will hear about magical technologies such as web services. You will hear about flat file methods of getting data across, or real time interfaces.

Ignore all of that! Until it is time. Start off thinking about how you work, and what information you need to pass or be visible between different departments, then you can rely on the technical architects to make it happen.

Draw your intentions in a diagram and include it in the project documentation. It will make a difference when consultants and staff want to understand what is in scope, what will work what, and what the intentions of particular interfaces are.

As a minimum we would want to see a solution design document that encompasses the details.

5. What did we buy again?

Some of you reading this will know what we are talking about here.

You would think that between the supplier and the buyer it is known what was purchased. But we have seen countless times where it is not clear.

Most systems out there are based around modules such as repairs, rents, ASB, CRM and so on. Make sure you have these referenced back to the contract/agreement you had following your tender.

The same goes for areas such as consultancy days, expenses, and so on.

Simply put, the flow of Tender > contract > delivery is critical, and someone needs to know and own the overall commercial and contractual delivery and how this relates to your project delivery. When you said you wanted ‘this and that’ in your tender and then supplier X won, based on those requirements, it ends up in a contract cementing these requirements. There is now a commitment to deliver. Then, comes the part of making it happen, and ensuring what you bought and what is being delivered is one and the same.

We have seen a real disconnect in some projects where the direction the project was taking was nothing like what was contracted to be delivered. This is where the project control is so important. And if you go back to point 1 about the ‘need’ it may just all start to make more sense.

There is an old saying, “It does exactly what it says on the tin”. It’s also true in systems transformation projects.