5 Replies Latest reply on Jun 25, 2008 4:27 PM by CatBandit

Calculating Development Time

Is there a formula used to calculated development time for each captivate screen?
• 1. Re: Calculating Development Time
Hi Nick

I'm not sure if there is any published formula for this. The time probably varies from developer to developer. What some may create quickly and easily may take many times longer for others. I recently sat in on part of a presentation at a conference where the presenter claimed that a 300 to 1 ratio is common. Meaning, for each minute of play time, count on estimating 300 minutes of development. This person did say that this ratio was subject to change as one becomes more familiar with the process.

Perhaps the page linked below will help.

Cheers... Rick
• 2. Re: Calculating Development Time
Hi Nick,

A couple of years ago the eLearning Guild came out with a study that put the development time of interactive elearning (not specifically Captivate) at 1.87 hours per minute of course time. I've found that it usually takes longer, so I like Rick's number! I may start using that one instead of the 2 hours per minute (I upped it a bit) that I've been using!

ERR229
• 3. Re: Calculating Development Time
> I'm not sure if there is any published formula for this. The time probably
> varies from developer to developer. What some may create quickly and
> easily may
> take many times longer for others. I recently sat in on part of a
> presentation
> at a conference where the presenter claimed that a 300 to 1 ratio is
> common.
> Meaning, for each minute of play time, count on estimating 300 minutes of
> development. This person did say that this ratio was subject to change as
> one
> becomes more familiar with the process.

300:1 is the ratio that has been quoted for 10 years or more **for highly
interactive content**. That would be content with lots of interactivity, and
would include some sound and video. And that includes time for everyone
working on the project - research, script writing, filming, sound recording,
editing etc etc in addition to coding.

Reduce the amount of interactivity, sound and video and you can greatly
reduce development time. Modern tools and methods have greatly reduced the
amount of work required to create an hour of training. In my current
organisation, I'd estimate 30 to 50 hours work for one hour of training.
Interactivity can be high, but currently we use no sound or video.

could get figures as low as 10:1 and much higher than 300:1.

Steve

--

Adobe Community Expert: eLearning, Mobile and Devices
European eLearning Summit - EeLS
http://www.elearningsummit.eu

• 4. Re: Calculating Development Time
I like all of your answers and they are both honest and all over the place, just like you might expect. My personal experiences are varied, but I spent 10 hours on one 10 minute presentation / Quiz set so that is a 60:1 ratio.

A lot of the answer depends on Subject matter Experts (SME's) and getting the materials. But then a great deal depends on the depth of the visuals, photos, crafty scenarios or stories laid out and other "creative" factors that take time to get just right.

So lets consider three other things (as if the folks above didn't add enough?).:
1. Workflow - You will be more efficient at times recording a demo without sound and then pruning out the duplicates and mistakes before recording sound. You will probably be better off with Microsoft PowerPoint as the layout tool if you are developing something that is not a software demo or simulation since it edits so fast.

2. Experience - Your personal proficiency is important to the equation. I could redo the 10 hours of work that I did in about 2 hours if I had the ideas and screen designs all set and ready to go. So planning becomes part of your experience level and then the software becomes more familiar to you and you'll find that presentation 2 is 20% faster than presentation 1 and then you'll vut another 10% or so in the next few and if the phones and coffee buzz are just right, you'll be flying at the 20:1 or 30:1 level.

3. This applies only to presentations and not software demos or simulations. Templates. A good template with your cover slide, back slide, favorite quiz setups, flyover pre-test mockups and any navigation bars, e-Learning (SCORM, Etc.) settings will save you a bit of time and frustration. You'll gain a familiar user interface for the end user and you will be more efficient.

My vote is for all items noted in this post. Planning and experience plus a degree of interactivity make the efficiency.

Joe C.
• 5. Re: Calculating Development Time
Some good ideas ... and obviously, some differences, but the differences can be explained by the differing attention paid to the preparation stage of Captivate development. BTW, Kevin Seigel, in his book " Essentials of Adobe Captivate 3" does give some reasonable time-lines on this subject.

Joe Caplin (retro74) came closest to saying what I was thinking ... but I'd like to elaborate by saying that the more time spent in the preparation stage, the less will be required to build the actual project. I've spent as much as a week on the "design" elements decisions, with a pencil and a lined legal pad - without even opening Captivate (almost). During that preparation stage the only thing I will open Captivate for is to try out and test ideas like fonts, colors, and so on, before making a final decision on a particular issue.

Most projects do not consist of a 10 minute movie, but a whole series of individual topics (movies) which, taken as a whole, make up the entirety of the Subject Matter. So for one project, you may be building 40 movies, or 200, or 10, to cover the range of your subject. And the more specific you are in laying out the parameters of each topic ( some as simple as a background, and some as time-consuming as the actual dialog to be used in each - the "script") ... and in selecting those criteria that will apply to all topics ... the better off you will be on the development-time-to-completion-line when the actual "Captivate work" is begun.

All of which is to say, until you answer the question of planning time, you cannot answer the question of development time, because it is all-inclusive. Planning is critically important to some developers, and paid only lip-service by others.

Larry