December
07,
2017
After many years of providing change management on projects using Waterfall (traditional) project management methodology, you might be asked to manage change on an Agile project.
Agile is a time-boxed project management methodology that uses an iterative approach to software development and delivery. The team builds software incrementally and shares those incremental updates with stakeholders from the beginning of the project. This is a significant difference from the Waterfall approach, where stakeholders are often not brought in until much later in the project – sometimes as late at user acceptance tests. As a result, stakeholders might not be able to provide their feedback early enough to make the kind of changes they would like to see in the software design.
I completely see the benefits of Agile to software development. However, when the project’s change management work is lumped into the Agile methodology, it can be problematic. Or, at least, that’s my experience. If you aren’t familiar with Agile, spend some time researching it online. There’s a ton of information on the topic.
If you are familiar with Agile, you know that within each program increment (PI) there are sprints (two-week work increments). You also know that during the sprints, the focus is on the work deemed most important by the team and the product owner (PO). Because most team members are probably working on software development and not change management, it is likely that the change management work will be viewed as less important. It might not be considered important at all. This poses a particular challenge because stakeholders are already aware and very involved with the project.
Recently, I worked on an Agile effort where, in the second sprint, the change management work fell off the radar. My work was “pushed to the backlog,” which is to say there was no plan to work on it during the current sprint; we would get to it when we finished the “more important tasks.” So you can see the risk of lumping the change work into the Agile approach, can’t you?
How might you overcome this? In my opinion, change management work should be separated from the other tasks and executed on a timeline independent of the iterations. For example, stakeholder analysis, communications planning and communications rollout can be executed concurrently with Agile iterations. Change management is an essential part of the project and should not be “shelved” at any point in favor of other work.
