What tools do IT managers need to successfully manage change?

As well as routine project management and IT programmes, IT managers are often tasked with the people elements of change – an implementation can’t be seen as successful if there is no user adoption.

So what do they need in order to make sure this goes smoothly?  IT managers need practical tools that will be sustainable for future use. As all change is unique and needs people to truly own it, all guidelines and templates must be flexible and adaptable to help engage people and enable them to put their own stamp on a project.

Here are my top ten products and tools to support IT managers:

1.       Change readiness assessment

There are questions to ask around how ready the business is for a particular change. How likely are the current culture and patterns of working to lend themselves to adoption of the new process or technology? What barriers may appear in the organisation?  Readiness assessments allow us to baseline our change capability within an organisation, or a part of an organisation. Readiness assessments can be repeated at various points up until go-live to measure the effectiveness of the change management we have implemented.

Take our sample organisational change readiness assessment

2.       A change readiness dashboard

The change readiness dashboard will collate the various readiness assessments and report them as a whole.  Through a readiness dashboard we can assess if our change management approach is being successful

3.       Change impact analysis

This is a template that allows us to overlay what the change is, with which user groups it is going to affect.  We can build on this to determine how we best support for those groups.

4.       Stakeholder mapping templates

A means of identifying and classifying key stakeholders according to their influence and relevance to the project. This can feed into a stakeholder management plan.

5.       A process for co-creating a key message framework

As well as the key message framework, you’ll also want to co-create the core story with key stakeholders.

Read our blog on the impact of storytelling on your change programme

6.       An adaptable communications strategy

Your communications strategy will need to be adaptable and flexible enough that it can be applied to different functions/areas to ensure it reaches all corners of your stakeholder matrix.

7.       A guide for line managers to support their teams throughout a project and beyond

You will need a guide for line managers to help them support their teams, and you will also need guides for sponsors and change champions to help them fulfil their roles. This includes ideas for sharing success, communicating at different levels, setting example behaviours, gathering and monitoring feedback, and answering questions. The guides should support the change network to reach the heart of the business, to prepare people and embed a number of changes in behaviour. And, thinking back to sustainability – these guides are inherently reusable.

8.       A sponsor roadmap

The roadmap needs to provide a  framework for the change project, and set out how the sponsor can support the various project teams and stakeholders, as well as how the project manager can use the sponsor to effectively deal with resistance and challenges.

Here’s the Prosci take on the sponsorship roadmap

9.       The creation of sustainable and highly relevant communications materials

Sustainability for any team faced with implementing change, really means three things here: 1 Boosting long term skills. Once a team goes through the process once and has coaching, the process becomes repeatable. 2 Tools should always have a long life-span for example a video should be reusable. This means every item has to be produced with sustainability in mind: ‘where can we use this elsewhere?’ ‘What would need to come out to enable multiple use?’ And 3. Adaptable templates for items such as emails and newsletters can all be used again and again by an IT manager or change team, to create materials for new projects.

10.   The development of a one-stop portal

often developed in SharePoint, the portal will house everything people need to know about the new technology, with individual learning pathways that can be tailored and updated for new projects.

 

We’d love to hear your thoughts on the ten points above. Are there any more elements you think could be added? Let us know in the comments below.

Agility – moving beyond the buzzword

Why adopt an agile mindset?

A lot of our clients appreciate the benefits of adopting an agile mindset, as well as agile working practices.  And this makes a great deal of sense, after all, we’re living in an age of major business disruption and innovation.  Modern business must deal with a plethora of challenges, from regulation, compliance and new technologies, to the economy and exploitation of big data.  Most of these challenges can also represent opportunities, if you’re in the right shape to take advantage of them.

This led me to think about how organisations message around agility (agility in terms of organisational culture and mindset, not Agile Project Management – although these two concepts are most definitely not mutually exclusive), and how they ensure everyone is on the same page with regard to what it actually means to be agile.  Agility can often be seen as an abstract concept that is not grounded in the operational reality of an organisation; I often hear conversations around agility along the lines of, ‘but what does it really mean for us?’ Or ‘agility means speed over quality’.

 What does agile really mean for an organisation and its people?

Agility does not mean unplanned or risky, quite the opposite in fact. The goal is to be nimble and flexible – ready to pounce on opportunities, or to change course to avoid inevitable problems. To be agile, an organisation and the people within it must have a clear goal in mind with waypoints to check if the plan is on target.

