A week or so ago we facilitated a week-long event for our Estates and Facilities Management department. We were helping them to look at their reactive maintenance process, because they’re about to upgrade the current version of their maintenance system to the latest version. The project manager for this major project took the unusual (but essential) step of thinking about the fitness for use of the current process. All too often we find that the introduction of a new computer system is seen as a panacea which will fix all the problems with the current process, and provide accurate, timely and just more management information. It was very heartening therefore to work on a project where the importance of getting the process right was recognised.
The process improvement project was planned and organised quickly in order to fit in with the overall project timescales. We pride ourselves on our ability to respond to meet people's needs - but this rapidity caused problems. We didn’t have time for a planning meeting, so some members of the project team were not briefed as well as they should have been. Some seemed to have been told they were going to be in a workshop with the software suppliers, others had only a sketchy idea of who PIU were and what we were doing. This didn’t become apparent to us until later on in the week. It’s amazing that in spite of this people were still positive and keen to make changes to resolve some of the many problems associated with the maintenance process. In particular participants were telling us that Risk Assessment and Method Statements (RAMs) were unworkable since they required too much time to devise, especially when working with contractors, and that SLAs imposed bore no relationship to reality and were therefore worthless. We spoke to the director of EFM who told us that there was no question of not having RAMs, but that they could be generic, and likewise that SLAs were a regulatory requirement, but that they needed to be sensible.
By the end of the week a new process which stands a chance of being adhered to had been drawn up, we had considered health and safety and SLA times, and participants were enthusiastic about the possibility for change, although fearful that it would not get past senior management in EFM.What are the main lessons from this flawed project?
- Never assume that project members know what you’re talking about - always check assumptions and follow your own process properly.
- Always check the facts - don’t rely on people’s hazy memory of the rationale behind decisions.
- Admire people for their ability to circumvent regulation where it stops them getting the job done rather than blaming them - and use that creativity to build a process that they don't need to circumvent!