Why Change Fails

By Shelley Hood, Founder, Cataliz Consulting


Applying "Best Practices" without context
When organisations undertake a large and expensive project they (rightfully) turn to others for guidance on what works and what doesn't. They adopt methodologies and best practices to mitigate the risk of the unknown. The implication is that the success of others can be captured in one recipe. It can't.

Even where most organisational characteristics can be almost identical, the road to success can look very different.

Take the example of a disruptive technology project being introduced in a public organisation vs. a private one: one group of employees chose their career for job stability, a decent wage and a predictable future. Their identity - both inside and outside of work, is very tightly connected to the job they do and the role that they're in. The other group joined their company for opportunities, are always looking to expand their resume, and start looking for their next role before the chair is warm in their current one.

If all other attributes were the same - same technology, same budget, same time-frame and same organisational size the differences in implementation approach would be far greater then any similarities. One group would see the technology as a massive threat, while the other would see it as an incredible opportunity to stay on the leading edge.

You wouldn't be able to apply one theoretical model to both of those situations.

There is no replacing judgment and experience to apply the best of what others have learned to your very specific context. Whether it be team size, budget, geographical location, corporate structure or demographic profile each and every project situation is unique. There is no recipe that is 100% transferable from one project to the next.

Each organisation needs to learn how to combine the unique characteristics of their project with the lessons learned from others to create their own project recipe.

The project brotherhood
A lot has been written over the years about the value of building strong project teams. Team handshakes, code names, and movie nights have been the calling cards of a "strong" team. The problem is that project teams - cohesive as they are, are typically long gone when the project benefits are due to be realised.

Ironically the stronger the brotherhood of the project team the less included - and interested, the receiving business users are.

It doesn't seem to matter if the project team includes members of the operational organisation or not. People can work side by side for years, but as soon as they go on "temporary assignment" to a project the relationship changes. They've entered the brotherhood.

The problem with the brotherhood is that they develop such a strong ownership of what they're developing that it becomes difficult for them to transfer the ownership to the organisation that needs to use it. Even if there is a fully engaged business team waiting anxiously to receive the fruits of the project the brotherhood can quickly squash that enthusiasm. They tend to inform people about what they're doing but they don't (really) share. This poses real challenges for transition to and acceptance by the organisation - never mind long-term adoption.

Ideally the project team delivers to implementation team. The implementation team delivers to the organisation. The implementation team is comprised of the people in the business that will own the benefits of the project for the long term. The implementation team acts as a broker between the project and the end-users.

Not only does this place long term ownership in the right place it also ensures that the project team delivers a product that will work for the business, by delivering it to a team that will be evaluate the product with an objectivity that the project team can't.

I have delivered a number of applications in an extreme example of this model that worked really well - the project team resided in one country, while the implementation team (the business) resided in another.

Although the project team felt very strongly that the projects were "theirs" and the team was strongly bonded around that belief, the implementation team were insulated from the project brotherhood. At times the project team would push back in indignation that some of their brilliant ideas were being tossed for the sake of the end-user but that provided a healthy tension - diluted by an international border.

This was much better then the project team sitting in the organisation that they're delivering to. It allows the implementation team to establish strong ownership early with the end-users - away from what can potentially be an overpowering project team.

Project teams should never deliver directly to the end business users. The implementation team as broker is the best way to keep everyone honest, to ensure that the business owners are engaged and feel ownership of the deliverable early and through to the realisation of benefits.

Long after the project team has disbanded.

Shelly Hood