4
Planning the Project

Q:	Why do learning developers work on the wrong things at the wrong time?
A:	They don’t take the time to build a detailed enough plan of the work to be performed.

When you really enjoy doing course development, you tend to look at new projects with idealistic optimism. There is a tremendous desire to jump in and start building something. However, you can’t do what you can’t see. Laying out the tasks of a project allows you to create a schedule that informs not only your work, but also the work you need your stakeholders to do. In chapter 2, you learned how to start a learning event project using a project charter to clarify the business purpose and “why”? Given that purpose, the project schedule determines the “how.”

The project charter pays forward to the project schedule. If you do a good job on the project charter, the project schedule will be easier to build. The project charter doesn’t show any sequencing or order—this is what you will figure out now in the project schedule. For all the work to be done, the goal is minimally to assign one name and one date to a task. You may also need to estimate the hours it will take to get a task done.

Traditional project scheduling is, at best, educated guessing and, at worst, shooting in the dark. There are a couple of challenges that make figuring out how long a task will take a very complicated question: How can I guess how long something will take when I’ve never done it before? With all the multitasking and increased project loads of today’s jobs, how can I guess how long it will take me to clear my calendar enough to do the task?

There are algorithms for calculating the ratio of development time to the length of the course, as well as loading factors for skill sets and organizational culture, which are both discussed in this chapter. However, it is still always a guess, and even more so now that matrixed and multitasking work has taken over. It is very difficult to predict when a task, and thus when a project, will be done because it depends on so many other people, budgets, and timelines in your organization.

In this chapter, you will learn how to build a traditional schedule by estimating the time it will take to complete each task, and then adding that all up to figure out a due date. In practice, few of us get to work forward, and most of us are working back from a due date. So, you will also learn a simpler approach that abandons guessing task duration and simply works back from the due date. Your particular project will determine which approach is best.

A project never goes exactly as planned, and most will require a major shift in strategy at some point. The project schedule is your strategy, which is based on the project as you currently understand it. When the need changes, your strategy will change. You will have a new project schedule, but you will still have a project schedule. This approach is a flexible structure. The key to successful project management is always having a plan and being willing to change the plan should your sponsor need to.

The Evolving Project Charter

As you begin to work out the tasks needed to get the project done successfully and deliver performance improvement, you’ll likely identify stakeholders you hadn’t thought about in the charter. In that case, you return to the scope diagram and add the new stakeholder and the arrows for the hand-off. This could also change or create new learning objectives. You need to learn to expect surprises. The more complicated or troublesome requirements are usually not revealed to the project manager until the project is well under way. Continue to ask for feedback. People don’t like to start with bad news, but remember, bad news early is good news.

It is vital to manage the scope of the project tightly. Keep your scope diagram handy throughout the project to ensure that everyone knows when you are adding new scope with new learning objectives or removing scope by taking a stakeholder or arrows away. The project manager cannot simply say “no” if the sponsor asks for additional requirements. The project charter combined with the project schedule supports the project manager’s best response, “Yes, and the impact will be this …”

Using the fictional case study presented in chapter 2 (developing a one-hour meeting management course), what happens when, in the process of building the project schedule, it becomes clear that the scope of the project has changed? The project now includes not only the course, but also pre- and post-meeting tasks. What is the effect on the project charter?

Q: Does this change the project scope diagram? (Hint: Check the scope diagram in Fgure 2-1.)

A: Yes. More stakeholders are needed to gather information about pre- and post-meeting tasks. The project will require more work (arrows)—specifically, in the development around the pre- and post-meeting tasks. Note that the learning objectives may not change, but there will be additional project objectives for the deliverables in the pre- and post-work.

Building the Project Schedule

There are three things that drive a project schedule:

• Tasks—what work needs to be done?

• People—who can do the work (specific names, not roles)?

• Time and dates—when must the work be completed by?

You may be familiar with the number puzzle Suduko. In this puzzler, you must figure out how to put numbers one through nine in each 3 x 3 square, as well as each column and row without duplication. Think of a puzzle that you like to work on. When you are in the middle of it, you are fully focused on figuring it out. Sometimes it’s frustrating because you think you are just about done, and then the very end doesn’t work out. This is exactly how it should feel to build a project schedule. If it seems straightforward and easy, you are either not scheduling with enough detail or you are doing a project that is not valuable to your organization. The process works like this:

