How to Handle Partially Implemented Software?

By Mathias Tölken | Mastermind Digest

Aug 03

It is not uncommon that organisations buy software packages and initially only implement a fraction of the available functionality.

After deployment, business leaders often keep asking for new projects, with new budgets, instead of analyzing the full extent of what has been purchased and what else it can be leveraged for.

Considering how expensive the initial purchase was (and often continues to be due to ongoing software maintenace), this seems utterly wasteful.

How should the IT leader approach such a situation?

More...

One of our IT Leader Mastermind groups recently tackled this question. Here is a summarised version of the outcomes.

The Mastermind Answer

As with most issues, it is imperative to first take a step back and understand the situation:

  • What was the intention of the initial purchase?
  • Was the business outcome of the original project achieved despite not implementing all of the available functionality?
  • Is the further implementation still planned and has it just not gotten the required priority or is there another reason?
  • Was the additional software part of a bundle at no or negligible initial cost to the business?
  • Or have changes in the business possibly rendered the additional software/ features obsolete?

If the original requestor/project owner is still around, they would be a key source for finding answers to these questions.

Once all the info has been collected, there are usually a few options to choose from:

  • If the software or additional features are no longer needed, then the business would have written off the cost and moved on. No need to further contemplate any implementation. In this case it is imperative to make sure that any maintenance agreement for the additional software be terminated if possible to minimise/eliminate any ongoing losses.
  • If it is still the intention to use, but not in the foreseeable future, then this topic can once more be parked. In the case of any ongoing maintenance or software assurance agreement, one should investigate if this cannot be stopped or at least suspended until the software is needed. Beware, however, of penalties that this could bring with it when the implementation does eventually commence.
  • If the organisation definitely still wants to use the software, but has just not gotten around to implementing it, the deployment of additional functionality should be added to the project portfolio and be prioritised along with all other projects.

Some More Insights

  • If the implementation gets deferred, then another question that pops up on the radar is the development roadmap of the vendor. Is there a likelihood that the software will be unsupported by the time the organisation is ready to implement it? Or is there a major version upgrade on the horizon?

Pro Tip

  • There is a chance that the additional functionality can be implemented with relatively little effort. In this case the question becomes: Could this be used as a "low hanging fruit" project that could solve some real business challenge (without having to buy additional software)? If yes, this could be a key insight for kick-starting the DX journey.

Other

Picture Credit: Lexus LFA bare chassis - Tokyo Motor Show 2011 - Wikimedia Commons - cropped

Follow

About the Author

Digital Sensei | Abundance Thinker | Helping Mid-Market Companies Evolve through Digital Transformation - As trained Industrial Engineer with close on 25 years' experience as IT Professional and Business Executive in the mid-market IT industry, Mathias Tölken loves to share his experiences and expertise with others.

>