Here are five principles to help you convey what agility really means in the context of your organisation:

  • Stability – to be agile and adaptive the organisation and its processes must be stable. That is stability in the sense of the organisation’s propensity for flexibility, reliability and resilience.  This is where stability and predictability should be seen as enablers for agility – many large organisations have these attributes – use them to your advantage.
  • Flexibility – this is the ability to course-correct mid project/initiative or in more extreme cases to change direction entirely.  This requires people within the organisation to accept that, ‘what was right then may not be right now’.  This is where the real mindset and behaviour change comes in, so take time get the right message across.
  • Speed – a primary benefit of agility is the speed with which things happen, while maintaining the quality of output.  This could be getting a new drug to patients, taking advantage of an emerging technology or an untapped market opportunity.  This is an output of an agile organisation, not a personal trait to ‘do things fast’.  It comes from a stable base and flexibility of mindset.
  • Culture – think about the culture of your organisation.  How do the behaviours and accepted norms fit to the principles of agility?  Tune in to those cultural aspects that align with agility and think carefully about how to message around those that may be in conflict.  This is not insurmountable and can be achieved by following a process to find the answer which is right for your organisation.
  • Get creative – we know that the best messages are ‘sticky’ in that that they are easily communicated, get re-used and tell a story.   A great way of achieving this is to represent your agile story visually.  With clear and concise thinking, which is represented with a visual identity, you will get a better spread of awareness and desire to engage with these new agile principles.  Check out our blog post on The Impact of Storytelling on Change Programmes.

 

In summary, the only way an organisation can adopt an agile mindset is when all of its people truly understand the principles of agile, the advantages to the business and the benefits to them as individuals.

 

If you have any further ideas on what agile means to you or your business, or experiences of how you or your organisation adopted an agile mindset, then get in touch via the comments below.

How does change management fit with project management?

There is, understandably, some confusion about how change management activities sit alongside project management.

After all, project management provides for comms and learning, so what’s the need for additional change management?
Looking at the success rate of projects, we can see there is great additional need for a structured approach to managing the people aspect of change.

Working at portfolio level – transformational change

This looks at projects from a portfolio, organisational perspective. If your organisation is faced with complex transformation, involving multiple projects, typical project management activities around comms and learning will not be enough to steer the organisation’s people towards a desired future state – efforts at the project level will simply be too fragmented. Change management allows for a portfolio top-down view of the way in which a business’s people will move from the present state to a future desired state.

Designing change with people in mind

At the beginning, project management includes a focus on initial stakeholder analysis, mapping and communications planning. However, change management goes further to plot the impact of the change/s on the organisation and teams.

This is the important part, without the buy-in and engagement of the organisation’s people, the project is likely to encounter negativity and push-back, with project managers spending precious time fighting fires and rescuing relationships.

The change management team will get to grips with the culture and beliefs of the different teams involved, understanding that potentially, each of these groups have their own unique attributes and preferences.  Feedback will be gathered directly from people on how the proposed changes could affect them, and how their day-to-day working may be impacted.

Building this initial picture and understanding of the organisation’s teams is the first step in a structured approach to the people aspect of change. Next the change management team will carry out impact analysis, change readiness assessment, and initial stakeholder research in order to outline a strategy to manage resistance and fulfil communication and engagement roles.

Factoring people in at the beginning means that barriers to adoption can be clearly identified and proactively dealt with.

Adding depth to the delivery of change to people

Articulating the reasons for the change, from a people and business perspective, comes directly from having the above people-focused approach to planning and strategy. A clearer vision comes from conveying the wider context of change and what that will mean for people. The story of why the change is happening is given a broader strategic level context.

From that it is easier to produce the blueprint for a visual identity, and a set of messages that create impact for teams and individuals. Inspiring people with a story, the context for the change and what it will mean for them are all made possible by the more structured people-focused planning and strategy which is afforded by change management.

Further, change management activities create a network of local support during the project delivery. Change champions are equipped to communicate and endorse the change. Special attention is given to line managers, sponsors and this change network to enable them to fulfil the goal of not just pushing messages out, but receiving input and monitoring how the change is being received and adopted by people.

An IT manager may deliver change focusing on communicating the benefits and training people to use new technology or process. However, change management process takes this further. Feedback and response mechanisms are formalised and structured.  It provides coaching for senior leaders and sponsors on how to identify the root causes of resistance and how to engage and manage resistance when it happens.

Read our article on managing resistance to change.

Training becomes another opportunity to engage with people and obtain their buy-in and genuine participation. Change management activities relating to training focus on how it can be made more interactive, designed for feedback, and feature the organisation’s people in the delivery – all with the core messaging throughout.

Post implementation we find that change management’s people focus means that people are rewarded and acknowledged for their adoption of the new, reinforcing the change after ‘go-live’. Feedback from people improves process and ensures the changes adapt to meet their original goals.

Five principles of good project governance

