Shared services programme: phase 1 programme closure report

5.0 Delivery challenges and lessons learned

Organisations of the scale and complexity of the Scottish Government and our shared service customers are reliant upon core systems and services that are key to the effective operations. The management of our people and the money that the Scottish Government is responsible for is right at the heart of effective organisational management and it was clear that our legacy systems were aged, moving out with support and not future fit. We needed to change and invest in capabilities upon which we can build and move forward with as an organisation thus we put this programme forward as an operational necessity.

Programmes of this size and complexity are infrequent in large organisations. Many HR and Finance professionals will only ever experience a major system change once or twice in a career. Our colleagues are not regularly asked to embrace internal operational change at this scale, and thus it’s not a ‘muscle’ frequently exercised in every part of government. Whilst the Scottish Government has run and delivered many IT projects over the years, this specific set of deliverables haven’t happened before. This was a novel programme, with new cloud software, new processes and delivered post significant growth in the organisation. Whilst the lessons from other programmes both within and external to the Scottish Government of course offer guidance, the estimation of this programme was challenging because of the unique nature of it.

Below are a number of lessons that we reflected on as the programme progressed through its different stages.

Insights that can be applied to improve the planning, management and delivery of other future projects/programmes

1. The preparation of the business case and the estimation process Whilst the team that led on estimation were experienced ERP delivery professionals, none possessed all the information necessary for more accurate estimation. The novel nature of this programme meant no-one had all the pieces, to reach realistic estimates for costs in particular. Accurate estimation required the team to have a detailed understanding of the scope and requirements, detailed software and product knowledge, awareness of the Scottish Government’s policies, a clear picture of the changes required in the organisation to make it cloud software-as-a-service ready, and crucially, a deep understanding of the scale and complexity of the change management elements of the programme. The Scottish Government has not undertaken a programme that touched so many people and processes, across so many organisations, at this scale before. All the pieces of information necessary were not available, and thus optimism bias significantly influenced the initial estimate. The experiences of other organisations, with smaller and simpler (in hindsight) implementations unduly influenced our estimations. Readying 20,000 users, across a broad panel of organisations and professions was also under-estimated. Again, such a change would be incredibly rare, and there was insufficient understanding of what it would take to land such a change in the community of users.

2. The programme team size and skills required The team was initially too small and was not able to move all workstreams forward at pace and in parallel. The sequence of the work thus was sub-optimal, and caused time delays at various points in the programme. Testing preparation started too late for example, due to a failure to hire the testing team early in the life of the programme. Acquiring enough of the skills necessary was also challenging. Programmes of this type thrive on deep experience earned on previous implementations. It takes time for all parts of the programme team to build a shared understanding of the process of change, the steps and stages to work through and to build confidence to commit to requirements, test plans etc. Programmes of this scale and nature are training grounds for many, even while drawing heavily upon the partnerships and supplier arrangements put in place to form the core of the delivery team. The programme is also reliant upon the skills and capabilities of ‘business’ resources – HR and Finance professionals. These colleagues of course often have other roles and competing pressures and can’t easily be released for full time project work, as they in turn are not easily replaced. Should the need arise again, more preparation to support the release of business experts to focus full time on project delivery, and the building of effective delivery teams from the outset are recommended.

3. Central design versus wide requirements gathering When working with such a diverse group of users, across multiple organisations, there are two choices when it comes to the gathering of requirements and building a design. Option one is to design centrally on behalf of all. Option two is to consult widely, build consensus and negotiate your way to an agreed design. The latter of these strategies creates variance, upgrade challenges and adds maintenance costs for all. Option one was chosen, because all entities already shared a common legacy platform, thus proving the point that a common system could be made to work for all. It was known of course that some requirement and bespoke needs of some users may be missed, with the intention of remedying the matter post go-live. What has proven difficult post-go live is a clear separation between genuine difference or need, versus preference. The delivery of Oracle set expectations high, and the central design has not always met those expectations. Indeed, there are gaps, and some sub-optimal processes to be addressed. The non-Scottish Government organisations have many enhancement requests that if all fulfilled, would drive greater levels of user satisfaction, but also variance and potential maintenance issues. Finding the right balance between central design, standard processes and broad buy-in is challenging, and we continue to work with all users to find the optimal way of working in some parts of the system.

