Essential Project Change Management

“One must always be prepared for endless and riotous waves of transformation”  ~E. Gilbert


Imagine you are dressing for a party. You have been planning your attire for weeks. You have purchased the perfect dress (bear with me, fellas), shoes, and jewelry to match. You try on the dress, examine yourself in front of the mirror, and – no! – you notice a snag in the dress. Right across the front, there it is. A most obvious, gnarly snag in your otherwise perfect party dress.

Well, clearly this won’t do. You quickly evaluate your options. You could skip the party all together. You do have a few other dresses that could work. After analyzing and weighing all choices, you settle on an old favorite from the back of the closet, give yourself one last glance in the mirror, and head out to the soiree, feeling a touch disappointed but relatively put together.

Now, what if we expand this metaphor a bit? Imagine you aren’t dressing for a party, but for a huge theater production, as part of the costumed chorus line? What if the costumes had been designed, selected, fitted, and purchased by a whole crew of stakeholders for the production? What if these stakeholders had decided upon and bought into every single detail of your intricate costume? And what if suddenly, while dressing for the production, you examined yourself in front of the mirror and – no! – discovered a snag in the costume. Right across the front. A most obvious, gnarly snag in your otherwise perfect costume.

Well, clearly THIS won’t do, either. But here’s the catch. You’re not a lone wolf anymore. It’s not going to work to just change your costume. You really can’t even decide on or implement a repair strategy or any other solution without the knowledge, input, and buy-in of the stakeholders involved in the production. You can’t just grab the first replacement you see and go out there on stage, the only blue dancer in a sea of pink ones. This is simply not a change that can be made in a vacuum.

Imagine the first scenario as a single person performing a single task. Sometimes, change can be made on the fly with little consequence.

Imagine the second scenario as an instructional design/project team performing a series of tasks with a collective goal.



Apply Change Management Concepts to Instructional Design Project Management

Like everything else in the world of instructional design project management, change requires careful analysis, clear processes, and communication.

While executing even the most well-designed project, there are few important things to consider:

1. Milestones – Evaluation and analysis of a project’s success need to take place at more than just the finish line. Building clear milestones into the project execution plan enables ongoing project monitoring. These milestones can be based on completion alone, but ideally, they’re also based on quality. Ideally, each milestone has an estimated completion date, a party or team responsible (for accountability), and at least some form of a quality or completion measure so that team members and stakeholders can assess whether the milestone has indeed been accomplished towards the successful completion of the project.

In keeping with our metaphor/example here, stepping in front of the mirror before the big production did not signal the completion of the production. If that production were a project being managed, that moment wouldn’t have been the finalization or delivery of the project. It would have been a milestone. The good news is that you stopped to look in the mirror at all.

2. Quality Controls – Throughout the execution of the project, quality controls need to be applied. These may be applied to the milestones, as described above, or they may be applied to the project processes themselves.

In this case, perhaps a few quality controls weren’t executed, or a few milestone quality controls missed. Was the costume engineer supposed to give all costumes a final check before the production to ensure no rips or snags?

3. Change Management Processes – As you’re hitting milestones with project execution, and you’re applying quality controls to measure the success of those milestones, you’ll need to have clear processes in place for managing change. Chances are about 99.9% that at least one milestone or quality control will indicate the need for change. Change on a project requires analysis and evaluation. Stakeholders have to agree that the proposed change is beneficial to the project outcomes. And communication is critical.

In our costume example, there might already be a process in place to satisfy the question, “What should I do if my costume is damaged?” Then again, there might not. Either way, the need for a change must be communicated. Stakeholders must analyze and weigh the options, and then, a change must be made and documented. Perhaps the costume procurer was wise enough to order backups. Perhaps there is a talented tailor on site. One can hope, right?


Change Is Inevitable

No matter how well designed a project plan is, the inevitability of change upon execution exists. If the instructional design/project manager does not have a plan for managing change, the project will suffer. The timeline might suffer as change requests are accommodated. The product itself might suffer if the change requests are not properly or fully evaluated in terms of the big picture goals of the project. So the ISD/PM has to have a plan for managing change. It’s just as essential as having a good starting design.

Change management as a part of project execution can be a tricky thing. The instructional design project manager has to ensure that processes are in fact in place, but at the same time, those processes have to be carefully designed so as to neither arbitrarily encourage nor discourage change.

Change needs to happen when the project will benefit. But change cannot be such a free-flowing event in a project’s execution that it unnecessarily throws the whole project off track or extends the scope, schedule, or budget beyond stakeholder approval.


Change Management

Though these may vary widely depending on the complexity of the project and/or the change management process itself, the basic components of change management are:

  • Identify a need/rationale for change (often through quality management processes)
  • Request the change (communicate to project team and/or stakeholders)
  • Analyze and evaluate the change (risk of change, risk of not implementing change, impact on scope, schedule, budget)
  • Approve or deny the change (communicate to project team and/or stakeholders)

Change-related documents may include a change request form, a change log, a change analysis/risk analysis form, and/or a change report. There are several tools available for developing strong change management processes.

Here are just a few:

Standard Change Log

Change Control Log Template

Project Management Foundations – Managing Change

Simple Steps to Manage Your Project Changes


Bottom Line

