3 reasons it's OK to say 'no' to change
Updated: Sep 16, 2020
You're exhausted. Your eyes are tired. Your head aches. You reach for the paracetamol. It's the second time this week you've felt like this, and it's only Wednesday. Why does this happen?
When agile and responsive becomes 'great idea, let's add it to our change program', or 'let's get the new product off the ground now to speed up how we answer customers' questions'.
Does this sound like a familiar experience?
I have worked in many large-scale change programs where the focus is tightly controlled and any requests have to go through a formal change control process, but there are times when this process is bypassed and the scope of work grows as new projects and new ways of working are added to the overall program.
Why this happens?
It is often easier to start something new, than it is to stop and re-start the program with less elements, or a re-evaluation of the priority of individual projects.
I have found there is a great deal of energy and enthusiasm at the start of a major change, with lots of opportunities and possibilities discussed and mapped into the change implementation plan.
Once a change program has been going for some months, or even years, it is harder to maintain the enthusiasm that started when the program commenced. Or, the original objective of the program has changed, but this is not reflected in the current scope of work and priorities.
3 reasons to say no
So, coming back to the title of this article, what are the 3 reasons it is OK to say 'no' to change?
When adding new elements to an existing and agreed scope of work stretches your resources too thin and causes delays across multiple projects in your existing program;
When changes are made, or new projects are added, without first going through a formal change review process. This is necessary to assess the expected benefits from the new project and evaluate these benefits against the program's objectives.
When your change program loses focus and you have many different projects on the go at the same time, all with the same or very similar delivery timeframes. This makes it more difficult to assess the relative benefits or consequences of individual change projects, and effectively manage issues as they arise.
What's the answer?
If you are getting a lot of requests to add projects to the program, or to change its focus, this is a good time to re-evaluate the program's objectives; and to stop and re-start the program with a new focus and new objectives.
In this situation, I have found individual and small focus groups useful to finding out what's working and what's not; coupled with online polls and surveys to get a sense of where projects are at.
This is also a good time to check in and see who knows the reasons for the change program and its original objectives. That is, what is the original problem the program was setup to fix. This gives you some quick feedback that you can use in your decision-making.
If customer needs have changed since you started your program, or a new technology has been released that would better for your customers, then it is definitely a good time to stop and re-evaluate the program.
In addition to internal surveys and polls to check the status of a change program, I find that checking in with your communication colleagues about what they are seeing in social media is a good way to keep an eye on how customer needs are changing, and how customers are responding to the changes you are putting in place. This means you need to collaborate across all customer-facing divisions and have regular check points during the lifecycle of your program. This allow you to more easily switch to new technologies or new ways of servicing customer needs while maintaining effective use of your limited resources.
Where you need to test changes to individual projects, and maintain delivery momentum, then it is better to split these experimental projects into smaller, discreet programs that don't affect the overall progress of the change. This allows you to allocate specific resources to experimental project(s), without stretching resources allocated to the overall program.
How has this article helped you?
What are the 3 things you'd stop today and what are the 3 things you can then start/add to your change program to deliver a better result?