4. The timeline and effort for key tasks affected the overall timeline

Throughout the programme we were making judgements about how ready we were for going live, and how we compared to specific readiness indicators. We took a very diligent approach to assessing our risk and confidence levels against hundreds of criteria. We delayed go-live on several occasions, as our scorecards indicated it would be unsafe to do so. We balanced the quality of implementation against the time and costs to achieve a safe go-live. Senior stakeholders came together regularly to review the criteria for go-live, make judgements and consider the risk and reward of delays versus proceeding. Once you commence a programme of this nature you must get to the end. Going live is a new beginning, and an opportunity to push a reset button on the risks, issues and actions logs, and plot your route to what is considered optimal over time. The team was confident that we found the right balance when we went live in October 2024.

The preparation of a new chart of accounts, that would work for all users and organisations was a very significant task that significantly influenced the overall timeline. The task of building the chart and checking that the structures would work for every entity was a very time-consuming process, with many iterative cycles. This process in turn affected the timeline for configuration and development, systems testing, data migration tests, user acceptance testing and report writing. The key learning point is that the work on the chart should have started very early, and before the team scaled up the development work. The production of the chart was always on the critical path and ideally would not have been.

5. Change management and training Change Management was given its own workstream and team within the programme. We recognised the scale of the challenge and the need to invest appropriately in the capabilities that would help prepare our people for change. Approx 20 Full Time Equivalent colleagues (FTE) were dedicated to this agenda, but it also pulled many business resources with subject matter expertise into the process of change, to run workshops, learning events, and training courses. We worked with our Systems Integrator to build a suite of e-module training courses (ready approximately six weeks pre go-live), and ran on site training courses for some HR and Finance professionals. On reflection even more would have been helpful. Colleagues across the user base regularly requested access to a ‘sandpit’ environment to build familiarity ahead of go-live. Technically this is a challenging and expensive thing to do if it is to be useful. We opted instead to run ‘model office’ sessions that were designed to give some users hands on experience with a near production-ready system. Whilst this was useful, we should have started earlier, and completed more sessions. If we were repeating this exercise, investing (at greater cost) in a sandpit environment may well be appropriate. This would have helped reveal the operational demands of managing features like ‘position management’ for example, which has been a significant change in how we manage resources within the Scottish Government. One of the challenges of delivery e-module training is that SaaS products change regularly. We were building training courses (with static screenshots) that at the point of go live didn’t always reflect what you saw on screen. Again, the maintenance burden of syncing training materials and systems was challenging and incurred additional cost. Our investment in Oracle ‘guided learning’ has proven to be effective. These always available, context-specific help guides are used often and the maintenance is effective. We would choose to do more with guided learning, and move further and faster with this approach in a similar initiative.

Other programme-specific lessons learned

6. Supporting the platform Our legacy systems had been in place for approximately 20 years. They were unchanging generally speaking, and thus there were high levels of familiarity with what they could / couldn’t do. Whilst there were many issues and frustrations, colleagues knew how to work them. The new systems introduced new data structures, new processes, new interfaces, new notifications, and the concept of self-service. The system revealed data and inaccuracies, or out of date data, that previously users could not see. The data migration process was a success, but it still generated some anomalies for some colleagues due to specific circumstances. Migrating data from an old structure to a new structure will inevitably result in some support needs. We know now that the Oracle Time and Labour module within the system had / has technical issues that have been very difficult to diagnose and resolve. We are, in January 2026, still working with Oracle to address these issues fully.

7. Data management & quality Bringing two entirely disparate datasets together, that had for 20+ years been separate, created additional challenges. We can see now that there was much to learn and co-create when it comes to the chart of accounts, cost centre structures and HR organisational hierarchies. These perspectives do not always align for many valid reasons. We could have done more as a team to explore these data structures holistically, to avoid some of the post go-live data improvement challenges. Integrated data is of course one of the key benefits of this platform, and we can see that increasingly evidenced in reports and outputs, but there were opportunities early on in the delivery of the programme to get all data structures right that weren’t fully exploited.

