Estimating Work

[mitches]

Has anyone come up with a way to estimate the time needed to create or make changes to the Help files?

We have a product that currently has roughly 200 main pages (screens) with 5 to 15 portals per screen. We are providing both context sensitive online help and a User’s Guide. We have developed the portal information as snippets. Most show up several times, others are ubiquitous.

We are trying to estimate the impact of changes. I’ve seen equations estimating test time as a percentage of the amount of time the developers have estimated for their change/update/fix. Does anyone have something like that?

I could see estimating based on how many pages, images, or portals changed, if that can be determined.

[LTinker68]

I hate estimating how long it takes to do something. I'm invariably wrong. So I don't have any suggestions, except to make sure you include the time to compile. The amount can vary significantly depending on the number of topics you have, how many masterpages you have, how many snippets, how many index terms, how many conditional tags, if the project is on your local drive or a networked drive (and therefore the speed of your LAN), the processing speed of your computer, etc., etc.

If this is an existing project, then I suggest you run the compiler and mark the amount of time it took to complete. Include the amount of time it takes to copy/publish the files to their final destination. That becomes your base time estimate.

The amount of time a writer takes to make changes depends on how familiar the user is with Flare and their understanding of the software/process they're documenting. That would be harder to estimate and the part I run into problems with.

[RamonS]

I'd write down the details of the work needed and then take a good guess. Then put that sheet of paper somewhere and look at it again in a day or two. Once you think that your guesses are reasonable, double that time before passing it on to the project manager (who, if not crazy, will add at least 50% more as well). Keep in mind that this work includes communication (email, phone, in person), documentation of the work done (such as a status report), discussions about change requests (you are asked to do something that is impossible or just doesn't make any sense) and so on. Also, when asked for an amount of days, count days as 6 hours, not 8. And even six hours is very optimistic depending on what else you may have to do.

What kind of funky equations did you see? Test time is at least the same as development time, typically more since one small change in code can introduce bugs in all kinds of different places. An edit is to be considered taking the same time and effort than starting from scratch. I just spent two weeks testing a mod that on the surface results to three new text boxes. Don't let anyone talk you into cutting corners. When it comes down to crunch time they forget about that and conveniently blame you.

[KevinDAmery]

Also take into account how extensive the changes are. For example, a change to a screen could be cosmetic (buttons moved around but the functionality is basically the same) or could be fundamental (e.g. the entire workflow is different now). A cosmetic change could take only a few minutes to document, whereas a fundamental change would basically involve rewriting one or more topics from scratch. So basing a calculation solely on how many screens changed could be wildly inaccurate--you also have to consider the magnitude of the change to each screen.

If you haven't read it before, you may want to track down Joann Hackos's book "Managing your Documentation Projects" to get a better handle on estimating.