Get better adoption of new applications



Get better adoption of new applications

You may have the best specified and implemented automation embedded in your Systems. You may have driven User Acceptance Testing proving that the system supports all the automation use cases you have analyzed. Yet if adoption of the system is poor, (or as importantly), the new ways of working around that piece of automation are poor, poor results WILL follow.

Why adoption? : R=I x A (squared) 

What separates the exceptional performers from the average is NOT the quality of their strategies. It’s their ability to execute them. 

The book, Common Approach, Uncommon Results, which we wrote defined a formula that is fundamental to the way strategy is translated into action. We’ve called it the ‘Fundamental Law of Business:

Results = Initiatives x Adoption squared

What this equation reveals is that it doesn’t matter how many initiatives (projects, exercises, programmes, whatever) you throw at people if no one adopts the working practices required to make them work. A Salesforce implementation is a typical initiative. In fact, in may be part of a larger transformation initiative


That adoption is significantly important (hence adoption squared) is shown by the graph[2]. If adoption is measured as a percentage of the adoption of the organization then 50% adoption gets you 25% of the result. If 90% adoption it is 81% of the result.

But here is the critical bit – if adoption is 0%, then the result is 0 and you get nowhere.

Most companies focus a lot (or all) of their efforts on ‘I’ (Initiatives), while ‘A’ (Adoption) never gets formalised. Perhaps Adoption is too difficult to specify, and often it gets called training – and that is the first budget to be cut when the Initiative overruns. Additionally, Adoption is often left until the Initiative has been completed and is fully in place, rather than woven into the overall Initiative from the beginning. In Software Implementation terms, this is where the focus is all on configuring and setting up screens, isolated workflows and transactions, without looking at them in the context of the end to end processes they support and interact with. The same ‘Silo Thinking’ that causes such big problems in organizatons generally, can cripple a systems implementation in the same way. Capture and analyze business requirements in the context of the relevant end to end processes, INCLUDING the parts automated by your system (, SAP, Workday, Oracle….etc). Only then should you design the User Acceptance Testing (UAT) to ensure your system will produce the desired customer experience aswell as ‘correctly functioning data capture, reporting and transactional integrity.

Looking at these aspects will highlight whether the system adds value in the eyes of the users or is a step backwards in usability or ‘perceived value’ terms. It may all ‘work’, but if it adds a lot of effort and additional time to the other activities that your users have to engage in, it may simply not get used. Any amount of senior management stick won’t drive adoption if the business value and customer experience is poor. Sooner or later there are always consequences for poor implementations like these. And there are plenty of them, regardless of the underlying technology or vendor.

At a recent Software Leaders lunch, the CEO of a major financial services software company challenged us. After 25 years implementing software he said that it shouldn’t be ‘A’ squared, but R=IA to the ‘n’ where ‘n’ was a large number.

If you took a sheet of paper and write down all the initiatives, improvement projects and programmes currently running in your company. Just the ones you can think of – top of your head. Now sit down and multiply that by three to get a more accurate picture.

That is the level of change hitting your end users – every day. Not just your Salesforce [or fill in the blank…] implementation. So you really need to focus on how to drive up adoption.
You drive real adoption (and thus different behaviour) into your company by focusing on process. You have to spend time with your teams at each level in your business and define their end-to-end processes. And then you talk about how Salesforce and any other apps supports the processes. The alternative to embedding processes in day-to-day behaviour is to either check people’s work to death OR tell them what NOT to do, or a combination of both.

o       Need end users to understand end to end process  … supported by automation

o       Better usage

o       Better data quality

o       Better process improvement ideas

o       Get it right  ROI WAY better


This is where Elements Process Knowledge delivers

The core Free capabilities in the Elements Process Knowledge allows you to build all of your business improvement initiatives on a strong foundation. The power is the simplicity. A simple hierarchical set of knowledge of ‘Who needs to do What, When, Why and How’ to achieve and sustain your improvement objectives. Do it right and that is HUGELY valuable.

  • capture
  • collaborate
  • communicate

You can use Elements to capture the As-Is picture including issues and opportunities and specific business requirements for your implementation; and then collaboratively design a To-Be which takes these into account.

You can then use that ‘To-Be’ set of Process Knowledge to design process focused User Acceptance Testing, and re-use the content to drive training, onboarding and operational activity, long after the project is complete.

When you next look to improve  and upgrade the processes, you can start from a living picture of your operations that the majority of your organization has continual access to, and the ability to feed improvement ideas and observations into. In the case of Salesforce, this is even delivered directly in the context of the application, as a separate tab, or embedded into appropriate objects.

Elements for project support or ongoing operational asset?

So this is a key question. Both answers are valid and both add value, but before you simply relegate this valuable picture into the background as ‘project documentation’, think about this. Would it be valuable for your orgnization to have a living globally accessible picture of how things need to work, and who needs to do what, when why and how to get the best out of your systems implementation?

Do you use this Process Knowledge as a one-time picture for a project or do you maintain it as a living asset to support AND SUSTAIN the adoption of the business improvements?

The Process Knowledge Pro capabilities (due Fall 2016) make that easier to do and add significant operational benefits into the core capability of the software. But we have ensured that you can build the foundations and embed the disciplines in your organizational culture, whether or not you ever go beyond the Process Knowledge Free capabilities.

The Process Knowledge Governance capabilities (due late spring 2017) enable full version, release management and the authorization, review lifecycle capabilities that allow you to put Process Knowledge at the core of your operational capabilities. With these in place, you can not only drive adoption and sustain improvements, but also make your compliance, risk and management systems completely aligned with the living breathing organizational understanding of your Process Knowledge.



  • Was this article helpful ?