by The Change Compass | Portfolio management
Most organisations are implementing a series of changes at the same time. It is no longer possible to simply focus on one or two initiatives. Most are executing concurrent inititaives at any one time.
As a result, the ability of the organisation to manage a whole portfolio of initiatives will be key to landing all of these changes.
From the end impacted user perspective, it is important to be able to visualise what the collect changes look like. This collective view will provide the ability for organisations to make better risk assessments, planning decisions and mitigation strategies to maximise the benefits for all initiatives.
To read up more download this infographic.
by The Change Compass | Sharing practices, Uncategorized
We sat down with change whiz Ben Szonyi to understand his journey in deriving one view of change.
Ben is a senior change leader with extensive business improvement experience across the globe. Ben has also held program change lead roles, most recently at Bupa, where he was accountable for designing and delivering large scale, operating model change programs, which included introducing an enterprise view of change to enable strategic planning and decision-making.
Ben, tell us about what started the journey to derive the one view of change at Bupa? What was the pain you were trying to solve?
The main trigger for requiring an enterprise view of change was that the anecdotal evidence was suggesting our people were feeling change fatigue due to a large number of disassociated projects in train or on the roadmap, yet the impact on our people wasn’t a key criteria in the decision making process. To solve this we initially tried simple techniques like graphically displaying the projects we were running centrally from a program office on a Gannt style plan, however this didn’t enable us to see the change programs the business were doing to themselves. This meant at no point in time did we understood the current or future collective impact our people were facing, meaning we were at risk of overloading and ultimately failing to deliver the expected outcomes.
What process did you guys go through?
The first key step was gaining buy-in from our executive committees for the need to change.
Next, once we diagnosed the challenge outlined above, we went about investigating internal and external options for providing an enterprise view of change that also aligned to ur new change management framework. Our ideal solution was to include not only change impacts but also our peoples’ change readiness and not duplicate what was presented in existing PMO reports. Unfortunately we were not able to find this solution at the time and as a result put our focus into a pragmatic and viable internal solution that leveraged existing tools, i.e. SharePoint and MS Power BI. The idea was that once we had an internal solution made and the right operating model to support it, we would investigate more robust external solutions.
What worked well and met the business needs?
The part that worked best from an internal solution was leveraging existing tools meant people were familiar with them and they were cost effective. This also meant we had the ability to continually improve after each iteration based on the feedback of the users.
The other success was the buy-in from our business partners who were very responsive when it came to providing their data points and utilization of the reports.
What didn’t go so well?
The biggest challenge was gaining buy-in from the internal change team when it came to entering the baseline data (e.g. initiative, impact level by business area and key dates) from their detail change impact assessments as they didn’t see the benefit to them. Once they understood the benefit was for their business stakeholders, they started to get onboard.
Was there anything personally challenging from your perspective?
The most challenging aspect was the time and effort each month to run it, mainly the chasing of data and the manual effort to generate the extracts, load, analyse and report.
If you had to advise others who are about to take a similar journey what would you recommend?
With more developed products in the market now like The Change Compass, if I had my time again I would partner with one of these companies to not only get an off the shelf solution but also one that has learnt from other organisations’ mistakes. This would also mean that you could have a more automated solution. Also, don’t underestimate the time and effort required to gain buy-in from not only your stakeholders, but also your change managers/ agents by ensuring you have a clear WIIFM story.
Based on your experience, what do you see to be the next phase of development for change management?
After working in Marketing more recently, I feel that the key for change management is to treat change initiatives like marketing campaigns where you are clear about the target audience, their needs and measurable outcomes by use of data and a continuous improvement approach. The more we can make change a science and not just an art, we will gain more respect from our stakeholders by demonstrable positive impact.
by The Change Compass | Agile
The MoSCoW technique of prioritising initiative requirements or features
The MoSCoW method of prioritization is well used by Business Analysts, Project Managers and Software Developers. The focus is on identifying and agreeing with key stakeholders what are the core levels of requirements that should be focused on more than others. This process of prioritization will then enable a better outcome in focusing the efforts of the team on the most important aspects of the solution given limited time and cost.
MoSCoW stands for: Must Have, Should Have, and Could Have.
There is significant opportunity for change practitioners to also adopt this technique to better prioritise a range of different change interventions. Too often, change activities are planned as a result of stakeholder requests, and not necessarily as a result of a prioritized approach of what approaches/activities provides the best outcome versus others.
1. Must Haves:
These are core, fundamental requirements that must be there for the end outcome to be there. These are the non-negotiable ones without which the goals of the project cannot be achieved.
For example, in implementing a new system, the users must know that the system is going to replace the previous system and the reason for this. Users must also know how to operate the new system prior to the older system being switched off.
2. Should Haves:
These are features or requirements that would have a high priority to reach the project outcome. These can often be core features that will add to the user/customer experience. However, they are not a must, and given challenges in time or cost they can be deprioritized.
For example, for a new system implementation it would be highly desirable to allow the users to access a sandbox to be able to play with the features prior to the launch to improve their readiness. It could also be that due to the large number of users using the system it makes sense to conduct a large scale awareness campaign to broadcast the arrival of the new system.
3. Could Haves:
These are nice to haves given sufficient resources such as time and cost. These requirements are definitely not critical and can easily be deprioritized as needed.
For example, in implementing the new system it may be nice to have coaching workshops with users prior to the go-live to offer additional learning support for those who may need more help. It could also be various system support materials such as cheat sheets, booklets, etc. to help the user embed the ins and outs of using the new system.
4. Won’t Haves (or Would Haves):
These are potential features or requirements that may be looked at in the future if there is sufficient resources available. This is the lowest in the order of priority, meaning that it will not make significant impact to the outcome of the project.
For example, in implementing the new system refresh training sessions could be offered later down the line for some users after go live. Depending on the organization and previous experiences an ‘embedment campaign’ could also be scheduled to drive continual usage of the system. But given the cost required these are deemed lowest in the priority.
In prioritizing change management approaches and interventions this way, we are adopting a structured method of determining the activities we are investing in to get the right outcome. The clarity of which interventions are core and foundational, versus others that are desirable or nice to haves is important to the success of the initiative. This could also avoid any disagreements or questioning of the change approach further down the line as the approach follows a structured and agreed process with stakeholders.