1.   Identify the tasks. Figure out all the tasks to be done (this will evolve throughout the project).

2.   Determine task order. Determine in what order the tasks should be done.

3.   Establish milestones. Group the tasks into autonomous groups with a due date to manage complexity.

4.   Establish due dates. Figure out a due date for each task based on how long it will take.

5.   Assign task owners. Figure out who can work on these tasks. (Hint: Specific people who represent the stakeholders on your scope diagram in Figure 2-1 will have tasks assigned to them.)

Identify the Tasks

When you are building the project charter, you are working in a very big picture way—brainstorming all the possibilities for the project with minimal details. When you are building the project schedule, on the other hand, you use an entirely different part of your brain to create a very detailed view. Project scheduling is more analytical. People tend to prefer one to the other, but both are required for project success. Based on your processing preferences, there are three different approaches to figuring out the tasks you need to do to get the project done: creating the work breakdown structure, leveraging a methodology, and brainstorming using the scope diagram.

CREATING THE WORK BREAKDOWN STRUCTURE

A work breakdown structure (WBS) is a hierarchical chart that helps you brainstorm tasks that need to be completed for a project. This is a very common technique used by project management professionals. Figure 4-1 shows a generic WBS for a learning event. Your chart will usually be more detailed than this one and will include additional tasks that are required for your specific business need.

Figure 4-1. Generic Work Breakdown Structure for a Course Development Learning Event

When building a WBS, brainstorm the components of each task to a level that is detailed enough for you to estimate how long it will take to complete each task. If you can estimate the duration, you are likely at a task level. As shown in Figure 4-1, develop a learning event breaks down into four tasks, each of which is too general to estimate accurately and must be broken down further. Create skills practice consists of two steps: honor multiple intelligences and honor the environment. These detailed tasks can be scheduled and estimated.

You may find that you are not comfortable thinking in this type of top-down fashion. Some people prefer starting with piles of sticky notes, and then grouping them from the bottom up into a WBS. Others prefer to begin in the middle and work both up and down. Whichever method fits your personal style is the right one for you to use.

The WBS is not a diagram that you maintain. Its only purpose is to help you brainstorm the tasks that will go into the schedule. The WBS is just a stepping-stone toward the schedule. If you are working on a project that is hierarchical—for example, e-learning modules that are aligned to topics—this may help you. However, if you are working on something more organic—for example, a leadership program—it may be confusing. Using a mind map (www.mindmeister.com) or some of the Agile tools (www.trello.com) may be more helpful at this point if the hierarchy is not useful.

LEVERAGING A METHODOLOGY

In chapter 3, you learned about some methodologies (ADDIE, SAM, Agile, and Design Thinking). A methodology is a cheat sheet that contains all the tasks you’d need to do a specific kind of project. Methodologies sound difficult and impressive, but they are really just a shortcut for creating project schedules. Methodologies include the tasks to be done and the best sequence to do them. In addition, they occasionally include recommended skill sets for each task.

BRAINSTORMING USING THE SCOPE DIAGRAM

Whether you use a WBS or a methodology, it is critical to audit your tasks using the scope diagram you built in the project charter—you’ll find very important hints to the tasks you’ll need in the project schedule.

Each arrow drawn on the scope diagram identifies one or many tasks on the project schedule. The direction of the arrow dictates who will be responsible for the task. For example, if the arrow is pointing from the project (center) to a stakeholder, the project manager is the task owner of those tasks. If the arrow is pointing from the stakeholder to the project, the person who represents that stakeholder will own the completion of those tasks. Remember, when you build the project schedule, you assign tasks to actual people, not roles (such as those shown on the scope diagram). Each task will have exactly one task owner and a due date.

Option 1:

1.   Think about your project, and figure out what tasks fit your requirements best.

2.   Build your task list using your scope diagram from the project charter; each arrow suggests multiple tasks needed to create that handoff. Add other tasks that fill in the gaps (the scope diagram is an overview, so all tasks may not be explicitly implied). Review the tasks for reasonability.

3.   Any risk prevention tasks that you planned in the project charter should also be included as tasks.

