The Secret of Better Project Management: Task Cards

In this article, I continue the explanation of the theoreticaland the practical of the project management methodology we use atTorranceLearning (see “Related Articles” below). Specifically, I will show youhow 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 projectmanagement needs to be flexible, simple, and client-friendly. ADDIE (analysis,design, develop, implement, evaluate) has been the eLearning industry’smanagement method of choice, but we found that ADDIE’s linear nature quashedour mid-project epiphanies and made it difficult to incorporate clientsuggestions that came after project initiation.

So I explored agile project management, a methodology originallyused by software developers. The agile method came closer to meeting our needsbecause it produces several usable iterations before the final product isreleased. Each iteration allows all stakeholders to evaluate the project todetermine what can be changed and improved. The agile method gave us theflexibility we needed without sacrificing the important steps of ADDIE. Agilewas originally designed for software development, so we gave it a few tweaksand made a couple adjustments for our eLearning purposes. We realized ourproject 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 ofADDIE are embedded with agile. Agile and ADDIE begin the same way: analysisthat leads to design and then development. The difference is that at thispoint, ADDIE progresses right to implementation, likely having already devoteda significant amount of the budgeted time to the design and development stages.Meanwhile, an agile approach would move through the design and developmentstages fairly quickly in order to produce a usable model for evaluation whichleads to repeating the design, development, and evaluation steps to makeanother, improved iteration.

That is a high-level perspective of agile and while it canhelp 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 agileapproach. That’s where this article will focus. I’ll talk about a method for breakinglarge project goals down into discrete tasks and then provide some guidelinesfor estimating these tasks.

Story cards, discrete tasks, and flexibility

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

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

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

Discrete tasks can more easily be re-arranged to accommodatenew ideas or to deal with problems. Got a great idea but you’re already halfwaythrough the project? Look over your tasks. You may find that by rearrangingsome or completely getting rid of others you’re able to incorporate the newconcept.

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

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

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

Many team members may also become concerned when they’veassigned a time estimate for a task and it takes longer that they’d planned. Underestimatingthe time for a task isn’t necessarily a big deal as long as the personresponsible for that task communicates to others that this task is takinglonger than anticipated. At that point, agile’s flexibility kicks in. Theproject manager might ask someone to take care of the other tasks while theoriginal team member completes the task, or maybe she decides to eliminate sometasks altogether.

It’s tempting to pad the estimate. The thinking usually goeslike 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 havebeen completed were forsaken because it seemed there would be no time for them.It can also make it difficult to communicate accurately with project sponsorsbecause it’s hard to predict how long it will actually take to reach the nextgoal in the project.

Dealing with mistakes

While it’s inevitable that some tasks will longer thanestimated, that doesn’t mean that it’s not worth exploring (or at least bearingin mind) why an estimate might have been wrong. Some common causes ofinaccurate 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 thanit’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 makingmistakes. Fortunately, agile can accommodate those mistakes as long as tasksare small enough to be meaningful, time estimates are as accurate as possible,and communication is clear and frequent among all team members.