When running large change programmes, good governance is what will protect investment, provide assurance and give control to the organisation whilst allowing the project teams to get on with the job in hand.

Less effective governance often occurs in two extremes; either the organisation forces projects to adopt exhaustive measures and assurance reviews which burden the project and increase resources or at the other end of the spectrum projects start organically, occasionally pushing out progress reports to a few stakeholders and are generally viewed with suspicion by their organisation and struggle to get decisions made.

So how do we get the balance right between the bureaucratic stranglehold of the organisation and the renegade project?

We want to suggest 5 key focuses for effective programme governance:

  1. Integrated planning: ensuring projects are well planned will be the foundation for progress reporting, but can also hardwire the discipline of talking to other workstreams and projects by integrating plans and tracking dependencies
  2. Expert change control: inevitably your programme won’t operate in a vacuum and will have to adapt to the changing external environment, technical issues and moving user requirements. Therefore providing clear boundaries as to when to approach sponsors, escalate concerns or get change approved in a considered process is essential
  3. Adaptable progress reporting: it is visibility that will give the programme team and the organisation a sense of control. Standardisation and automation of reporting is good but having centralised ownership through a PMO will give consistency whilst providing a hub of information creating insight, foresight and flexibility in reporting
  4. Proactive risk management: more than just stage gate compliance, the programme needs to establish a strong culture of identifying, reporting and tracking risks and issues in a way which crosses project and workstream boundaries and creates practical mitigations
  5. Business strategic fit: at a portfolio level programmes and projects should be prioritised to align to strategic business objectives. However once in flight, particularly larger projects, should continue to regularly check back to organisational priorities to ensure that the benefits and outcomes being pursued are still relevant

There is a fine balance between being bureaucratic and having dangerously absent governance. The key is to ensure visibility, responsiveness and strategic direction.

Should I be using Agile project management for Change?

Everyone’s talking about Agile project management, and it’s reported to be 3 times more successful than other techniques. So, do we have to re-structure, re-train, re-model our change programme? Wait…maybe there are some practical principles we could adopt today.. 

Agile came into being with the ‘Manifesto for Agile Software Development’  published in 2001. Since then it has grown into the de facto methodology for software development teams and tech start-ups.

Organisations continue to race to adopt Agile, but it’s no off the shelf solution, rather it’s a collection behaviours, approaches and techniques which hold to the principles of the Agile Manifesto.

The question is: what does Agile have to offer organisational change programmes?

At Afiniti we help organisations prepare for, manage and embed change and this often starts with how to structure your programme. Often whilst aspiring to Agile principles an organisation’s executive team will still require more traditional project controls such as predictable schedules, predetermined budgets and some fixed scope.

 

So how do we combine the two?

A great practical way to build some Agile into your programme is to start with your component project teams and SCRUM. This will mean at a basic level assigning a Product Owner and Scrum Master within that team and breaking activity down into sprints.

This will allow your teams to be reactive to change and stay centred on the customer’s requirements. This could be implemented within a training team; developing training materials iteratively with regular feedback loops to end users or if in a large IT change programme perhaps within your data cut-over team; holding daily scrum meetings empowering team members to self-organise the ‘how’ whilst allowing the lead to focus on Sprint goals.

If this is a good start point then there are also some great Agile principles we can learn and adopt too when undertaking programmes of change, without reinventing the wheel.

 

Take Spotify for example

Spotify have reinvented the wheel and apply Agile to their entire organisation. The organisation is structured into squads with a long term mission, such as “building and improving the Android client” and tribes incubating ideas across squads pursuing similar goals. But there’s a lesson here.

Whilst this restructure may be out of reach for most of us, the idea of keeping conversations outcome focussed, pushing towards the product or goal whilst encouraging collaboration between those facing similar challenges, can be of benefit for all of us.

Spotify also hold to the philosophy that dependencies should be avoided at (nearly) all costs. Blockers or problematic connections are eliminated through re-prioritisation, re-organisation or technical solutions, rather than being managed throughout the development lifecycle. What do we think of this?

Well, in complex change programmes dependencies cannot be completely avoided, but an approach which views these as a type of risk and aims for simplicity, keeps dependent activity highly visible and encourages continued dialogue to reduce complexity and mitigate risk.

So, are we looking to change everything?

 

The Big Three

A recent insight from APM into “Conditions for project success” identified factors critical to successful projects. These will remain important to your change programme even if introducing more Agile practices.

Effective Governance: whilst you might encourage a more iterative approach to detailed planning you will still require a high level plan for each sprint and defined decision gates at a programme level.

Goals and objectives: although you may wish not to tightly specify the product as in Agile, it is still vitally important that we stay focussed on the business value being created.

