Part of Something Bigger

If you're an instructional designer, this request may sound familiar: "We are looking for a self-paced learning solution to help our front-desk staff respond to calls faster." Even if that exact scenario has not come across your desk, a similar one likely has. Stakeholders bring us in to scope, design, and develop learning solutions. As such, we typically have our own process for managing the project of building a self-paced learning solution. However, what we do not always have is a process that fits the self-paced learning solution into the broader organizational goal that leads to the need to upskill the front-desk staff in the first place.

Organizations are most effective when there is strong cross-department collaboration and clear roles and responsibilities. Instructional designers can aid in that effectiveness by seeing their project as part of a larger initiative rather than a standalone project.

The challenge is understanding how to manage your portion of the project while having a project manager for the overarching initiative. To explore such a process, this article will follow an initiative from end to end, highlighting key stages where it is just as important to have someone managing the broader project as it is to be managing your portion of it.

Here's the scenario: You work for a large organization that has multiple sites. Staff can move across the different offices, but few do. During discovery, the company found that workers did not feel confident in their skills to connect with the other offices. To help the workforce build confidence, the executive team determined that self-paced learning would help individuals better understand what networking is and provide foundations for how to be successful.

Project start

You receive a project request to develop a self-paced learning solution on networking best practices. From the intake, you learn:

• The solution should take learners less than 20 minutes to complete.

• The audience has little to no background in the topic.

• The target launch date is eight weeks from now.

The deliverable date is what shapes the project plan, so if you do not receive a date, that should be your first request to the stakeholder. Next, clarify what they expect on the deliverable date. In other words, what does "launch date" mean to the stakeholder? Are they wanting the learning solution in learners' hands on that day? Are they expecting you to pass off the solution to someone else on the project team? Something else? Understanding what is dependent upon that date is key to managing the instructional design portion of the project. Based off the delivery date, you build the learning solution project plan (see Figure 1).

Make sure to share the project plan with the stakeholders as soon as you create it because it's what connects your portion of the project to the work everyone else is doing. Presenting the project plan enables you to gain additional information and sight lines into anything else that addresses the situation, which will help you understand how this solution fits into the larger puzzle and who else is working on that puzzle. Such information helps lay the foundation for coordinated efforts, sets hand-off dates, and ensures everyone has the same comprehension of what is happening and when.

Even though your initial plan works for you, if you do not connect it to the rest of the project team, problems can occur. Developing a project plan based on details you learn during the intake process helps to identify red flags.

Figure 1. Initial Project Plan

Red flag 1: There is no one with whom to share the project plan. Once you reveal the project plan with the stakeholder, they should subsequently disclose it to other members of the project. If there isn't anyone else who must see it, that can indicate there is no plan for how and where the course will launch upon completion. Such a scenario provides the opportunity for you to clarify where your portion of the project ends and where someone else will need to take over. For instance, the stakeholder will need to involve the learning management system administrator for course upload so that the solution reaches learners.

Red flag 2: Dates do not line up. Your project plan will indicate the dates you anticipate each stage to start and end. If you learn from the plan that the dates don't work for other project members, something will need adjusting.

Let's say that after sharing the project plan with the stakeholder, you discover that the subject matter expert will be on vacation during week 6 of your project timeline. To accommodate for their absence and still stick to the completion date, you must modify the schedule.

Make sure to explain how you set the plan in the first place, so if changes are necessary, the stakeholder will know what to expect as far as reduced scope, fewer reviews, or any other consequence. If you do not reach consensus on dates before kickoff, the project will start off on shaky ground.

Red flag 3: There is no coordination for handoffs. With multiple people working on the project, you must know how the team will stay up to date on what is happening with the project as a whole, not just the learning solution. Are there regularly scheduled update calls? If not, you may not find out that, since you established the timeline, a key reviewer is now unavailable. Having a regularly scheduled mode for the entire team to get updates is key for determining roles and responsibilities that everyone understands.

Keep communication open with the other roles regarding the status of your work and whether anything changes. If you are unsure how often to communicate, check with the project manager.

During the project

The planning phase provided the timeline and should have identified who or what is dependent upon your work. From the larger project team, you learn that:

• The LMS administrator will need one week to build the shell and one week for testing.

