Project Management and Change: From Digital Initiative to Business As Usual

Digital projects, especially those introducing agile working or establishing new services, inherently involve big organisational change. The project manager's role shifts from a deliverer of output to a champion of sustained change and the steward of a new operation.

Managing Digital Change and Agile Work

Digital projects, such as implementing a new management platform or transforming data systems using AI architecture, are designed to introduce significant changes to how the business operates. This demands controlled change leadership, as well as great coaching abilities to support the team and end-users.

• Agile Integration: Implementing Agile and PMI methodologies can significantly boost team productivity. Agile environments demand continuous feedback loops and openness to change.

• Leading Controlled Transformation: Effective change management involves working closely with senior management to design pathways to success, implement controlled change, and gather feedback for adjustments.

• Configuration Management: Changes to requirements are inevitable. Implementing changes requires managing new versions of products or documents (such as SOPs, forms, or IT systems). For complex digital projects, rigorous document version control is vital to ensure the integrity of deliverables throughout their development and operational lifecycles.

It's not always easy. We can throw around terms, such as Agile, Lean, Scrum and many more, but when it comes to real adaptation, it can be difficult. Depending on the organisation, the industry or the project, it might be worth advocating early on: there will be changes in the requirements, the client might decide they want something else when we present the prototype, our budget is too tight, and we will need to be creative with our plan and execution, etc.

In my personal experience, the most challenges often come when rolling out internal change. When you work on a project for a client, the whole team is on board: we are bidding for a tender, building a service or trying to create a completely new product. It might not be what the client needs, wants or would be willing to pay for, but it is something we accept at an early stage and will be happy to revisit once more information or client feedback is available. However, when it comes to internal change, for example, a new CRM system or a change from Monday.com to Trello, it can be difficult. You understand the project and are excited, but there is immense resistance to change.

Efficient Stakeholder Management - Key To Fighting Resistance To Change

My professional background is ridiculously diverse: I worked across various industries, countries and cultures. I was born in Lithuania and initially started with health and social care, then transitioned into journalism and corporate communications with marketing. After a while, my career took a turn, and I went into logistics. Throughout all this time, I worked with different markets and came to realise: I need to move abroad and study International Business. So, I did - went to London, completed my degree, did an MBA in International Project Management, and bounced through a few more industries: government, MedTech and Higher Education. I somehow ended up living and working in the USA.

This personal story is to say that I've managed a lot of personal and professional change throughout my life. And it also serves to illustrate how I can now recognise (and appreciate) some patterns when it comes to rolling out change initiatives. Do yourself a favour and accept: no matter what great idea or project you are working on, there will be strong resistance:

• People will question your choices and solutions

• Customers will have strong feedback about your service

• Users will not want to shift from their preferred method/service/portal to the one you're rolling out

• ...and many more!

You can only do what you can do. But there are things that you can do - as a PM, you are always in control:

1. Start early: focus on the benefits of your project/product/service/new method.
   What is the current issue? Which people are affected? What does it mean to their personal or professional life? And what is the solution you're implementing? How long will this change take? How will this change look? What support (training, information, etc.) will be available? What will the benefits be?

2. Be constant: make yourself available to answer questions, continuously provide materials, training and regular progress reports regarding this new initiative.

3. Don't take it personally: some people will always reject innovation; it might need more effort or additional intervention to onboard them. Continue to supply relevant resources and learning support.

4. Track progress: be on top of your project, the user onboarding journey and everyone's needs.

5. Incorporate feedback: be proactive about feedback and ideas to continue the change initiative. Change is not over even when the project is over. It's a continuous process.

The Transition to Business as Usual (BAU)

A defining feature of a project intended to become a service (like the Technology Enabled Care Lifeline Service, or implementing an AI architecture) is the transition from project delivery to Benefits Realisation.

• Project Closure is Just the Beginning: The project manager ensures that all deliverables are handed over to those who will operate and maintain them. The SRO must confirm that the project is handed over to a person who will deliver the outcomes.

• Benefits Realisation Plan: A project should deliver tangible, quantifiable benefits (e.g., reducing costs, improving efficiency, complying with new legislation). The Benefits Realisation Plan is essential for determining the degree to which benefits have been achieved. This plan specifies how benefits are defined, what units of measure are appropriate, when they will be realised, and who is responsible for measurement and action.

• Sustaining the Service: Following project closure, the updated business case is used as the baseline to measure the achievement of actual benefits during the benefits realisation stage. Responsibility for ongoing compliance and operation of the service must be accepted by the appropriate parts of the organisation.

I believe that a project is only ever successful after it has been delivered, transitioned to BAU and then gone through several stages of controlled change, until Standard Operating Procedures have been saved in the system and people have accepted it as the new norm. Too often, a PM will walk away after meeting the deadline, successful and forgotten. When it comes to change-related projects, the deadline, quality and financial criteria for PM evaluation don't seem to be correct. True success lies in the ability to deliver a change initiative so it meets the needs and strategic long-term goals of the organisation. Only then can we call our Change Management a success.