Ensuring success: Insights into rapid software implementations

Thankfully, gone are the days of five-year Student Information System (SIS) implementations.  The drive for competitive advantage, and the need for faster benefit realisation, means there is a growing trend of customers demanding a more rapid and agile approach to both software development and project delivery.

Several factors are now helping institutions achieve this agility:

• Access to standard tools, templates and proven approaches means you can leverage the knowledge and expertise of your solution partner
• Working to shorter project timeframes and delivering a minimum viable product means you can respond more rapidly to market changes
• Building a ‘Learn and Improve’ phase into project delivery to enhance configuration and fine-tune business processes will help deliver greater competitive edge
• Taking advantage of remote delivery teams as a cost-effective way to access the right resources to meet tight project schedules
• Adopting a methodology that is scalable, embeds change management, and business benefit, will ensure long-term success and return on investment
• Working with a solution partner that understands the sector and its business processes will help deliver business outcomes, and not solely a software product.

Why use a standard approach as a starting point?

Configuration (the ability to build almost any requirement) is becoming a double-edged sword in a world where we all understand the benefits of:

• using a standard approach to software implementation to ‘get across the line’
• focusing project resources on filling the gaps between what the software offers and what your institution needs to meet business outcomes and provide a holistic solution
• leveraging core functionality of new systems before implementing new ideas
• sticking to implementation timeframes for faster benefit realisation
• not wasting time, money and resources on deviating from standard process when there is no business case to do so.

That’s why most software solutions offer components that are out-of-the-box, with some vendors offering to share ‘last-best’ or pre-configured standard templates that you can plug in or build upon. Whilst adopting a standard approach will only work if your institution is committed to this method, using the industry standard as a starting point is proven to get you a long way – faster. And if the project creates design principles that are about leveraging existing functionality and redesigning business processes – you may even achieve more ambitious implementation timeframes.

But do you really want to deliver a Minimum Viable Product?

Whether we think of this as implementing the ‘critical path’ or a ‘minimum viable product’ (MVP), the aim is to leverage the core functionality the vendor has available, so you can go-live sooner.  Large-scale software implementations like SIS are known for long implementation timeframes, running the risk of requirements changing before the solution goes live and long lead times for benefits realisation.  Not to mention the additional costs if the project doesn’t manage to meet its planned go-live date.  Agile project management focuses on faster deployment of a MVP followed by a phase of rapid incremental learning based on feedback from users to further improve the product.

The catch here is go-live is not the end of your project journey.  Sure, a part of the project team will need to transition to BAU operational support to ensure software stabilisation.  But the most successful projects will have a defined project phase (and budget) following go-live focused on learning and improving the solution.  This is when you can make informed decisions on where further project investment will deliver the greatest business benefit.

Project communication is key (because Minimum doesn’t sound very appealing right?)

Coming from a change management background, selling the concept of a minimum viable product to business users can be pretty tough.  Who wants the minimum?  Is it really minimum? Why are we changing if that is all we are aspiring to achieve?  It’s our job to sell them on the vision and get users excited about how after the pain of transition, the new solution will bring benefits to staff, students and the institution. So we have some explaining to do.

For some business users MVP will mean a like for like transition, so it may be difficult to get their buy-in.   There needs to be clear messaging from the project sponsor and project team around scope and the aims of each phase of the project, so people understand when they are likely to benefit from the change.

But let’s be clear, MVP is not simply like for like across the board.  There has been a case for change, most of it usually focusing on regaining a competitive edge. So MVP will still be a step-change for many areas of the business, and it is important to showcase new functionality and business processes to give people an idea of what is possible going forward to get buy-in to this phased approach.

There may also be small pockets where years and years of bespoke development in a legacy system means it is not practical or cost-effective to develop the same functionality for MVP.  The project and change team will need to work closely with business users in these areas to design business processes and explore new ways of working in the new system to meet their needs.

With a focus on getting a MVP solution across the line it can feel like there are missed opportunities to re-engineer existing processes and make more transformative change.  However, projects that attempt to undertake transformational change at the same time as the implementation of a new software solution are rarely successful.  Therefore, this delivery approach with a distinct ‘Learn and Improve’ phase, is proving to be a safer and more successful incremental journey for our customers.

Is this approach right for you?

A good starting point is assessing how far from standard industry templates your institution is willing to vary, and what that will mean in terms of time and cost to the project and ongoing maintenance down the line.  Understanding where variation will bring competitive advantage will help you promote the case for change in the areas that will bring the greatest business benefits to your institution. To help support your decision, speak with your vendor and understand what they have available that can help fast-track your delivery path.  If you adopt this approach, ensure the business understands MVP is not the end goal but a step in the overall project delivery to ensure you get their buy in… Good luck!