Commitment to success: commitment transcends technique every time, envisioning your project team will remain vital whatever the process.

Agile behaviours and approaches will enhance your delivery of change, this isn’t a complete re-write but it’s about being more responsive, people focussed and collaborative whilst delivering the benefits, governance and peace of mind your organisation needs.

 

Find out more about how afiniti can help with Business Change

4 things to consider during project planning

During projects, a whole host of things can go wrong: scope creep, lack of commitment from your sponsors, resistance to change from stakeholders… the list goes on.

But we know that not all business change outcomes are under the control of the project team; some organisations are just not set up for successful projects. To make sure your project doesn’t become another failure statistic, it’s worth carrying out a ‘health check’ as part of project planning, looking at some of the key aspects affecting change.

You can’t immediately change a company’s leadership or culture but you can uncover potential issues, areas that will need your focus and ways you may be able to use your influence for a better outcome.

Business Alignment

Of course, projects should only go ahead if clear business benefits and drivers have been identified. Do they stand up to scrutiny? Can they be clearly articulated? And who are they actually benefiting?

An Afiniti colleague was telling me only the other day about an organisation he worked for where the IT team routinely advised the business of their next project, but usually didn’t get a response – and didn’t expect one. They ploughed on with each project regardless because, after all, they were the experts; they knew why they were doing it, even if the end-users didn’t!

project planning

 

Leadership

How true are the following statements in your organisation?

  • Leaders talk to us; we have good visibility of company performance and plans.
  • Senior executives are skilled and experienced in the leadership of change and change programmes.

It’s beyond the remit of a project team to tackle leadership culture head-on, but it can support leaders to fulfil their role in change. Make sure that your project communications explicitly align the benefits to wider plans and performance but keep them relevant to your audience.

Name-check leaders (with permission!), suggest to them the enormous benefit of leadership visibility on roadshows, town-halls, even videos. This brings us neatly to…

Engagement

Is there a culture and widespread practice of encouraging honest two way feedback?  If there isn’t, introduce a mechanism for your project to garner employee views throughout the life of your project, not just at the end. Most importantly – act on it and be seen to do so.

Capability

Are people provided with the learning they need to deal with business change and new technology? Don’t make assumptions, even based on previous projects – know your users!

For example, we were rolling out new laptops and a Windows upgrade for an organisation a few years ago and their IT department was pretty insistent training wasn’t required. They were wrong, which resulted in an upsurge of calls to the help desk at ‘go live’. They’d made an assumption based on how they thought technology was used, not on the reality.

Carry out your own analysis of user needs, to make a compelling case for your choice of learning approach.

These are just some of the aspects of change that can pose a real threat to the likely success of a project or programme. They’re the reason our industry has the change readiness assessment: to see how prepared an organisation is for the impact of projects and programmes of change.

It’s a rare organisation where change is always implemented smoothly but a project planning team does have it in their power to affect the outcome and maybe even influence how change is dealt with in the future – as long as you’ve done your homework.

 

Further resources

Online change readiness assessment

When is a business change project most vulnerable?

project handover

When there is business change, whether it’s an office move or the introduction of a new system, the employees affected by the change will require support. 

One of the main issues when undertaking a change project is the lack of support for the ‘end user’.  Projects tend to have a support resource in place, but what happens when the project team leave? Support services for this time are rarely put in place before the project takes flight which can cause a lot of confusion for employees affected by the change. Users have questions and issues and, having looked to the project team for support throughout the duration of the project lifecycle, now really require support.

At the end of every project, during the closedown period,  lesson learned workshops often take place, and essentially the project is handed back to the business – BAU Handover.

This is when support for the end user is removed and the crucial BAU handover can be often neglected. As commented in the article  “Projects are evil and must be destroyed” “BAU support/maintenance teams are generally under-resourced, have extremely limited opportunity for handover from project teams, and have to support many different systems. This usually leads to less than ideal development practices and deteriorating quality over time.”

This is unfortunate as the BAU handover occurs at a delicate time. Successful user adoption is far from guaranteed at the end of a project and the BAU support team and project team need to ask some key questions to determine what support the end user will need:

  • What’s really important when introducing something new to this company?
  • Who’s really important when making this change?
  • How can we help them get through this change?
  • What tools or resources can we put in place to ensure they are supported fully during and after the BAU handover?
  • How much time should we take planning this before we make this change?
  • When do we need to have the support in place by?

As the emphasis is often more on delivering a project and physically making the change, and the BAU team is not always well provisioned, these questions are useful to ensure the end user is adequately supported. End user adoption of the business change is, after all, pivotal to making change stick.

What are your views? Is this a really sensitive time for business change and have you seen change fail at this point before?