In this article, I continue the explanation of the theoretical and the practical of the project management methodology we use at TorranceLearning (see “Related Articles” below). Specifically, I will show you how to use story cards to improve your estimates of project scope: tasks, time, and budget.

Enhancing eLearning project management methodology

Over the years, my team and I have found that project management needs to be flexible, simple, and client-friendly. ADDIE (analysis, design, develop, implement, evaluate) has been the eLearning industry’s management method of choice, but we found that ADDIE’s linear nature quashed our mid-project epiphanies and made it difficult to incorporate client suggestions that came after project initiation.

So I explored agile project management, a methodology originally used by software developers. The agile method came closer to meeting our needs because it produces several usable iterations before the final product is released. Each iteration allows all stakeholders to evaluate the project to determine what can be changed and improved. The agile method gave us the flexibility we needed without sacrificing the important steps of ADDIE. Agile was originally designed for software development, so we gave it a few tweaks and made a couple adjustments for our eLearning purposes. We realized our project management approach was a lot like agile method approach—LLAMA.

Reconciling ADDIE and agile

In an earlier article, I gave an overview of the agile approach and how the steps of ADDIE are embedded with agile. Agile and ADDIE begin the same way: analysis that leads to design and then development. The difference is that at this point, ADDIE progresses right to implementation, likely having already devoted a significant amount of the budgeted time to the design and development stages. Meanwhile, an agile approach would move through the design and development stages fairly quickly in order to produce a usable model for evaluation which leads to repeating the design, development, and evaluation steps to make another, improved iteration.

That is a high-level perspective of agile and while it can help you understand how a project might be managed from initiation to release, it doesn’t necessarily help you navigate the day-to-day implementation of an agile approach. That’s where this article will focus. I’ll talk about a method for breaking large project goals down into discrete tasks and then provide some guidelines for estimating these tasks.

Story cards, discrete tasks, and flexibility

One of the key reasons agile works so well is that it helps us frame the long-term goals and short-term plans simultaneously. After project-initiation meetings, the long-term goals are established. In agile, these goals are called “story cards.” Stories capture business needs and performance outcomes in a format that’s useful for planning and production. Story cards should define scope and be meaningful to sponsors and users. Once you have all your story cards, it’s time to start breaking them down into smaller, discrete tasks.

(Side note: If you’re familiar with agile and scrum from the IT perspective, these great long-term plans with many stories are known as “epics.” The epic structure gives the overall trajectory for the project and provides context to stories. For a single eLearning course, the concept of an epic might be overkill.)

Writing down discrete tasks is central to agile’s flexibility. Single tasks on their own index cards can be passed (literally) to someone else if team members change or the team expands or contracts. The cards outline the next steps of the project, so even if there are personnel changes whoever comes to the project will know right where to start.

Discrete tasks can more easily be re-arranged to accommodate new ideas or to deal with problems. Got a great idea but you’re already halfway through the project? Look over your tasks. You may find that by rearranging some or completely getting rid of others you’re able to incorporate the new concept.

Using task cards to scope a project: tasks, time, budget

Another benefit to breaking story cards down into smaller stories is that they will become more meaningful to everyone involved. What does a story card like, “Create interactions that allow the learner to experiment with different options in a real-life situation” really mean in terms of work effort? Break stories down into smaller stories and tasks until they are a meaningful size. Meaningful means that you can reasonably define and estimate the work effort. For example, “Write script for interaction 1: What should employee do in a medical emergency” can likely be estimated more accurately than the all-encompassing story card.

Each task card requires a time estimate. The person who is assigned the work estimates how long it will take to complete the work. This part can be a little intimidating at first because team members often fear that their estimates will be used as an evaluation of their work ethic or time management. It’s important to keep in mind that an estimate is just that. An estimate.

Many team members may also become concerned when they’ve assigned a time estimate for a task and it takes longer that they’d planned. Underestimating the time for a task isn’t necessarily a big deal as long as the person responsible for that task communicates to others that this task is taking longer than anticipated. At that point, agile’s flexibility kicks in. The project manager might ask someone to take care of the other tasks while the original team member completes the task, or maybe she decides to eliminate some tasks altogether.

It’s tempting to pad the estimate. The thinking usually goes like this, “I think this task will take me an hour. It might take longer, though, and I don’t want to look like a slacker so I’ll estimate two hours. Best case scenario, I get done early and look like a star. Worst case scenario, I get done on time and it’s all good.”  However, padding doesn’t help anyone. Sometimes tasks that could have been completed were forsaken because it seemed there would be no time for them. It can also make it difficult to communicate accurately with project sponsors because it’s hard to predict how long it will actually take to reach the next goal in the project.

Dealing with mistakes

While it’s inevitable that some tasks will longer than estimated, that doesn’t mean that it’s not worth exploring (or at least bearing in mind) why an estimate might have been wrong. Some common causes of inaccurate estimates?

  • You’re over-doing it.
  • You don’t have the right skills to do it.
  • The card is not well-defined.
  • The card is misunderstood.
  • You’re putting more effort into the card than it’s worth.
  • Because it was just an estimate.

Agile is, after all, fairly reliant on people. It’s a great system, but even agile can’t actually produce the eLearning. People are needed to get the work done and people are known for making mistakes. Fortunately, agile can accommodate those mistakes as long as tasks are small enough to be meaningful, time estimates are as accurate as possible, and communication is clear and frequent among all team members.