Change is going to happen
When you say the word change to a Project Manager, they often shudder as they’ve probably experienced some archaic change process and been stuck in change request hell.
Change request hell is typically a fixed scope project that hasn’t been planned well, or the stakeholders assumed that if everything is defined upfront, nothing will change after that.
As a Project Manager, you’re continually having to issue change requests and, in many cases, request more budget which is rarely a pleasant conversation to have.
But change shouldn’t be seen as a negative; change is about improvements, doing what’s right and what’s needed for the business and its users.
Change is going to happen whether you’re working with the Waterfall approach, Agile or any other delivery methodology. It just comes in different forms.
Change needs to be planned for and then embraced when it happens as it means you’ve learnt something new and (in most cases) you’re creating a better product or service because of it.
Discussing change and approaching it at the start or before a project begins is vital for the successful running of the project.
It doesn’t matter if you’re a Project Manager or Scrum Master; change will happen so you need to make sure you’re prepared for it.
So, Why does change occur?
There are so many reasons, and the list below isn’t exhaustive but will help you understand that change is inevitable.
You have to plan for it and educate the stakeholders and the team that it will happen, so prepare for it early.
Use these examples in your conversations to help build up the project stakeholders knowledge of potential changes that could happen on your project.
- The project needs something you weren’t aware of. The most common type of change and you’re pretty much guaranteed for it to happen.
- User feedback. If you’re testing your product with users, they’re going to think of something you’ve missed, whether that’s a problem or an improvement. Unless you’re running your project on your own in a basement, this change will occur.
- A new business need. Industries change, strategies change, a new brand, the list goes on.
- A new idea. If you discuss or work on something, you’re going to have a new idea for it as you do it.
- General improvement. Building on what you already have. You’ve built a new feature on your web site, and, by doing so you’ve thought of many ways to make it better.
- A competitor has it. Your mid-project and your main competitor has released a new feature, and your product needs it to be able to compete.
- Stakeholder request. This is often the trickiest change to manage, especially when the change doesn’t have a valid reason like a user need or a business need. It’s simply that a senior stakeholder who wants it.
- The need isn’t there anymore. You’re halfway through a project and discover that there is no longer value in some of what you planned to create or have created. This happens as you learn or are influenced by outside factors like your competitors.
- It’s too complex. Sometimes you discover things mid-project that you would ideally know initially, but this isn’t always possible. This is especially true in software development, where something you want to create is far more complex than you initially thought. In this example, you either need to take more time, simplify or, potentially, not do it at all.
- A dependency can’t be removed. In an ideal world, a project team can work independently with no dependencies, but this rarely happens. When a dependency can’t be removed, then the project team may have to create a workaround or the team is delayed impacting other planned work.
How complex does a change process need to be?
This question varies depending on many different factors, so use these questions to help you think about how complex or simple it needs to be.
What are you creating? If it’s a complex piece of machinery, you’ll need far more conversations around how change is managed vs a simple landing page for a product.
What methodology and framework are you working within? If you’re using a Waterfall process, then the changes will need to be assessed from a cost perspective, time, impact etc.. and formally agreed and signed.
If you’re working in an Agile manner, it’s managed through story creation, refinement, and prioritisation. All of which still impact time and costs, so discussions and agreements are needed.
Does your contract allow for change? Is it fixed scope, or are you working with a time and materials or a fixed capacity approach that helps the budget owner to make change decisions faster?
Are the team empowered to make changes? If the team can improve and adjust the product, you need to make sure they have the right working environment to do this. Or do they need to wait for specific stakeholder approval?
What documentation do you need? If you need to create a change document, don’t just add the standard structure you’ve found on the internet; discuss as a team and with a client what the minimum/mandatory information you need and how it adds value.
If your change document is a beast, then be clear with the stakeholder what work is required to complete it, so less time on the actual work and more time working on a change document. Make them make the decision of how much effort should be spent on it.
What does a change process need to include?
I’ve purposely kept the description of what needs to be in a change process light, as the detail within each of these points can change depending on the project type.
If you’re working on an Agile project, then a lot of the below will be covered through conversation versus a project using a Waterfall approach, this will all be documented.
The critical point is to make sure you’re asking these questions and documenting what’s needed to build up shared knowledge across the team and stakeholders(when required) to deliver the change.
Plus, remember to always discuss how can you simplify the change process, speed it up, and increase the focus on value and outcomes.
What is the change requested?
- A description of the change
- Why do you need this change?
- When is it required?
- What is required in order to be able to provide this change?
- What does the change need to achieve?
What impact will it have on the project?
- Will it affect anything else planned?
- What is the effort needed (days, hours, story points)?
- What is the cost required (Monetary or de-prioritisation of already planned work)?
- What will the new plan look like (project plan or release plan)?
When can you make this change?
- When can it be done/started?
- Who needs to do it?
- Who needs to approve it?
- What dependencies does this change have?
What is the change process timeline?
- How can discussing potential change earlier reduce the impact on the in-progress work?
- How can a requested change be refined and checked as part of the project ceremonies already planned for the project team?
- How much notice does a change approver need once presented with a change?
- What is the change process timeline covering discussions and actions from the initial request through to implementation?
- Who needs to be involved in the actions performed during the change process timeline
Agreeing on the approach for your change management process
Start by asking yourself these two questions.
“What is the minimum amount of information I/the project needs to clearly articulate a change?”
“How and when can I share this information that will have the smallest impact on the project and the team?”
The first question is saying what you shouldn’t do is just Google ‘change management template’ and use that.
Nothing wrong with getting a template as a starting point if you’ve never seen one before, but don’t fall into the trap of assuming this works for you and your project. You may end up committing to providing a lot of information that’s not actually needed.
For some budget holders, stakeholders, clients or whoever is approving the change, if you offer them lots of information as a starting point they’ll probably tell you that’s what they need.
The second question is to get you thinking about how you can make this is as simple and least impactful for the project team. How will a change impact their typical working week?
Then at the start of a project, you need to make the overall change approver do some work, by asking them these two questions.
“What do you need to know for a change to occur?”
Then ask.
“Why do you need to know that?”
It might not be as blunt as this, but these are starting questions you need to ask as you’re trying to find out what they need to be able to do their job, but also understand why they need it, and check they also haven’t just Googled ‘change management template’ as well!!
By doing this you’re creating a transparent change process from day one, that will be easier to implement and manage when you need it.
In your discussions when defining the change management document, it’s not just about what goes in the document, you need to discuss and think about how you actually get that information.
So going back to one of the original questions you need to ask yourself.
“How and when can I share this information that will have the smallest impact on the project and the team?”
Discuss and consider the following:
- For any information required in the document, how will you get this information from the team? Can you merge the request into the current project team ceremonies rather than creating another meeting
- Who will provide it and what impact will it have on their workload?
- When would be a good time to prepare a change document when a change is requested? Are the reviews always on the same day for consistency rather than ad hoc, which can be disruptive?
- How do I show the impact of the change on the overall plan? This could be a version of the current project plan with the assumed change added or the impact of the change within a release plan.
- How can I plan the change process to reduce disrupting the work in progress? Can the change be broken down into stages?
What you need is for the change request approver to fully understand what requesting a change means for the project team. So not what the change if made will provide, but the impact on the team’s time as it requires reviews, estimation, planning updates to name a few.
You need to make the change process simple and clear, but not so easy that you’re getting changes requested constantly.
Techniques for managing change
Plan F2F discussions for any change.
Don’t fall into the trap of forwarding a change document to the team, without having a discussion with the requestor first.
By doing so, you’ll not only create alignment early, but you’re also far more likely to catch potential issues in the request before it even gets to implementing it. You want the change to be as smooth as possible for the team, so be the barrier to protect them whenever you can.
Ask what the priority of the change is when it’s first raised
In some cases, asking for a change is the easy bit, especially if you’re working on a client and agency project. What isn’t easy, is sharing what the priority is against other work in progress, or even harder, what do you want to de-prioritise?
So always ask about the priority and make sure the requester understands and sharesthis.
Managing a change request with a team whose work load is already full
If you’re struggling to prioritise the change and decide what needs to drop out so the team can stick to the agreed timings, ask the following question:
“If we had to remove one thing for launch, what could it be?”
Pick something you can get a fairly consistent agreement on, discuss the impact of removing it until the full team are in full agreement. If you can’t all agree, then move onto the next one until you’ve removed enough work to be able to integrate your change.
Make the person requesting the change make the final decision on if it goes ahead.
This might sound obvious: of course they’ll make the final decision as it’s typically the client or stakeholder asking for the change. But, they need to make a decision knowing the true impact of the change.
The impact that’s often missed is the effort to plan and estimate the change. This is especially disruptive for a big (major)change or a change that comes late in the project.
So be clear and transparent with the requestor about what it will take to even get to the point that the team will be ready to implement the change. Let them decide if they want some of the team to work on preparing for this change, versus working on the work already planned.
The reason for doing this is it really makes them think if this change is needed. Do I want to tell my boss I’ve slowed down the project for this change?
The Bottom Line
In summary, change is a complex thing on any project but as a Project Manager, you need to embrace it and make the overall approach to managing it a big part of your role.
Get clarity and control early on how the change will be managed and make sure everyone on the project understands the flow and what is required to manage change. Never assume everyone is aligned with the approach, talk them through it and give them the opportunity to ask questions.
The opportunity to ask questions is especially important for the project team and the change request approver, as it’s very likely they’ll have feedback that will improve the change management approach or highlight something you’ve missed.
As a ProjectManager or Scrum Master, you need to be the facilitator in the process and create the structure, but it’s the team around you that will refine it and finalise it for what ultimately will be used on the project.
I’ve also used a lot of terminology that is accustomed to a more traditional change management process, but a lot of what I’ve described in this post is relevant for a more Agile way of working as well.
If there is anything I’ve missed or you want to share what challenges do you have when managing change, please let me know in the comments below.