4.   Any communication plan and governance plan activities will also be included as tasks (for example, status reporting and decision points).

5.   Use a methodology task list (for example, ADDIE), to audit whether you have identified all the tasks you need.

6.   If you discover additional stakeholders when you think of other tasks you’ll need, remember to go back and add the arrows and stakeholders to your scope diagram so everyone can see and agree that the scope has changed.

Option 2:

1.   Build your task list using a standard methodology (for example, ADDIE).

2.   Any risk prevention tasks that you planned in the project charter should be included as tasks.

3.   Any communication plan and governance plan activities will also be included as tasks (for example, status reporting and decision points).

4.   Use the arrows from your scope diagram to audit the task list. Add other tasks that fill in the gaps (the scope diagram is an overview, so all tasks may not be explicitly implied). Review the tasks for reasonability.

5.   If you discover additional stakeholders when you think of other tasks you’ll need, remember to go back and add the arrows and stakeholders to your scope diagram, so everyone can see and agree that the scope has changed.

Sharing your task lists with other people may help you discover gaps in your thought process. Even if you have to do the project alone, consider borrowing the brains of your friends to help you with this strategic planning task. The following checklist can help you build a successful list of tasks:

• Have you considered project management tasks, such as status meetings, reviews, and the implementation of communication, governance, and transition plans?

• Has every stakeholder on your project scope diagram been assigned a task?

• Have you discovered any missing roles, specifically roles that you will perform outside your role as project manager? If so, add these as stakeholders to the scope diagram and break out the tasks assigned to you.

• Have you considered how you will evaluate the learning effectiveness before it is implemented? Do you need to add testing activities? Will this require new stakeholders on the project scope diagram?

• When will the project end? What are the tasks that will occur? Are training notes or other instruction needed for the people who will present the event after the project is complete? Being very clear about the end of the project is critical to capturing all the work that needs to be done.

Determine Task Order

The next step is to put the tasks in the most effective order. To save time and with enough resources, it is possible to have parallel work done on a project, which you also figure out now. The sequence of the tasks is best shown using a network diagram depicting the order of tasks from left to right. This type of predecessor dependency is often called task dependency. Project management software is most useful for keeping track of task dependencies and due dates. Not all tasks have dependency relationships, but when they do, it is important not to forget about it. Here’s an example: Consider the tasks put on pants and put on shoes. Clearly pants then shoes is a task dependency. You could do it in the reverse, but it would make the task much more difficult.

Create Milestones

A milestone is a date that a group of tasks will be completed by. Milestones are an important organizer for project schedules for two reasons: they allow you to group tasks under one heading to make it simpler to manage, and they allow you to create interim dates when these groups of tasks must be done, which makes progress reporting easier. You can use milestones to show the date when a related group of tasks (a milestone) is done. Because the goal is to make it easier to track and manage the status of a project, milestones may be unnecessary for a small project. Here’s an example of how to use milestones effectively: Assuming you were using the ADDIE methodology, the milestones and done dates might be:

Start	6/1
Analyze phase done (requirements finished)	8/1
Design phase done (design blueprint finished)	10/1
Development phase done (build finished)	11/1
Implement phase done (install, initiate finished)	12/1
End	12/31

This may be a good view to use to communicate status to your project sponsor as well. Although many project management software programs break this rule, milestones are only dates, and they do not have duration. In some situations, milestones may also be approval points at which contracted work is paid for or interim deliverables are completed.

Establish Due Dates

After identifying and sequencing tasks, the next step is to estimate how long each task will take. In project management, there are two types of estimates: effort and duration. Effort is how long a task will take for a person of average experience uninterrupted. It is also the same as labor expense or billable hours. Here are traditional guidelines for the effort required to build training projects:

• instructor-led training: 25 hours of development for one hour of instruction

• e-learning training: 200 hours of development for one hour of instruction.

These guidelines vary widely depending on the knowledge of the content, the skills of the developers, and the tools available, as well as the types of virtual learning (webinar, asynchronous, and so on). Brandon Hall has adjusted these estimates for newer technologies, which you can find at www.brandonhall.com.

