The Project Timeline as a Change Management Communication

There are certain project activities that almost everyone agrees fall under the purview of change management. Development of the project timeline is typically not one of them, but perhaps it should be.

18 March 2024

The objective of change management is to increase staff and stakeholder readiness and support for organizational change initiatives. There are several project activities that almost everyone agrees are part of change management. These activities include things like readiness assessments, change impact analyses, project communications, training, and resistance management. Good change management, however, includes a lot more than just these activities. In fact, it should touch almost every aspect of a project, including development of the project timeline.

Creating a project timeline is typically not considered a change management activity, but in so far as it lays out how much time is going to be spent on each project task and when each task will be worked on, a project timeline can be thought of as statement about a project team’s priorities, and the creation of such a statement definitely contains at least an element of change management.

The completion of any project requires compromises. Project teams do not have infinite resources at their disposal to get their work done. There is usually a set amount of time and money that a team can use on a project. In order to stay within these constraints, the project team typically needs to make compromises.

The compromises that a project team makes are usually very clearly illustrated in a project timeline. A timeline shows how long a team plans to spend on each project task and when work on each task will be completed. Since projects do not have infinite resources, project teams often are not able to optimally schedule all tasks. Some project tasks typically need to be allocated less time than is ideal and some tasks typically need to be scheduled to be worked on at non-ideal times. Which project tasks these are tells the tale of the project team’s priorities.

Consider the example of a team creating a project timeline for a software development project. The team does not have quite as much time and money as they would like to complete the project (a very common scenario). As such, they need to make some compromises on how much time they spend on each project task. These compromises will result in the quality of some tasks being reduced in order to decrease the amount of time required for their completion.

Let us assume the project team decides to reduce the time spent on requirements gathering, user acceptance testing, and fixing things users find during testing in order to complete the project in the allotted amount of time. The timeline for this project is going to reflect each one of these project tasks being allocated less time than is ideal for completion, and end users are going to be able to infer from this where the project team’s priorities lie. This will result in many end users coming to the conclusion that the project team does not really value their input on how the software operates, and this will rightly create resentment and decrease staff and stakeholder support for the project.

Now let us look at a different scenario. Instead of decreasing the time allowed for requirements gathering and user acceptance testing, the project team decides to slightly decrease the amount of time allocated for coding and keep the decrease in time allocated for fixing things found during user testing. This timeline tells a much different story about the project team’s priorities. An end user looking at this timeline will probably see a project team that values their input (hence the good amount of time allocated to requirements gathering and user acceptance testing), is willing to make sacrifices to help ensure end user voices are heard (hence the slight decrease in time allocated for coding), but might not be able to fix everything found during testing before go-live. This timeline and the story it tells are going to do a lot more to increase staff and stakeholder support for the project than the one discussed in the last paragraph.

A project timeline is typically not considered a change management communication. But in so far as a project timeline states how much time will be spent on each project task, it is a statement of the project team’s priorities, and such a statement definitely carries an element of change management with it. Organizations planning critical change initiatives should consider what their project timelines are communicating to staff and stakeholders and how this communication will impact support for their initiative.