By Dave Loudon, Founder of DtL Creative

You’ve bought a new, shiny, all-encompassing, truly amazing housing management system. Or at least, that’s 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’s that word again. ‘Can’. We’re saying that it ‘can’ do a good job, but only if it’s implemented well. And that’s the hard
part: implementing well. I’ve been involved in many housing systems implementations and I could write a book on the subject (now there’s an idea). We’ve 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:

• We get involved from the start
• We’re brought in to rescue a failing project.

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

The need

There must 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’re implementing this system because…and we’re going to make sure we deliver to this’.

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 it’s fine to give an initial system overview, but please don’t 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’s 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.

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’s 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, “Pete, you can do it, right? You once used a ZX Spectrum, so you know about these things”
• There’s 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’ll 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’ll make a big difference.

Architecture

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

Ignore all of that until it’s 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’ll make a difference when consultants and staff want to understand what’s in scope, what will work what, and what the intentions of particular interfaces are. As a minimum, we’d want to see a solution design document that encompasses the details.

What did we buy again?

Some of you reading this will know what we’re talking about here. You’d think that between the supplier and the buyer it’s known what was purchased. But we have seen countless times where it’s 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’s being delivered is one and the same.

We’ve 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 my first point about the ‘need’, it may just all start to make
more sense.

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