The bottom line is that without a solid change management process in place, your project is likely headed for stormy weather. Either no changes will ever be made, and the project is likely to contain gaps, flaws, or mistakes, or change will creep up on your project and soon turn out of control, extending the scope, the schedule, and almost always the budget for your project.


In short, get a process in place. Know what to do when the costume fails three minutes before showtime. Because chances are good that no matter how awesome your project plan is, something will need to be changed.



Cox, D. M. (2009). Project Management Skills for Instructional Designers. Bloomington, IN: iUniverse.

Rooij, S. W. (2010). Project Management in Instructional Design: ADDIE is not enough. British Journal of Educational Technology, 41(5).

Building a Base – Communication and ISD Project Management

As I’ve been examining the relationship between instructional design and project management, I’ve examined many critical facets.


Critical Components

For a project management approach to effectively support instructional design, strong analysis has to take place on both fronts.

Instructional designers have to carefully and critically analyze the needs of learners and of the environment or goals that instruction is designed to support.

They have to understand the learners themselves, and they have to be able to articulate the learning tasks required in order for the implementation of the instructional design to be successful. They have to understand the development process and the roles of all the players involved. Design documents must clearly articulate the goals, instructional events, measurement standards, and development needs for an instructional design project.

Project managers, on the other hand, have to carefully and critically analyze the project itself.

They have to understand the stakeholders, the goals of the project, and the limits within which the project must be completed. They have to understand and be able to articulate the scope of a project and the many different tasks required to complete it.

Not only that, but project managers have to be able to predict in a quantifiable way whether the project can be completed within the allotted budget and time. Project management documents must clearly articulate all of this.


Communication is Critical

Clearly, communication is an absolutely critical piece of the puzzle.

As an instructional designer tasked with project management, I understand the intrinsic value of design and project tracking documents. Through the act of doing the thinking and the work it takes to create them, instructional design project managers gain insight and deep understanding of the design project itself. But the documents aren’t just for the designer/manager. The documents have to COMMUNICATE so that stakeholders can understand and effectively contribute to the design project.

One of the tricky things about communicating with stakeholders is that there are different bits and levels of information that different stakeholders need.


High-level executives don’t need to understand the nitty gritty detail of a project. They don’t need to know how many multiple choice items need to be developed, or how many rounds of edits each piece of content must go through before being finalized. They don’t need to know which sources are used for research on the project, and they don’t need to know every task on every team member’s to-do list. Rather, they need to know the general scope of the project, its budget and timeline, and the general benefits of project completion for the organization.

Content writers and other production team members don’t need to know the high-level budget for a project, and they don’t really need to know every nitty gritty task and detail on every other writer’s list. But they do need clear priorities, deadlines, and task lists for their own contributions to the project.

One of the challenges I’ve faced as an instructional designer turned project manager lies in this very arena. I’m still exploring and learning tools and methods for communicating with all the appropriate stakeholders, providing each of them with exactly the information they need, no more, no less.


Need to Know

I think what I’m learning is this:

An instructional design project manager has to be able to swing like a pendulum between the very broad, high-level aspects of a project (overall goals and scope, timeline, and resources) all the way down to the minutia. And all of the facets of a project must be documented and communicated.

But moreso, just as an instructional designer must analyze the needs of a learner, and a project manager must analyze the needs of stakeholders, they must also analyze the information and communication needs of their various audiences. The documents created must communicate on the appropriate level for each group of stakeholders, and they must neither overload the recipient with too much detailed information nor leave out critical pieces.



What I have designed as my attempt at a solution is a series of documents that work in a hierarchical fashion.

We have the high-level program outline and scope and sequence for the curriculum, which list the overall unit themes and the primary targeted skills.

We have the unit outlines and template designs, which list and describe each instructional segment within each larger unit.

We have the overall project schedules, which provide estimated completion dates for the project milestones by unit.

We also have the detailed task lists and to-dos which provide priorities and estimated completion dates for each smaller segment of the program. Everything is broken down into three categories – high, mid, and detail leveled information. This way, the documents I’ve created can be interpreted by the right group of stakeholders.



In addition, I’m exploring the value of Basecamp in supporting communication at these varying levels.

By creating and tracking a project at a high level, I can communicate with executives and other high-level stakeholders. By creating and tracking a project at the task level, I can communicate with and monitor progress among the individual team members.

And by empowering team members to use Basecamp to create their own projects (projects within a project, if you will), I am empowering them to monitor their own progress and also encourage them not to skip critical tasks.

I am very interested to discover the ways in which the use of a transparent, real-time communication tool such as Basecamp can help to ensure that all stakeholders have access to the appropriate levels of information regarding the larger instructional design project.



Clark, D. (2011, September 26). ADDIE. Retrieved from Big Dog and Little Dog’s Performance Juxtaposition:

Cox, D. M. (2009). Project Management Skills for Instructional Designers. Bloomington, IN: iUniverse.

Culatta, R. (2011). Instructional Design. Retrieved August 30, 2012, from ADDIE Model:

Gordon, A. (2012). ID Roles and Responsibilities. Retrieved from Gordon Computer:

Hodell, C. (2011). ISD From the Ground Up: A No-Nonsense Approach to Instructional Design. Chelsea, MI: Sheridan Books, Inc.

Istation. (2012, June). Istation Reading. Retrieved September 3, 2012, from Istation: