The common traps

I like the software as-is, but can you also do….? These questions are asked in the sales pitch. You get a nice demo from the vendor and you like what you see. But then you think about your internal processes and how you do stuff differently in your company. Every vendor will happily answer – of course we can! They know that they compete with other vendors and want to tick all the boxes with their product.
Your vendor might also be a software implementation “partner” who make their money with customisation of 3rd party products. Then later they sell you a maintenance contract to help you through ever more complex release upgrades.

You have written a long list of business requirements and now need to tick the boxes. They are very detailed but focus on implementing your current business process. Quite often they relate to either a manual process or your legacy application you want to replace. The closer the new system can satisfy your current process the easier it is to implement it and roll it out (you think!). However, you have not looked at how the new system would actually solve the business problem out-of-the-box.

Your current processes “suck”! They have evolved over time, maybe there is a good reason to run them that way, maybe not, nobody knows. What you do know is that you need to “tweak” the package a just a bit to run your process as it is. Sometimes you actually have more than one process in your company for doing the same thing. So the software needs a bit of “if … then … else …” coding to do the same step differently depending on where or who is running it. You think this could be harmonised, but this might require agreement with lot of different people, so now is not a good time.

Some other department tells you they need this change, otherwise they cannot possibly sign-off the application. You might sit in IT and the other function is your business. You are their service provider and you want to make them happy. You might think that they could change the way how they run things better, but they tell you that this is none of your business. You should be their partner, but they do not want your advice.

It is not customisation but configuration. There is a fine line between different the two types of changes, often defined by what is technically done to the product. For a customisation you need a developer, for the configuration only an administrator. However, there are heavy configurations that almost duplicate the original functionality. Those are worse than small customisations.

Photo by Rosalind Chang on Unsplash

Getting out of the trap

Go back to basics and pull out your project charter document, somewhere in the objectives you have written about simplify the IT landscape, reduce support costs, harmonise the environment. These are your strategic objectives. Your customisations are in direct conflict with these objectives. Customised software is not simpler and does have higher support cost than a plain-vanilla configuration. Start to use business language to describe the impact of customisations. Consider the long-term impact on further development or maintenance, technical documentation and also user training. With this extra information, have a discussion with the right people who have really signed up to the charter and challenge every single request for customisation.

Keep a log of customisations if you really need to do them. Capture why they were required and who signed them off. This will be your log of technical debt, things that ideally should not exist because they get you further away from your target state. Whenever there is an opportunity, try to clear off items of your technical debt.

Stay in control of the decisions and do not leave them to 3rd parties. Vendors have different objectives than your company. They live off your money. So what is complex and expensive for you to build and maintain is their revenue stream for them. Some good vendors will partner with you to do the right thing, but it is important that you keep implementation decisions in-house.

Do not start with a long list of detailed business requirements when you buy a software package. When you build your own the case might be different, but when you buy a package it often comes with a good default configuration. Keep your business requirements as high-level and abstract as possible so that the software package has a chance to fulfil it in the way it was designed. Use the Agile methodology to start with the off-the-shelf configuration as minimum viable product. Really think hard in your use case and acceptance criteria what extra business value a story or epic will add.

Review the stakeholders of your implementation project. If you need to change processes to keep your software simple, do you have the right people at the table who can make these decisions? Establish a forum of like-minded people who can help you make the right decisions for the organisation and fully understand the long-term impact of getting it wrong. In one company I established a Design Authority with appointed process owners for topics like IT Governance, Demand Management, Project Accounting, Benefits Management, Enterprise Architecture etc. who had the authority in the organisation to either request software changes or change their respective processes.

Credits and further reading