8. Role Based Access and Controls The system embeds many role based access controls, approval groups and data structures for the purpose of good governance, security and fraud prevention. The system is designed to embrace the recommendations of auditors and good practice. These controls function well, but for some the controls may appear complex and difficult to navigate in small business units. Understanding the many role profiles in the system, who can do what, and how to manage that landscape operationally takes time. Smaller organisations in particular find this challenging as they may not have all of the people / roles necessary to create the segregation of duties the system expects. We can see too on reflection that some role profiles may need tweaked, to offer greater levels of self-sufficiency (business managers for example) whilst maintaining appropriate controls. Fine tuning the role based access is key to maturing the system post go-live.

9. User experience optimisation The software allows for a great many individual settings, process designs and ‘journeys’ which is Oracle’s way of helping set up guided processes for common people related activities. During the project we fine-tuned many pages, and addressed many accessibility concerns. This work continues post go-live with the benefit of broad use and customer feedback. Some journeys are not yet easy to use and will benefit from optimisation. The software changes a lot during the life of platform, as a result of the many quarterly upgrades. It was unfortunate that the ‘Redwood’ changes, which were considerable, landed during and soon after go-live. Oracle continues to develop the software and user experience, and we continue to optimise internally. This is a journey of choices, lived experience, reflections and iteration towards optimal.

10. Data extraction / insights generation / reporting One of the most powerful benefits of Oracle Fusion is the data insights that it can yield when live, optimised and embedded in the organisation. The programme took us so far along the path towards an integrated and coherent overall data structure, but more has been done post go-live. We didn’t understand sufficiently the relationships between different ‘master data’ sets. Since go-live we have created a master data management team who now have robust control and change management processes in place. In preparation for go-live hundreds of reports were produced and tested. These met many basic operational needs. There wasn’t capacity to go further, and nor were we ready to, pursue richer management information reports and dashboards. Work here is ongoing. Colleagues across the user base continue to request reports and reporting tools (of which Oracle provide many). Some have a steep learning curve, which the organisation was not ready to take on at go-live. Some require confidence in the chart of accounts and master data management structures before use. We have a lot of focus now on data extraction and analytics. Our ongoing work in relation to EPM is linked to this, as is the business as usual data and analytics team who are developing a deep understanding of the data structures, and reporting tools available.

Looking ahead there is work to do to embed self-service, optimise operating models, drive system adoption, enable the distribution and utilisation of extensive management information (MI)/ data insights and generally leverage the platform. Achieving this will require some focus on leaders, and leadership behaviour, to ensure that we do not work around the system and capabilities, but that we constantly ask more of it. The data within the system is the biggest asset, and that data needs to work for the organisation. That requires everyone to make a contribution.

Best practice

During the lessons learned workshops we also took the opportunity to identify specific examples of best practice, highlighting aspects of the programme delivery what worked well. These have also been retained for the use of future programmes.

At a programme-wide level, the following were some of the key examples provided.

Delivery method

• The decision to conduct a high number of data migration (DM) cycles allowed us to improve through repetition and achieve better cleansing of data. This in turn enable us to increase confidence as we progressed through the cycles.
• Early set up of the Data and Analytics team within the Corporate Hub, and its hands-on involvement with the production of reports and letters, facilitated good knowledge transfer from our system integrator and created an early stand-alone capability.

Planning / ways of working

• The dress rehearsal for implementation was an excellent exercise to ensure the cutover went well. Valuable lessons were learned which enabled the live cutover to proceed according to plan. A dress rehearsal for the support model, specifically having everyone in person, was also a useful exercise. The opportunity to come together in the same room for many of the programme was very powerful in terms of increased collaboration, as well as undertaking the dress rehearsal objectives.
• The decision to have a Process Owner and Process Champion presenting the process and policy sides, as well as being the stakeholders who would sign-off decisions, largely worked well. This approach also paid dividends when there was a requirement to co-design and delivering workarounds.

Managing / involving stakeholders

• Using full time SMEs (and increasing their number through the development and testing stages) and temporarily backfilling their operational roles, meant we had very little impact on HR business-as-usual (BAU) operations, whilst also building skills in a core group of super users.
• Model Office was a useful exercise (where feasible) to ensure key stakeholder groups had a good understanding of the new system and become familiar with the changes in advance of go live.
• Regular Business Readiness Assessments for every organisation provided structure and discipline around stakeholder engagement and planned programme activity.