• The marketing team will need three weeks to develop a communication plan.

Those timings are dependencies on your work. Two weeks prior to launch, the LMS build will need to take place to allow for testing and quality assurance during week 8. Marketing will need to know at week 5 whether everything is on track so it can start communication planning and rollout.

If you are trending ahead or behind schedule, that could affect others. During the planning phase, you found out that the primary stakeholder will serve as the project manager and provide status updates. Therefore, you need to inform the stakeholder of any changes to your timeline. A single-day delay may not seem like much, but it can create a ripple. Whether you are waiting for a review or development takes longer than scoping, the rest of the project team will need to be up to date.

Let's say that during week 3, the stakeholder tells you that a member of the executive team attended a webinar where they saw an e-learning program that contained virtual reality and wants to incorporate the technology into the learning solution. They ask you whether that is possible. Before saying yes, you must update your project plan based on the new request (see Figure 2).

You must remind the stakeholder that the update is just for the learning solution portion. When midproject changes happen, all project members need to be aware because some of their timelines may be affected.

It is your role to communicate what the updates may be, providing as much information as possible to help make an informed decision on whether to accept the change and to determine what else will alter as a result.

Based on the three-week setback, the LMS administrator's and marketing team's key dates have shifted. If the full project team is not aware, the LMS administrator will request the course before it is ready, which can lead to future delays if they have any conflicts with the revised schedule.

Figure 2. Revised Project Plan

The handoff

Your portion of the project concludes once you complete the learning solution. Reviewers have tested and signed off on the e-learning course, and you've provided the source files for launch.

You originally scheduled the e-learning project to take eight weeks; however, scope changes caused the predicted timeline to increase to 11 weeks. Review delays and additional edits lead to a final project time of 13 weeks for the learning solution. You turn over the files to the LMS administrator, who says it will be another week before the course will be live in the LMS. During a meeting, questions arise about why the course will be launching at week 14 when you've completed it at week 13.

It may be tempting to provide the answer, citing the time necessary for the LMS team to test within the system. However, that may not be your question to answer. Managing your part of the project is knowing what is and is not your responsibility.

Delivering the files to the LMS administrator was an agreed-upon task; uploading it to the system was not. Developing the project timeline does not only help keep others up to date on stages and timing, but it also provides a clear expectation of what is and isn't part of the learning solution. That is not to say that your work is complete once you deliver the file to the LMS administrator. There may be items that come up in testing after the file is in the system that you may need to correct before launch.

Successfully managing your portion of the project can involve more than one component. By completing this part of the project, the e-learning program is ready for the LMS. But is there a standard update period when the course is up for revisions? Is there feedback from learners? Is there a new part of the project postlaunch? If so, that segment will need its own project plan.

• Three months postlaunch: View launch and completion numbers and compare them to key stakeholders' expectations. Determine whether adjustments are necessary.

• Six months postlaunch: If three-month numbers did not meet stakeholder expectations, view launched and completion numbers again at six months and discuss with key stakeholders. Determine whether adjustments are necessary.

• Twelve months postlaunch: The subject matter expert reviews the course to determine whether any content changes are necessary.

Tools to help

Project management is a full-time job; however, it is also often part of every job. Whether your organization has dedicated project managers or it is a shared responsibility, a variety of tools and processes can assist you throughout the process.

Project management software. Automating workflows is a quick and easy way to keep projects on track and everyone informed. Check with your IT department about whether there is software your organization subscribes to and whether you can have a user license. If not, programs such as Microsoft Excel and Google Sheets often have templates for Gantt charts or similar project management outlines.

Postmortem. Conduct a reflection and evaluation of the project after completion. A survey or meeting helps the team understand what did and didn't work and identifies opportunities for improvement in future projects. Postmortems typically include reviews of:

• Project objectives and outcomes

• Timeline and budget

• Workflows, collaboration, bottlenecks, or inefficiencies

• Stakeholder feedback and lessons learned

Continual development. The L&D team often sees themselves as the cobbler's children, spending so much time creating training and learning solutions for others that it is easy to forget about our own development. Dedicating time to learning and growing with industry standards and best practices can help speed up development time and improve the quality of the work you produce.