In this post I want to share my experiences in the support of the governance process that is responsible for keeping the level of customization for a standard package solution under control. How do we approach this? It's easy to boldly say upfront that you rather adapt your way of working than to customize the software you bought. This post is all about sticking to that decision even when the going gets tough.
Any professional that has experience in implementing package solutions will agree that the only way to achieve success and reap the long-term benefits is by limiting the customizations you make to the standard solution's code. The cost of adapting standard code might not be that high at the moment itself, but it becomes really expensive later on. Any update that the software provider releases would require an impact analysis on the customizations. Fully aware of these long-term consequences, bpost has consciously chosen for a standard HR-solution and made it very clear from the beginning that the budget for customizations would be very limited and closely watched upon.
How do you do this? How to stick to that kind of strategy and avoid letting go when the pressure starts to go up? We did it by implementing a governance process that makes sure that every customization to the software first needs to be approved by the project sponsor. Without formal approval of the sponsor, the invoice of the implementation partner wouldn't be paid. Sounds easy enough. The only trick is: the project sponsor is not involved in the day to day operations of the project. He doesn't follow all the workshops. How can this sponsor take the right decision and feel confident about it?
To tackle this challenge, we've created a dedicated governance body that:
I'm not a fan of 'overformalizing' things but you need at least some basic structure.
In the case of the bpost iHRM program this structure includes:
It wouldn’t surprise me that being in meetings where they have no added value is in your colleagues top ten of professional irritations. If you'd ask me, it would be in my top five. We limit the number of people around the table to those who have an impact on the meeting's objective. That way we can ensure an efficient meeting.
If you are looking for inspiration, this is our SAB:
In order to provide the decision taker with the right information to take a confident decision, we rely on a template that contains just enough information and focus on the aspects that really matter.
Our template consists of:
This is probably the most important slide and always contains the same evaluation parameters. This is vital to achieve consistency in the decision process throughout the project.
The parameters we use to evaluate each alternative are:
The evaluation is presented in a matrix style that immediately indicates the rationale for a certain decision. To obtain a final decision of the decision taker, we reuse a few slides and propose the advised solution and the rationale.
This method has proven itself time after time over the past three years so it's something I can highly recommend. We were able to stick within the foreseen limitations on customizations for the first phase of the program and are on good track regarding the second phase. Don't be mislead by the example slide! Most of the customization requests have been denied and alternative solutions have been found. We stick to the plan!
This is the end on a series of posts on a great program in which bpost has already shown a lot of maturity and perseverance. It is still ongoing and I sincerely hope that somewhere beginning next year we can celebrate the successful go-live of the program's second phase. Meanwhile it's been a pleasure to write about my experiences and I look forward to any questions or comments you might have. I hope you've enjoyed reading this stuff as much as I liked writing it.