Cartoon of ID wearing many hats, one of which is labeled "PM"

All blog posts ……..Start each work week with the latest issue. Scroll down to subscribe!

PM do’s and don’ts for IDs

The process of creating and delivering instruction requires inputs, a process (some flavor of ADDIE), and outputs.  It often involves a team and is always subject to real-world budgetary and technical constraints. 

And that means project management, or PM, is involved. 

On large teams, instructional designers (IDs) may be contributors, working with a formal project manager.  But on small and one-person teams, IDs may find themselves tasked with the PM role—even if they have no background or certification in project management.

If you ever find yourself in that position, keeping the do’s and don’ts below in mind can help you avoid some major potholes and bring your project across the finish line on time and within budget.

1.  DO schedule a project kickoff meeting at the beginning of each project. 

The purpose of a kickoff meeting is to introduce the team members to each other, define the overall project goal, and set expectations around the development process, tentative timeline, and the responsibilities of individual team members. The outcome of this meeting should always be explicit task assignments, complete with due dates.

2. DO use historical project data, if possible, to inform the project timeline and the hours of work associated with each role’s task.

If you don’t have historical project data:

  1. Use a projection tool to estimate hours and timeline for the current project (or just estimate them yourself based on your experience).
  2. Capture actual data for the current project.
  3. Use that data to create revised timeline and hours estimates for your next project.
  4. Repeat steps #2 and #3 until your projections are reliable enough for the leadership at your organization.

3. DO obtain sign-off from stakeholders at each major step of the design and development process.

Sign-off ensures everyone accountable agrees on what needs to be done when. Major development steps include:

  1. Project requirements, including detailed learning objectives, how you’ll assess learners on mastery of those learning objectives, and what assessment outcomes will determine project success
  2. Scope and sequence (table of contents)
  3. Completed storyboard
  4. Final materials

4. DO hold team members accountable.

Make articulating who’s expected to complete what by when, even after changes are made to the project team or timeline, a firm habit.

In addition to ensuring that everyone on the project team knows the tasks and turnaround times they’re responsible for, ensure that everyone understands that delayed task completion translates to a delayed rollout.

5. DO keep all stakeholders apprised of project progress on a regular basis.

Automate reporting if you can; make do with a weekly, well-worded email if you can’t. Don’t feel you need to go overboard providing ultra-granular information or building out a fancy dashboard. All most stakeholders want to know is if the project is on track and, if not, what’s causing the problem and who’s responsible for getting the project back on track. Providing this information shouldn’t take a ton of effort or time.

6. DON’T let stakeholders take the reins. 

Without a formal, certified project manager in place, some stakeholders can be tempted to take over and run the show. Don’t let them. As critical as subject expertise is, a successful instructional project needs oversight beyond just content accuracy.

7. DON’T permit scope creep.

Refer stakeholders to the scope and sequence you had them sign off on near the beginning of the project (you do have a signed-off scope and sequence, right?).

Offer to capture details of out-of-scope work now, but be clear that anything outside the original scope will need to be delivered in a phased approach, as a separate project.  Alternatively, if the scope does absolutely, positively need to be expanded (due to fly-in regulatory changes or legislation, for example), formally revisit the project requirements and push back the timeline.

8. DON’T expect a bump-free ride. 

Issues, large and small, will likely arise arise. Embrace this fact, build wiggle room into your timeline, raise a red flag immediately when an issue does arise, and tackle the issue proactively.

9. DON’T skimp on the up-front work. 

It can be tempting to want to rush through the (okay, I’ll just say it) tedium that’s often required to define bulletproof project requirements so that we can get straight to the fun part – the design, the shiny new tools, and the prototyping.  Doing so, however, all but guarantees poor outcomes.

10. DON’T make the development process harder or more complicated than it has to be.  

Sometimes, the tools and processes we put in place to make our lives easier actually make them harder. We don’t always need every single step of every task documented in triplicate; every meeting recorded and distributed; or every last project detail shared out to all stakeholders in complicated report formats. 

Yes, we need to track project progress, decisions, and constraints; but if our process management, tracking, or reporting strategy is adding a disproportionate amount of time or effort to the work, we should feel free to consider replacing it with a simpler, more practical, more sustainable approach.

The bottom line (TLDR)

Whether we constitute a one-person shop, work on a small design team, or contribute to large projects led by a formal project manager, the project management skills we build and hone as IDs are an indispensable part of our value-add. They don’t hurt our marketability, either.

What’s YOUR take?

Do you have a different point of view? Something to add? A request for an article on a different topic? Please considering sharing your thoughts, questions, or suggestions for future blog articles in the comment box below.

Leave a comment