In Part 5 of this series, I outlined the information to consider being documented in a Requirements Work Plan. And at the end of the post I asked you what might be missing. Did you think of anything that could be added that would be beneficial? How about addressing Change Management? Let’s take a look at why adding this section can help you keep your project stakeholders engaged.
What is Change Management?
Change Management is the process of identifying, analyzing, and deciding on modifications to your clients’ needs as they have been documented in your Requirements and/or Specification documents.
No matter how well you think you were able to understand and document the requirements or specifications, new information will come up that could change what you think you are working on. It could be information that your client thought you knew or “assumed” was included. It could be clarification of information as you work through the specifications and realize there is a key piece of functionality that really you hadn’t yet discussed. Or it could be that the needs of your client have just changed. Whatever the reason, changes may occur. Your job is to be keeping an eye out for things that are “out of scope” (meaning not included in your current project) and to help to assess the impact of the change. You’ll be responsible for understanding and educating the team on what the change means, and working with your project manager to determine whether the change will be included and how.
Addition to the Requirements Work Plan
So what should you include in the Requirements Work Plan? Explain what the Change Management process entails. For example, where is the “end-point” of requirements, where you might get approval or some sort of sign off on all or part of the requirements? How will changes be incorporated after this point? Will the project require formal documentation in the way of a Project Change Request – and if so what is that process? Are you following a more agile methodology where the idea of change is built in to iterations? How will changing requirements be worked into the backlog of features to be incorporated?
By clearly explaining what this process looks like, your stakeholders will know what to expect when you get to that point. And better yet, they will probably see that there is more work involved to change things later in the process, and may be more engaged earlier on to capture as much as possible the first time around.
The Point of No Return
Regardless of what project management or development methodology you’re using (waterfall, scrum, Agile, etc.) there is likely a “point of no return” after which time no additional changes can be made to the project. Sure, you could always push out your delivery date, but honestly, if you’re days away from launching your project, find out if the changes can be incorporated in a follow up effort. At some point, you will have to put a stake in the ground (working with your project manager, of course).
Communicate in Advance
Reassure your stakeholders that you will communicate these points in advance – when you are entering into the Change Management portion, and when you are approaching the Point of No Return. If you know the precise points in the process (i.e. after Requirements are signed off, and 2 weeks prior to launch, respectively), put those right in the Requirements Work Plan. Remember, this is a working document so it can change – just be sure to clearly communicate those changes.
But even if you don’t know exactly when these points will occur, identify that you will communicate advance warning. Most importantly – be sure to actually communicate in advance. Part of keeping your stakeholders engaged is building trust and assuring them that you will guide them through the process.
What else do your stakeholders need to know about Change Management? How can you help guide them through that process?