Change is often bigger than it seems

18th January 2022

Change is often bigger than it seems


In the fast-paced and ever changing world that we live in, organisations seem to be in a perpetual state of change. Quite rightly, executives focus on understanding (and pre-empting) their markets, deciding a course of action, and adapting quickly.  When ideas are raised there is often an urgency to get them implemented, not least because good ideas often sound so simple.  I mean what could be simpler than “implementing a CRM package” or “upgrading our current ERP system”.  Surely these sorts of efforts should be done and dusted quickly, particularly if off-the-shelf solutions are adopted? 

Some readers will undoubtedly have a wry smile on their faces as they read this, as these types of projects are often far from simple.  So often additional complexity is discovered during the implementation that was just never foreseen. Let’s take the example of “implementing a new CRM package”.  Technically, assuming we have people with the right skills on hand, the implementation is probably a fairly straightforward thing to do.  If we wanted to use a software-as-a-service solution (rather than hosting it in house), it’s probably something that just about anyone with a credit card and a web browser could do.  Yet buying the licences and getting an ‘out of the box’ implementation is only the first step in a much longer set of tasks… just deploying something doesn’t mean it’s in any way actually usable or useful!   The change needed is often bigger than it first seems, and this is where the question of value comes in. 


Understand What Value Is Sought 

It’s important to avoid change for change’s sake and for falling into the trap of solutionising too early.  Perhaps you’ve seen this in your own organisation: a new technology is implemented which promises everything but actually somehow manages to make things worse.  This might be because insufficient attention was paid to what different stakeholders actually find valuable. 

Let’s take the example of an expressed need to “implement a new CRM package”. Arguably,  this is a proposed solution approach, rather than an actual expression of what stakeholders need.  If we spent time asking different stakeholders why a new CRM package is seen as desirable, we might find that there are different views: 

  • Sales director: I want to maximise sales revenue & increase customer retention 
  • Regional sales manager: I want to know which of my sales territories are performing well or badly so I can take action to maximise revenue 
  • Sales person: I want to do my job quickly and without the bureaucracy of the current system which slows me down 
  • Customer: I want the salesperson to know my history and have information on hand so ordering is easy. 

For each example stakeholder we now have a high level statement of desired value.  Of course in reality we’d need more investigation and these are deliberately concise examples, but I’m sure you get the gist.  By understanding different perspectives we can ask the question “is a new CRM package the best (or only) way of meeting these needs?”.  It might be that there are different solution options that are open to us, perhaps some that are cheaper, quicker and slicker. 

If a new system implementation is the best option, we can ask “what other business changes are needed (other than the IT implementation) to meet these sets of needs and achieve these outcomes?”.  Building on the example, if we need to maximise revenue, increase retention while also meeting the needs of the other stakeholders we probably need to: 

  • Integrate the CRM package with other organisational systems, so there’s one ‘source of the truth’ 
  • Ensure it fits well with the organisational processes, which will likely involve adapting existing processes so that they work well with the new system (as well as configuring the new system so it fits well within the organisation) 
  • Configure the new system so that the user interface is clean, clear and that it’s a breeze to use for the salespeople 
  • Ensure it can be used remotely (on a mobile phone connection) for those who work in the field 
  • Work out what backup, disaster recovery and other considerations need to be taken into account 
  • Assess what user support and training is needed, and what type of communication campaign is needed more generally 
  • Ensure there’s a clear roadmap so that people know what is coming when 
  • Put in regular reviews to see if processes can be improved 
  • … and so much more 


Bigger Doesn’t (Necessarily) Mean Slower 

It’s important to highlight at this point that while the list above might look daunting, well-planned change doesn’t have to be slow.  It can be delivered incrementally and iteratively, perhaps certain features are rolled out to specific users first to get their feedback.   

The key is to ensure that the change is adequately planned, and that unintended consequences are avoided.   Understanding needs, and ensuring that the solution is aligned to them, will avoid later misunderstandings and conflict.  A small investment upfront can clear the way for acceleration downstream. 

In conclusion, change is often bigger than it first appears.  Yet downplaying the size will only lead to problems later in the change initiative, so collaborating with stakeholders early to understand this will pay significant dividends in the long run. 

by Adrian Reed, Business Analysis Expert