Duration is the amount of calendar or clock time that will pass before the task is completed. No developer can or should work on something for 200 hours without stopping. This is where duration comes into play. For example, 200 hours of development for e-learning training might actually take 10 weeks of elapsed time. Remember, the planned labor expense is not based on duration (you’re doing lots of other things), but on effort.

Many times when we guess the effort and duration of tasks for a project, we forget that it actually was a guess. Once these numbers are written into the schedule, people treat tasks as gospel and are shocked when they don’t happen that way. In reality, it is very likely that the schedule will not go exactly as planned; in fact, it will probably change frequently. This requires the project manager to adapt within the constraints (for example, due dates) of a project; it does not mean that the project manager is a failure because the guesses of the future were not correct. A project schedule is likely overly optimistic.

Another novice project manager mistake is to accidentally show disrespect to other organizations by estimating the expected effort for their tasks, when it is clearly work you aren’t familiar with. You probably get annoyed when people tell you to build a course for them in a couple of hours. With all these loose ends, estimating effort or duration is a crapshoot, and must be accepted as such to be able to practice the adaptability needed as project manager. The next section will walk you through a process to work backward or forward from a date. In other words, instead of telling others how long the task should take, tell them when the task has to be completed for the project to stay on track.

You may also be required to estimate how much labor—the main driver of cost—will be required to complete the whole project (planned labor expense) to drive proposals for internal and external consulting work. This is tough to estimate accurately for the same reasons discussed; newer methodologies such as SAM and LLAMA offer alternatives to the practice of estimating a whole project when it’s really too early to tell. Both depend on evolving and iterative requirements and design work that requires heavy involvement of the customer to allow predicting effort for small pieces of the project, rather than the whole (see chapter 3).

WORKING BACKWARD (OR FORWARD) FROM A DATE

Working backward from an established due date is a useful technique if you are assigned an inflexible due date. If you do not have a final due date, you can work forward from the start date to calculate an expected due date using this same approach. Since 1986, Capers Jones and others in IT have researched the best allocation of time between analysis, design, development, and implementation (Jones 2007). When projects neglect the upfront activities, the develop and implement phases get overloaded with rework. Constant change is also disruptive to the quality of the end result. The more times you have to rework something, the more likely it will disrupt something connected. It takes great courage to delay “checking off the build” to focus on more thorough analysis and design. It’s very tempting to dive in to create a course, especially if you are busy and there are cool new tools to play with.

Figure 4-2 summarizes Jones’s research on effort applied to the ADDIE methodology. If you know your start date or end date, and the appropriate ratios in between, it is purely a math problem to establish the dates each milestone has to be finished.

Figure 4-2. How to Allocate Effort to the ADDIE Phases

Using the fictional case study, we have been told that the meeting must now be held in 30 days, on September 30. Today (the start date) is September 1. Using Figure 4-2, we can create due dates for the milestones, which are shown in Figure 4-3.

Figure 4-3. Meeting Workshop Project Milestones

Like all good project managers, you ask for clarification about the September 30 end date. Is this the date the meeting will be held, or is this the date the evaluation will be completed? You’re told it’s the date that the meeting will be held, and the evaluation will be done by December 31.

Now it’s time to figure out what tasks need to be done for the analyze milestone to be complete, and in what order. Figure 4-4 is an example of the task order and how the time is allocated based on experience and working back from the due date (this figure just uses a small number of tasks as an illustration—you will have many more).

Once you’ve figured out the tasks, their sequence, and their due dates (or effort and duration if you have to), it’s time to assign a person to be responsible for each task’s completion. You could drop your sequenced tasks in a spreadsheet prior to assigning the task owners, but it may affect the sequence of the tasks, so it’s usually better to wait.

Figure 4-4. Meeting Workshop Project Milestone Task Schedule

As explained in chapter 3, the problem with this ADDIE approach is that the longer the project takes, the more likely the earlier phases require rework disrupting the timeline. The SAM methodology mitigates this risk by spending minimal time in analysis (Savvy Start), then loading up the prototyping in design. The percentages are different, pushing more work to design and development—15 percent in Savvy Start, 40 percent in design, 30 percent in alpha, 10 percent in beta, and 5 percent in gold. In Agile, the percentages don’t have meaning at all because each iteration (sprint), is a fixed amount of time, combining the analysis, design, development, and implement phases.

Assign Task Owners

