If we were asked to choose the most commonly ‘broken’ design principle of every HR and Finance transformation project, it would be ‘adopt not adapt’. These words even appear on RFP and ITT documents as a question against which suppliers are evaluated. Yet … lift the bonnet on many of the projects where there have been challenges of any kind and an inability to ‘adopt not adapt’ is likely to be a strong contender for the root cause.
What does it mean to ‘adopt not adapt’?
In its crudest form, it means two things:
Using as much ‘out of the box’ functionality that is provided by software vendors as possible. The level to which you can do this does depend on the solution of choice – some come with much more pre-configured capability than others, so this is an important consideration when selecting technology.
Standardising your processes and policies wherever possible. Failing to standardise as many processes and policies (note this does not mean T’s and C’s) before starting a technology implementation is an own goal. The beauty of Cloud technology and being able to configure and automate as much as possible, is severely hindered when your landscape is very complex and tailored. Stripping back any form of unnecessary complexity is an absolute MUST and should be considered as a prerequisite to signing a SaaS contract. In case of any doubt, the vendors and implementation partners will not have the time (nor capability in many cases) to do that work for you and even if they do, you will see your project costs explode!! A great example is leave. Changing the contractual entitlement of colleagues may not be realistic, especially where you have any legacy entitlements etc. But ensuring that everyone adopts the same policy (leave year, accrual rules, carry-over rules etc) and the same process (how leave gets requested and approved) is well worth the upfront investment.
Why is ‘adopt not adapt’ so important?
Doing this well has a critical impact on four significant factors:
Your ability to agree and ‘exit’ the design phase of your technology implementation. Although Cloud software is sold as ‘iterative’ and ‘out of the box’, there are still a multitude of things that you need to agree. By holding the line of ‘adopt not adapt’ and getting stakeholders to understand the value of this design principle, you will stand a much better chance of signing off a future design and moving into the next phase of the project.
Your ability to deliver a great customer service. The demands on HR and Finance are increasing all the time, as is the scope of their role. In order to keep up with demand and earn a strategic voice, there is a need for clear rules of engagements and boundaries to be set around the service being delivered to end users. Standardising the service will mean less firefighting and more focus on resolving the core aspects of service, rather than managing bespoke and unplanned work.
The impact on total cost of ownership. Whatever you design and deploy has to be supported and upgraded. The more complex the solution you have built, the more time and resource it takes to maintain.
Your ability to continually improve and innovate that service. Looking at SaaS software model as the example, the more you can restrict bespoke and ad hoc requests made of the service you are delivering, the greater your chance of being able define and control a roadmap for service improvement and innovation.
Why do challenges arise?
If you are moving from a highly bespoke on-premise system to a Cloud solution, ‘adopt not adapt’ can be particularly challenging as it will feel like you are losing all the stuff that makes your business work. Or if your inhouse team has always worked in a certain way, they may resist the thought of changing towards something that feels less familiar. Or, some of your senior stakeholders may be particularly keen on seeing bespoke services and activities across different lines of business. And a more common challenge - your IT team is keen to demonstrate an ‘agile’ approach and has initiated a ‘design from scratch’ exercise.
These are all valid challenges, and it would be rare to encounter an organisation where none of these challenges exist. The role of a transformation team is to support the HR and Finance teams to demonstrate the value of standardisation as part of transformation. It is widely recognised that ‘lifting and shifting’ from old tech to new is not a good use of time or money, so finding a solution to these challenges should be top on every Programme Manager’s list!
The answer
From our experience, there is not one answer to the ‘adopt not adapt’ challenge. Here are our top tips you can take for the best chance of sticking to this principle:
Start the standardisation conversation at the strategic level, not the process and data level. In other words, get colleagues bought in to a set of outcomes and benefits (aka a strategic vision) and work down to process and data from there. This approach gets much better traction from senior stakeholders and gets people understanding that the more you standardise, the more you are likely to deliver your benefits, which makes everyone very happy!
Present a service design and potential operating model which is ready-made for that sector and represents SaaS out of the box ways of working. This removes any need to evaluate one current state versus another – you move straight to the ‘optimal’ future state and put pressure on your business to justify why this cannot be adopted.
Remove all emotion from the debate. Where a requirement to deviate from the out-of-the-box process is identified, encourage a ‘neutral’ evaluation of this through a clear governance process that quantifies the cost and assesses any impact on benefits.
Do as much of the above before you contract with a SaaS vendor – some of these things take time and you don’t want to cause delays during an implementation while you get you business to agree to standardise.
Conclusion
Ask most organisations who have deployed Cloud technology what they wish they had done differently and ‘adopt not adapt’ will probably feature high on their list, along with a number of very valid explanations as to why this was the case. BUT … wind back the clock and start again and I expect they would all try to put this right, as the impact of getting this right is too significant, both during a project and way beyond into BAU. Putting it right is a bit of an art and requires discipline. At Veran we take huge pride in getting this right for our clients.
For more information about Veran’s SaaS Mindset™ and how to put 'adopt not adapt' in to action, click here to arrange a 20-minute chat with one of our consultants.
Comments