Thursday, October 16, 2008

Guesstimating Seat Time

Many eLearning projects are priced out based on expected "seat time" -- that is, how long the learner has to sit on his or her butt to learn (watch!) what needs to be presented/taught.

I've never been that good at estimating seat time and often end up with projects that are longer than they're supposed to be. This is not good from either the learner's point of view or the development team's.

I have a lot of issues with the whole "seat time" model (and I'm thinking about sit and click style eLearning here of the self-paced variety):

  • My seat time may be different than yours
  • Is there supplemental material, like reading, that is optional -- or that might vary per user?
  • How interactive is the course going to be?
  • Is the user being forced to watch every single page or do they have freedom to jump around.
  • ETC.
  • ETC.
What would you add to this list?

There's some metrics floating around: such as 4 hours of classroom time = 1 hour of eLearning time. But that varies wildly if you're talking software training vs. something more complex and soft.

How do you estimate seat time?

Or, better yet, what's the alternative to seat time as the basis for a pricing model?

Photo credit: Shock and sorrow: chair mass grave by emdot

11 comments:

Dan said...

Cammy, likewise I've never really understood this measurement - our model is based on the very same.

All too often the "x hours of elearning" are sold before the content has been fully assessed so you are stuck trying to make things fit, or arguing that a screen is worth 50 seconds of learner attention against 35 (or whatever).

I think that the better way to go is to sell based on the number of screens that will be used. That way at least at the end if the initial estimates have been wrong you can say we are "x pages too short" or "if you want that extra content in the course it will be x pages to fit it in".

This works well because you can then measure up the complexity of the pages and charge more for the clever, fancy stuff or less for plain "text 'n' next" types, and you can even factor this in the charging model. Since pages are a more reasonable unit of development effort this surely makes it easier to relate to for codies.

Of course, even this falls flat when you start developing gaming type interactions that don't have "pages" per se.

If you are working with rolling media (video/audio) then time becomes objective, but learning time on typical elearning pages just isn't.

jadekaz said...

Fantastic question about estimating course time. I was just looking for info on this, and didn't find much - so I'm hoping this spurs some ideas. Another side of the picture is overall time versus chunking. We're trying to move away from loooong courses to ~30-minute segments. Estimating what fits into 30 minutes is hard - especially when you're staring at a course map/storyboard and trying to guesstimate.

Cammy Bean said...

So Dan, how do you "eyeball" that big stack of material, the SMEs head, the "this class takes three hours" and turn that into a page count?

I'm struggling more and more with these estimates as we get away from old-fashioned click next til the death models of eLearning.

@jadekaz -- I feel your pain! I've been doing a lot more chunking, too. The more I do the better I get (this looks like it should be about 15 minutes of content...) But it's SOOO hard and SOOO inaccurate.

Can we just put the pricetag on the project AFTER we've delivered it? (She says, in a whining tone of voice.)

Sameer Lele said...

I would go be creating a ISM (Instructional Strategy Matrix) which breaks content in a MLTP (Module lesson Topic Page)structure. Once this structure is made, this document can be used for two reasons, Seat time and Effort hours for estimation.

Estimation needs to account for all the activities that are needed to create this WBT for e.g (No of interactivity, No of and length of animations, no of static screen etc - which can be derived from an ISM)

Seat time can always be a thumb rule which says that if content falls in Level 2 category of complexity then the average screens that the user can complete are 40 per hour, based on which a seat time could get calculated

Seat time might not always be proportional to the estimates as Seat time is a function of content complexity while estimation depend upon content treatment.

Anonymous said...

Cammy -
A couple of more weighing in on this at Workplace Learning Today

Janet

Cammy Bean said...

@ Sameer -- thanks for you input. Do you create this ISM when you're still in the pricing phase?

Sameer Lele said...

Cammy, ISM will typically need to get created upfront at the proposal/pricing stage.

PayPalPoet said...

I use a three-dimensional model to discuss pricing.

The X axis is scope. It's linear, with a break at the point where it becomes economical to invest in building templates and development tools - a "factory" if you will. Costs more up front, but saves time over the long haul on a large project.

The Y axis is interactivity. Now, interactivity is gerally two-dimensional, with linear vs non-linea on one axis and user-control vs system-control on the other, but for estimating development cost you can squish them together. Non-linear user control (linked web pages) is the cheapest, and non-linear system control is the most expensive (guided simulation), with linear in the middle (system control is cheaper than user control, since there's less navigation to test).

The third axis is production values, with text at the bottom, followed by line-art graphics, up to data-driven real-time 3D graphics at the top. That's not a linear scale. Each point goes up by a factor ten. :-)

Draw out those three points and you have a rectangular block. The cost is the volume of the block.

A project I worked on for PLATO involved a new kind of interactive widget. We'd never built one, and had no idea what it would cost to create. So, we built a production prototype to answer that question. When we rolled that data across the whole scope of the content, it was clear that either we had to double the budget or cut something.

It would have been easy to cut out the new widgets, but they were a vital part of the pedagogical approach of the course. We'd already cut out audio and video, the only thing left to cut was the scope. So we did. By half.

It was a terribly challenging piece of instructional design, because so much of the content was so interdependent. But we made it work.

Cammy Bean said...

@Corrie - Wow, that's quite a model. I'm trying to visualize this -- do you have price points along each of the axis? I'd love to see an example if that's something you could share (if you can/are willing please send to me via gmail @ cammybean).

So many questions
What do you do in the middle of the project if you think you're going off the scale on one of the axis? Is that the PLATO example? Or were you still pricing the project out at that point? Did you build the prototype before the pricing was set?

Mind over Matter said...

So is there any industry level standard on how many screens per hour of learning at different levels of interactivity? It's really hard to convince clients who are looking for a quick bargain that 60-70 screens do not translate into one hour of learning.

Mind over Matter said...

So is there any industry level standard on how many screens per hour of learning at different levels of interactivity? It's really hard to convince clients who are looking for a quick bargain that 60-70 screens do not translate into one hour of learning.