Customization strategy. Stick to the plan

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:

• Is supported by a good process and template.
• Consists of a limited set of people that together have the right set of skills and knowledge.
• Formulates a substantiated advice for the sponsor.

Process and template

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:

• A governance body with a clear name: 'Solution Alignment Board'.
• A recurrent meeting slot with enough time reserves. We plan in two hours every two weeks.
• If the agenda is not fully booked, the participants gain some free time. This works better than reshuffling calendars when decisions need to be taken fast.
• A straightforward and easy process. I try to have the agenda finalized one week before the meeting date. I also request to have the meeting materials two days before the meeting so I can review it on completeness and quality.
• A template that puts focus on all aspects that are relevant to support decision taking. I'll tell you more about the template's content in a minute.

The right people around the table

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:

• SAB Chairman (in our case the business architect)
• The program manager
• A business manager with broad knowledge and active project involvement
• Two domain owners (project team members with profound knowledge in a business area)
• The project manager of the package implementor
• Guests that present a topic on the agenda or that have specific knowledge

Formulate a substantiated advice

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:

• Some general context
  What information is touched? Which business process are we discussing? Which application components are involved?
• The business problem
  Address the business problem as accurately as possible. Stick to what matters and where it could hurt.
• Business impact (if we'd do nothing)
  What would be the effect on our business if we'd just go for the standard solution.
• Question for the SAB
  What would you like to have advice on? This is mostly: advice on a customization decision.
• Solution alternatives
  Description of all alternatives that were analyzed.

Evaluation

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:

• Alignment with the solution/reference architecture
• Solution durability
• Business risk
• Manual business effort
• Customization need and level
• Development cost
• Feasibility of the planning

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.