The next step is to assign a task owner (one person) to be responsible for the completion of the task. There may be other people helping this person, but you want to have one go-to person to check on status. This seems like an obvious step, but assigning people can get a little tricky. For example, which of the four tasks sequenced in Figure 4-4—identify target audience and performance gaps, create agenda, determine speakers, or determine logistics needed—would benefit from multiple people? If these tasks have to be done in this order (there is task dependency between each), adding people makes the project progress more quickly only by adding multiple people to a task. Adding additional people to this analyze phase only makes sense if one of these tasks would benefit from more than one person working on it.

Adding additional people to help with the create agenda task would likely not be useful. It would make more sense to add people to figure out the performance gaps or contact speakers, but not too many. As Frederick Brooks says in his book, The Mythical Man Month, on software engineering and project management: “You can’t hire nine women to have a baby in a month.” Not all tasks subdivide well, and adding people to a troubled project tends to make it more troubled.

Our final project schedule contains one name and one due date for each task that needs to be done. Figure 4-5 shows spreadsheet headers you can use to store your tasks. Notice the done column—not only will this spreadsheet work as a dashboard for your project, but it can also be used as a status report (see chapter 5).

Figure 4-5. Spreadsheet Headers for Task Dashboard

As people are assigned to tasks, new dependencies may emerge. Project management rules require that one person cannot work on two different tasks at the same time, so a choice must be made to place one ahead of the other. This is called people dependency. Choosing the best resource greatly improves project success.

In 1979, AT&T Bell Labs researched and released a numerical process to account for the difference between effort and duration. This calculation looks at three factors that predict how much duration the effort will take for a task: expertise, project-related work, and environmental factors. Doing these calculations for every task on a project is overkill today. Understanding the impact that these factors predict, though, will improve your success at estimating effort and duration.

• Expertise. Expertise can significantly lengthen or shorten the effort for a task. For example, a person who has never done an e-learning project will take much longer than a person who has been developing this kind of training for many years, purely due to the learning curve. Expertise includes both the ability to do the task and the knowledge in the content area. The AT&T study also found that expertise in the politics of an organization influenced effort significantly.

• Project-related work. The tasks that you have identified and sequenced are all the tasks required to build your project. This does not include project management tasks done in most cases, including building the project charter and project schedule. The AT&T research found that project management is an additional 10 to 20 percent of the hours of the total project. You can add this amount in as a line item on contracts—project management is an additional value we provide when we do a project.

• Environmental factors. This is the last factor and the most changed since the 1980s. At that time, AT&T found that being part of a company took 25 to 35 percent of your day. This percentage included sick and vacation time, celebrations, and meetings unrelated to your project. Today, through an exercise in our PM workshops, learners believe that they can only dedicate two or fewer hours to deep thinking work, including their projects each day. This is a complete reversal of the loading factor. It is becoming common for two or three people to answer “zero” hours in a day. Many people try to catch up on projects and deeper thinking activities late at night or on weekends. This practice is not scalable or sustainable, and likely lessens the quality of the deliverables.

Effort does not predict when the project will be done. This is a common mistake and how many projects get into trouble. No one can work on a project without spending time on other tasks at the same time, so carefully consider the experience level, project management overhead, and project load of the people assigned to the tasks on your project. Especially you because you have to juggle all the roles you play in your real job and your other projects!

Visualizing the Project Schedule

There are various ways to look at a project schedule—by date, person, dependencies, or milestone, for example. It is labor intensive to try to manually create these views. Project management software allows you to enter your schedule once, and look at it in multiple ways, depending on the need. Two common reports are the critical path method (CPM) and Gantt chart.

Figure 4-6 shows the beginning of a CPM diagram. This example is based on the generic WBS in Figure 4-1. Notice that this diagram implies an order through the arrows drawn by showing the tasks, task order, dependencies, and dues dates. This diagram shows that some tasks can be done in tandem, some can start at any time, and others must wait for predecessor tasks. Project management software is useful for keeping track of task dependencies.

Figure 4-6. Sample Critical Path Diagram

When there is more than one parallel path, one usually has a longer total elapsed time than the other. The longest path is called the critical path. The other paths have slack time, which is the difference between the longest path and the shortest path. In other words, the shortest path has a little extra time, but this extra time is for the whole path, not each task, which is a common misconception for novices using some project management software.

