Change – Lessons Learned

Issue 1 - Output of workstreams not always fully captured. Some teams were trying to impose the disciplines inherent in legacy systems to a new system that is structured in a different way. Workstreams captured detail in a way they were accustomed to rather in a way that would facilitate the development of the new system.

Recommendation 1 - Teams should have been exposed to the new system in its entirety for a suitable period to gain full understanding, before commencing workstreams.

Issue 2 - Between time of going to market and Project going live, the market had moved on technically in terms of infrastructure. After the tender was specified, delays prevented the system from going live for 3 years and opportunities to utilise enhanced technology were not realised.

Recommendation 2 - If there is a delay in a project, there should be a fresh stock take of technology platforms available before re-starting.

Issue 4 - A number of management changes and restructuring took place

Recommendation 4 - Handovers resulting from changes to management and resources need to be more effective and existing governance procedures should be adhered to in order to further ensure continuity amidst change.

Issue 5 - Some Service Owners were unclear about their role and responsibilities when reviewing Change Requests.

Recommendation 5 - Roles and responsibilities should be clearly set out at the start of the project. A job description should be developed for each role, and this should be discussed/explained with job holders. In addition, as roles evolve during the lifetime of the project, roles and responsibilities should be updated to ensure there is clarity and agreement on any new or amended responsibilities.

Issue 6 - Ambiguity in specifications and assumptions caused issues in terms of delay and cost with change requests during build.

Recommendation 6 - Ensure specification of requirements is robust, carefully check that the requirements and information are accurately and fully mapped to any design document prior to build commencing. Hold workshops with supplier and business area to ensure all parties have a shared understanding of what requirements are.

Issue 7 - More time would have been useful to scrutinise Change Requests, especially on technical solutions and costs.

Recommendation 7 - Sufficient time should be included in process to ensure appropriate scrutiny with expert input as required. All Change Requests should be reviewed by Contract Management Team and Change Authority Group to ensure, they are within scope of contract, have been costed in line with contract terms, represent VFM and that the Contractor solution is acceptable.

Issue 8 - Financial model was not updated when each change request was developed and when contract was extended.

Recommendation 8 - Ensure financial model is regularly updated.

Industry guidance/ further reading

PRINCE2, Managing successful projects with PRINCE2, 6^th edition (2017), chapter 11.

APM, APM Body of Knowledge, 7^th edition (2019), section 4.3.6.

Commercial Delivery Group’s Programme and Project Management hub: Programme and project change management | Department of Finance (finance-ni.gov.uk). This covers:

• Definition
• Purpose of change management
• Roles and responsibilities in relation to change management.