Vivify Labs BLOG


Do Business Systems transformations always have to be so hard?

Written by 

If you are looking for a quick way to kill a conversation; try asking a friend or colleague how their latest internal IT transformation project is going at work?  Don’t be surprised to see them break out into a cold sweat and visibly age in your presence as they describe an experience that is akin to getting a tooth pulled out by their dentist.

This blog breaks down some of the reasons why these projects are difficult and also offers some suggestions on how to set up internal Business Systems transformations for success.


It’s hard because it’s complex... 


I’ve found that the difficulty of IT projects often correlates to the complexity of relationships and the number of stakeholders that rely on that system to perform their job.

Let’s consider a very common Business System application that is used by the majority of medium to large organisations; the Customer Relationship Management or CRM system. 

This application is often originally implemented as a tool to assist the Sales & Customer Service departments, however, it is not unusual for a CRM to evolve into the engine room of many organisations with functions such as (Product, Pricing, Finance, Marketing etc.) becoming heavily dependent users. I recently worked with a company that had 50 plus (system and manual process) integration points linked to it’s CRM system.

When we break down the number of internal functions and stakeholders that rely on the system that we are trying to transform, it becomes easier to understand why these types of projects can be difficult.


Breaking down barriers


One of the key lessons that I have learned from being involved in many of these types of projects is the importance of ‘shared responsibility’ from the inception phase all the way through to the final stage of delivery.

When the going gets tough in a transformation project, which is inevitable, the default often falls back to blaming specific departments within an organisation. When this happens don’t be surprised to hear comments like, ‘This is an IT initiative, we don’t really know what is going on’ or ‘Sales should be driving this project, why are they not involved?’.

There is simple way to overcome this dynamic, you can break down the barriers by assigning the responsibility of delivering the project to a cross-functional team with representation from the critical stakeholders that are dependant on the solution.


Importance of stakeholder engagement


I believe that full-time engagement from key subject matter experts (i.e. Sales Account Managers, Customer Service Specialists, e-Marketers or Commercial Analysts) is a critical ingredient for a successful project team. And just in case you were wondering, full time engagement does mean a complete divestment from normal day-to-day responsibilities.

Back filling roles or trying to cover the absence of an SME certainly causes some disruption and comes at a cost to the business, however, my experience has been that the benefits far out way the downsides every time.

Benefits can include:

  • Higher levels of engagement and understanding within the project team (another tick for shared responsibility)
  • Enables ‘just-in-time’ decision making which reduces cycle times and removes much of the frustration around waiting on email responses or scheduled decision forums for progress
  • Improves the team’s collective resilience and resolve when they are faced with ambiguity or setbacks

If any business is still unsure if these benefits stack up; then I’d ask them to consider the cost of not allocating their best SME’s to these types of projects. Particularly if transformation project budgets extend into several hundred thousand or even millions of dollars...


Owning the vendor relationship


Another trap that I have seen companies fall into is the ‘vendor led’ project. I firmly believe that organisations must make the time to clearly define their high level objectives and scope before engaging their preferred vendor.

Firstly, these types of inputs are very useful in determining whether specific vendor solutions are right for your business during the due diligence stage. Secondly, it empowers the project team to take responsibility for managing expectations with the vendor to ensure that the solution aligns with the underlying business needs.

Conducting a series of project inception workshops, with the purpose of engaging all of the relevant stakeholders, can be a brilliant way to reach consensus on the high level objectives and scope.

Project inceptions can be used to:

  • Create a shared vision on the reason for the project
  • Define scope
  • Incorporate user understanding
  • Process analysis
  • High level requirements
  • Build out initial project team (required skill sets)
  • Foster shared responsibility
  • Provide an early indication of solution design
  • Define initial project plan, release plan and indicative sizing


The dangers behind trying to implement 'current-state' processes with a new technology


Plumbing broken processes into a ‘brand new’ technology solution will inevitably lead to a much more expensive version of the same problem.

I’m not advocating that companies need to engage with unnecessary wholesale ‘process re-engineering’ activities, however, there is always an inherent danger of perpetuating the past if a project team blindly follows a ‘current-state’ replication strategy.

One of the key advantages of implementing a leading CRM system is the opportunity to take advantage of integrated modules and native workflows that can automate common business practices such as (Sales Pipeline Management, Case Management, etc) 

The key here is to keep it simple, if an existing process is working for the business and can be automated into a native workflow within the new solution then that’s a big win. Any time that you can achieve a requirement via configuration over customisation you reduce the ongoing support overhead for your IT teams.   


Favouring lean delivery practices over ‘big bang’ implementations


Pursuing a lean delivery strategy is possible with Business System transformations/implementations.

Whilst it may not be possible to set-up a continuous delivery capability that can release individual features via an off-the-shelf vendor solution, it is certainly feasible to deliver phases or modules of functionality across the duration of an implementation project.

Smaller production releases, that focus on delivering meaningful functionality to the business early on in a project, provide opportunities for fast feedback loops from users and the opens up the option to incorporate iterative improvements into future releases.        


To conclude, I hope that this blog offers some insights and techniques that might prove to be useful for those that are engaged in Business Systems transformations.

At Vivify Labs we are passionate about helping organisations achieve their objectives. Drop us a line to see how we can help you shape and engage the most appropriate strategies for your transformation.

Login to post comments




Vivify Labs are active in the social media space. We have a presence across the broader social network in which we regularly post updates and information on our business as well as the digital landscape in general. We'd love for you to follow us and engage on our journey.

  • trance

  • techno

  • synth-pop

  • soundtrack

  • smooth-jazz

  • rock

  • rap

  • r-b

  • psychedelic

  • pop-rock

  • pop

  • new-age

  • musicians

  • metal

  • melodic-metal

  • lounge

  • jazz-funk

  • jazz

  • index.php

  • house

  • hip-hop

  • heavy-metal

  • hard-rock

  • get.php

  • electronic

  • dubstep

  • drumbass

  • downtempo

  • disco

  • country

  • clubdance

  • classical

  • chillout

  • chanson

  • breakbeat

  • blues

  • ambient

  • alternative-rock