One skill I’m constantly trying to improve is estimating how long it will take to complete a project. Because I work for myself, I have to create good estimates. If I don’t, I either bid low and lose money or bid high and lose a project.
The two sources I use for benchmarks are Bryan Chapman’s research and Karl Kapp’s ASTD research. Of the two, I usually go for Chapman’s data, since it’s broken down with more detail. I find it helpful to refer clients to these sources, especially if they think training development should take barely any time.
I also track my own time for every project I create, so I can compare my actual numbers to the benchmarks. I use a time tracking template that lets me analyze my time on different tasks and projects. That’s the best situation, but I don’t have enough data for all types of projects. I also want to verify my personal numbers against the benchmarks.
For example, let’s say a client asks me to convert an existing full day training program to self-paced e-learning. This will be mostly linear with some interactivity and no branching scenarios. A “full day” or training in this case means 6 hours of actual content. The content itself is in pretty good shape; there’s slides, a participant guide, and a facilitator guide, and it’s all fairly complete. There’s no video, only limited animation (the kind I can build in Storyline or Captivate), and professional voice talent will be used.
I’m going to assume this can be compressed to about 3 hours of e-learning. That’s 50% of the original time, which is a standard estimate backed up by research. This project is on the low end of a Level 2 by Chapman’s study, so the ratio for development is 127:1 (that is, 1 hour of e-learning takes 127 hours to develop). For 3 hours, that’s 127 * 3 or 381 hours total work. That’s the work for everyone on the team, not just me.
Chapman’s study provides this breakdown of tasks and the percentage of time for each (see slide 18).
- Front End Analysis: 9%
- Instructional Design: 13%
- Storyboarding: 11%
- Graphic Production: 12%
- Video Production: 6%
- Audio Production: 6%
- Authoring/Programming: 18%
- QA Testing: 6%
- Project Management: 6%
- SME/Stakeholder Reviews: 6%
- Pilot Test: 4%
- Other: 1%
Thinking Through the Numbers
I always weigh different factors to tweak these benchmarks.
- Front end analysis is 9% of 381 or about 34 hours. I’ll assume less than that because it’s a conversion and a lot of analysis has already been done with the face-to-face version. (Yes, I know that’s not always realistic. Just because someone already has a course doesn’t mean they actually did any needs analysis. Pretend with me that this client did, and I know the current course is meeting their needs.) I’ll call this analysis 20 hours.
- Instructional design is 13% or about 50 hours. I’ll call this 45 hours for me, assuming the SME will need to spend some time reviewing.
- Storyboarding is 11% or about 42 hours. I’ll estimate 40.
- For graphics, my estimate depends on how much custom development I’m doing and how much will be provided by the client. If the client has a standard template and a large library of images for me to use, this might be 20 hours. If I’m creating a custom template and a lot of graphics, this should be 45. Let’s assume that although the content in the slides is good, the graphics are awful, and I’ll create a template myself. I’ll use 45 hours for this example.
- Since there’s no video, I use 0 for that value. Audio will be created by someone else, so I won’t include that in my estimate either.
- Authoring/Programming is 18% or 69 hours. That actually seems a little low for building in Captivate or Storyline, based on my experience, although I’m assuming for this example that the course relies heavily on templates. I would assume at least 75 hours, maybe more.
- QA Testing is 6% or 23 hours.
- Project Management is also 6% or 23 hours. Depending on the project, I do more or less project management. I’ll assume 10 hours for this example.
- The Pilot Test is 4% or 15 hours. I assume other people will be involved in that test, so I’ll estimate 6 hours. Generally a review of a course takes me 2-3 times the length of the course.
Adding it all up, it’s 264 hours. How much padding I add to that estimate depends on a number of factors. If I’ve worked with the client before and I know they’re always responsive and very clear with feedback, I might just round up to 265. If the client seems unclear about what they want or I suspect that reviews and revisions will be complicated, I’ll add more and probably call it 275 or more.
The above breakdown also helps me determine an estimate if I’m not creating the entire course. I often work in teams with other multimedia developers, so I might only be doing the analysis, design, storyboarding, and project management. It’s easy to take those components and come up with a rough estimate for my portion of the course.
These resources may help you with your own time estimates.
- Bryan Chapman’s research on how long it takes to create learning
- Karl Kapp’s ASTD research on the time to create one hour of learning
- My time tracking template. In the future, this is what I hope to use for all time estimates as I increase my data for different types of projects. I’d rather have actual personal benchmarks instead of generic industry benchmarks.
- Adobe Captivate, TechSmith Camtasia Studio, Articulate Storyline: Production Times by IconLogic. This estimate says that Captivate and Storyline development generally take 2 hours per finished minute to produce, or a ratio of 120:1. That’s not including writing a script or recording audio. Chapman’s estimate is closer to 20:1 for the authoring/programming section, so there’s a pretty large discrepancy here.
- IconLogic’s Captivate Time Estimator. This is a free interactive PDF download, but it requires registration. Answer questions about factors that affect development. Using this estimate for a 3 hour course, I got a the total time is 562 hours instead of the 381 based on Chapman’s estimate. That’s closer to Chapman’s mid-range estimate for a Level 2 course (187:1).
- Estimating Time and Costs in Instructional Design: Don Clark’s overview of multiple sources with time estimates. The Chapman averages cited are from an older survey than the one I cited above.
Image Credit: Time by Alan Cleaver, on Flickr
- Learning Theories Gone Wild – Urban Myths that Hurt Your Learning Designs
Learning styles, Dale’s Cone of Experience, the forgetting curve, and “learners know best”: myths to disregard
- Periodic Table of Storytelling
Tropes for storytelling. The examples are primarily TV series, but this could be inspiration for e-learning stories too.
My daughter was born last May. “E” was in a hurry to meet us and arrived two months early. When my water broke, we rushed to Duke University Hospital. I quickly received a dose of betamethazone and a bolus of magnesium. E spent over a month in the NICU. My conversations were suddenly filled a whole new language: brady, desat, gavage, TPN, bili lights, central line, kangaroo care.
My husband and I continued working while she was in the NICU. I had to finish up a few projects before my maternity leave could really start. I pumped every three hours, so I never got more than two hours of sleep at a stretch that whole month. We drove 40 minutes to Duke every afternoon to visit her in the hospital, while juggling work and getting the house ready for her to come home. The staff at Duke were wonderful and helpful, but I was completely exhausted.
As fatigued and stressed as I was, I quickly learned the language of the NICU. In the first week, five separate nurses or doctors at Duke asked me if I had a medical background. I seemed so familiar with the terminology that they assumed I had formal training. I always chuckled and explained that I have no medical background, but learning the language of different fields is part of what I do for a living. As an instructional designer, it’s my job to be able to work with experts in lots of different subjects. The fact that multiple healthcare practitioners were fooled into thinking I’m one of them is just a sign that I’m a competent ID.
A few years ago, I wrote a course on bulldozer safety. I’ve never even ridden on a track dozer, but working on that course expanded my vocabulary: tramming, trunnion, berm, FOPS, frog, grouser, windrow, ROPS. Every organization also has its own lingo. At Cisco, I’d ask people to “pass me the ball” during meetings so we could finish before our “hard stop” and discuss what’s changed in CSAP since the program was “put on pause.” Like any big organization, Cisco uses hundreds of acronyms, and the same acronym in one group can have a different meaning in another team.
Learning those acronyms and becoming familiar with the vocabulary of your organization and field is part of the job of an instructional designer. It’s actually one of my favorite aspects of being an ID; one of the reasons I enjoy freelance work is that I’m constantly learning new things from a variety of sources. Lifelong learning is a major perk of this career.
I’ve seen people argue that IDs should have content expertise in the fields where they develop courses. Usually it’s in job listings where a company requests something like “5-10 years experience in healthcare or pharmaceuticals.” I’ve even seen someone in the learning field argue that content expertise is an “essential” qualification for doing this job. Personally, I think that’s completely wrong. It’s not essential; it’s not always even beneficial.
I agree with Connie Malamed: Instructional designers are content neutral. Connie explains some strategies for gaining knowledge when you’re not a mini-SME: preexisting content, instructional analysis, task analysis, research, and interviews. Even without the motivation of being responsible for the well-being of a teeny tiny human being, you can do the research and learn enough about a field to ask SMEs intelligent questions. That’s often the real key: do you have the right language to ask the right questions? We don’t need to be SMEs; that’s why we have a SME on our team. Our role is to be experts in learning, not on the content. We do have to learn about the field so we can collaborate with SMEs and develop content, but we don’t need the true depth of expertise of a SME. As long as we can learn the language, we can ask the right questions and explain our ideas in a way that others can understand them. We don’t need to be SMEs; we need to know how to talk to SMEs.
E is now 10 months old and doing great. Her language skills right now are focused mostly on blowing raspberries and saying ba-ba-ba-ba, but that’s a fun language for us to play with together.