The benefit of looking at the project schedule as a CPM is that it is very clear what order the tasks must be done in and how work is being done in parallel. To see the calendar view—where are we and what has to be done right now—it’s easier to look at a Gantt chart. Many project management software tools show both charts side to side as a dashboard. In both cases, these diagrams can be very large.

Technically, Gantt charts can be any two-way examination of project tasks—including tasks to calendar, people to tasks, and so on—to represent different views of the project task against a calendar.

Gantt charts can be used to show when each task will start and should end, as well as who is assigned to work on each task across a timeline. Notice that dependencies are not as clear on this view of the project.

Figure 4-7. Sample Gantt Chart Segment

When the first edition of this book was written, the majority of project management tools were expensive and complicated. Today, there are multiple choices. You can use:

• an enterprise-wide tool like Microsoft Project Server to do company-wide, complex, large projects

• single user or team-based cloud-based subscription services to do mid- to small-sized projects (examples include Basecamp, Smartsheet, and Clarizen)

• visual tools (used in Agile projects; examples include Trello and Mindmeister)

• SharePoint tools

• drawing tools (for example, Visio)

• Excel.

Here are some tips to help you decide whether and how to use software:

• Using project management software can be time consuming. Sometimes you can find that you have wasted a lot of time trying to do something that the software cannot easily do, if at all. Limit your time on the computer so you don’t end up doing project management software work instead of project work.

• If your project has small risk, a simple drawing is all you need to manage the project. A good drawing package, without all the calculations and logic of project management software, may be enough to make it pretty, but will not add so much complexity that it takes your attention away from the project.

• Consider asking someone else to enter your hand-drawn project plans into the computer. That way, you can stay focused on project management and the other person can help you with administration.

• A good guideline for using project management software is to let the software calculate dates from your task estimates as much as possible. Doing so gives the software more flexibility to adjust the dates when the actual task time is greater or less than planned. If you do not plan to calculate duration (if you are working forward or backward from due dates), the software will frustrate you.

• Excel is a simple tool to get started with and good for working back from dates.

Planning the Budget

The more complex the project, the more important it is to manage the budget carefully. Figure 4-8 is an example of a worksheet used to document the budget at the start of the project and then manage the budget as actual project work is completed. Using worksheet software can make this easier to manage.

If you are the only person working on the project, you may not find it necessary to be this rigorous in your management of the budget. Remember the discussion of constraints in the define phase; in many cases, learning event developers are assigned a fixed budget and have no ability to get more funding, even if they need it. In this case, the project manager is better served by monitoring scope and critical path than by monitoring the budget. (Chapter 5 provides more information on this topic.)

Figure 4-8. Sample Worksheet for Projecting and Managing the Budget

History Says …

Some good lessons about creating a project schedule for L&D projects:

• It always takes longer than you think it will. This is generally a result of events not immediately under your control, including business politics, other people, and surprises such as weather, illness, and even promotions. These glitches will not take long to emerge and may hit the day you start. Don’t get discouraged—plan for them. The risk assessment process should help you deal realistically with changes and surprises. They will happen.

• It is tempting, no matter how experienced you are, to avoid putting enough detail in the project schedule or skip it entirely. In fact, the more experienced you are, the more tempted you will be to skip it. Don’t. Even if you never look at the schedule again, creating it will dramatically improve your project success.

• If you do not believe the schedule is doable, you’re probably right. Be honest with yourself and to anyone who is trying to coerce you into a schedule that you do not think is possible.

• Everyone’s expectations—yours, the customers, and the other stakeholders—are strongly influenced by a common visual picture and language. The project schedule creates a central place of understanding and should be a living, breathing, evolving document as the project progresses.

Summary

In this chapter, you read about how to plan a learning event project. To manage a project as it progresses requires a clear, detailed plan specifying minimally each task needed with a due date and a task owner. When experienced and overworked, consider just building the schedule back from the due date. Milestones, status checks, and budget worksheets are critical for complex projects.

Practical Exercises

Now practice the plan phase you have just learned using your own project as a reference point. In the following exercises, use the steps provided to schedule your own project working back from a fixed date (or forward from the start).