Guy McClintock, Solution Architect Stream Lead, FINEOS
Recently I was involved in discussions related to framing a business case for a claims replacement project. The conversation centred around the return on investment that the new claims system would bring. Naturally we discussed the hard benefits which could be turned into a tangible dollar and cent amounts; for example, the ability to process claims more efficiently, increased profitability and being able to do more for the customer with the same size team. We also discussed the more (but equally important) intangible benefits like user experience and customer satisfaction, which, while less scientifically proven, are no less important. This was all good conversation and debate, the outputs of which will be used to frame the business case, and hopefully push the release of the budget to start the project.
But what happens next? The project team is established, there is a kick-off where the business case is referred to, but then, it’s usually shelved until close to delivery time when its frantically reviewed to ensure all the boxes have been ticked. Is this really the right way to operate? Should the business case be kept under wraps only for the senior executives and sponsors to be aware of? No doubt there is commercially sensitive strategic information in the business case, however, keeping the full thing under wraps feels wrong, doesn’t it? It feels like expecting someone to get somewhere without telling them where it is you actually want them to get to. If you don’t think that makes sense for one person, why does it makes sense for a whole group of people? Especially when that group can be distributed across multiple disciplines, locations and even organisations!
Consider a project with 100 people working on it. Every one of those people has their own goals and desires. Some will be operating on a personal level, attempting to shine in a particular role. Others, hopefully the majority, will have the project’s success more to the forefront. The question then becomes, what defines a project success? Shouldn’t it relate to delivering on that business case that was defined at the outset? I believe it should.
To that end, I would advise incorporating the key project goal elements of the business case into the everyday life of the project team. Maybe it’ll need to be tailored so that it is relevant to everyone, but this shouldn’t be a tall order, and the exercise itself will be useful. This is where the “perpetual” comes in. The business case should frame all major milestones of the project, it should even frame workshops and meetings. Everyone on the project can become empowered to positively challenge decisions and outcomes … “Is this really helping us to achieve our business case?” … “But the business case says we should be aiming for this” … This kind of self-organisation and empowerment would help engender a real sense of ownership in the project, and more importantly a clear understanding of where we are trying to get to.
So the next time you are pulling together a project team, consider the power of putting the business case at the front and centre of the project – and keeping it there for the life of the implementation, refer to it regularly, have your team makes decisions with the business case front and centre in their thinking. Imagine a place where everyone on the team is driving in the same direction to achieve the same goal. It sounds like a great project to work on to me!
