|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2006 --> Estimating project times and costs
Vous êtes ici : Essais --> 2006 --> Estimating project times and costs
By Geoff Hart
Previously published as: Hart, G. 2006. Estimating project times and costs without losing your shirt—or your sanity. Intercom April 2006:6–10.
Determining how long it takes to complete a job is essential for planning and for budgeting your time, whether you're a wage slave or a freelancer. In this article, I'll focus on the needs of the freelancer, but the same approach will work equally well for managers of teams of technical communicators and even for lone writers, for whom the "client" is a fellow employee such as the software development manager.
As a freelancer, it's natural to want to charge your clients by the hour. Those times we end up with a particularly hideous job, this approach provides the comfort of knowing that we'll at least be fairly compensated for our time. Clients, on the other hand, prefer fixed-price estimates for a job so they won't be the ones with an unpleasant surprise, and that's doubly true for new clients who haven't yet learned to trust our professionalism.
When the client won't accept an open-ended estimate, how can you estimate the cost of a job without losing either the client or your shirt? On the one hand, you need to protect yourself against the truly appalling jobs that will take years off your life span. On the other hand, you need to be able to bid low enough that the sticker shock won't kill the client before you can collect your paycheque.
There's good news and bad news. The bad news is that there's no way to estimate a job's cost perfectly every time—clients and life are both unpredictable, and the less mature and controlled the client's planning process, the less predictable the work. If you're an editor or translator, you can ask to see the whole mess before you have to quote a price, and that lets you look for the trouble spots and inflate your quoted price accordingly. If you're a writer, the task is considerably more difficult.
But there's also good news. With a little ongoing effort, you can gradually develop a good feeling for your own productivity and use that knowledge to estimate reasonably accurate costs. The key is to track your productivity for each of the different types of task you do as part of your work.
Over the years, I've acquired a good idea of my range of productivities for various types of work. I work primarily as an editor and translator, and for each job I've done, I've recorded the number of words and the time it took me to do the work. As a result, I have many years of productivity data (words per hour) for most of my clients. This data gives me two key things I need to know before I predict how long a job will take and how much it will cost:
This data makes it possible to provide highly accurate estimates of the total cost of an editing or translation job for specific authors or corporate clients, even without seeing the manuscript. (I still ask to see the manuscript, but unfortunately, this often isn't possible.) If a new client asks me to bid on a job, sight unseen, I can offer them my worst-case price, thereby protecting myself, then point out I can almost certainly do better than that price. If I have a large multi-author job, such as a few books that I've recently edited, my long-term average productivity for (literally!) hundreds of authors provides a reasonable estimate for any other group of authors. Where more precision is necessary, I can examine a subset of data based on the native language of the client (e.g., for my Japanese, Chinese, French, and Turkish authors, among others) and for the type of project (e.g., Web page vs. journal article) to see whether that type of work has traditionally posed unusual problems.
To estimate the cost of a job, I need only divide the actual length of the job (in words) by whichever productivity value seems most appropriate for the situation. That tells me how long the job should take. If I lack confidence in this estimate for whatever reason, I can inflate the time by a percentage that represents my level of discomfort: the less comfortable I am, the more I'll inflate the time. I can now multiply this time by my standard hourly rate to come up with a base price. We'll return to that base price later in this article.
The benefits of my approach are clear: it provides a reliable method for generating reasonably accurate initial estimates. If you haven't been tracking your productivity, start now. Over time, you'll develop similar confidence in your ability to predict time requirements, and thus, costs. It's crucial to note that "industry benchmarks" for productivity are useful if you have no data whatsoever, but the only truly reliable data are for your own personal productivity.
I'm a firm believer in simplicity, so I track my editing and translation work using only word counts and completion times. I maintain this information in a simple word processor file using Word's table feature; now that I'm working full-time as a freelancer, I'm planning to migrate this data into a spreadsheet so I can automate the process of calculating productivities for each category of job or client. If you do the same kind of work that I do, either approach may meet your needs.
If you do different work, such as technical writing, you'll need different data to be able to plan and budget effectively. You can still do a reasonably good job with a simple approach, but that simple approach must reflect the actual nature of the work. For example, let's say you're creating an online help file. Here are some typical tasks you should track:
There are clearly many other tasks, but this is a good starting point. Once you have this information, you can begin developing a good idea of the time it takes to perform each of these tasks: simply look at the clock when you start a task, and again when you end. That's how long that particular task took you to complete. Now you need to determine how many tasks there will be, because multiplying the number of individual tasks by the time to perform those tasks gives you the total time. Thus, your next step is to identify the number of items you'll have to deal with. Count up the number of menu choices, dialog boxes (and fields, checkboxes, icons, tabs, and other components for each dialog box), icons, fields, overview topics, tutorial topics, and reference topics. There are others, but that's a good start.
The client may provide this checklist of the work you'll be required to do, or you may have to generate that list yourself. In either case, this list becomes the basis for your planning: you will document everything on the list within the time you have quoted and for the specified price, and everything else will be billed at an additional cost.
Unfortunately, some items will be substantially more complex or difficult to document than others. For example, a dialog box that will be undergoing continuous revision until the product ships will clearly take far more time to document than a feature that has been frozen for months and will not be revised again. The next step is to account for this additional difficulty by increasing your estimated time sufficiently to account for such difficulties.
I call this a weighting factor because you're using it to increase the weight (difficulty) of the job and thus, to increase your estimate of how much time it will take. There are several ways to calculate a weight, but again, you can start simply and develop a more sophisticated approach as time permits or as your needs require. If the problem you'll face is that each topic will have a different and unknown number of subtopics, come up with an educated guess at how many subtopics there will be; add that to your estimate, with a note that additional subtopics will require more time and money to complete. If the problem is that the interface isn't stable, estimate the number of revisions you're prepared to endure, then use that as the basis for your estimate; each revision counts as a separate documentation task, and any additional revisions will also take longer and cost extra. If the problem is that you expect to have difficulty reaching the subject-matter experts (SMEs) who will provide key explanations of how things work, add an hour—or three—to account for this wasted time.
Are we done yet? Not if you want to truly account for all the likely difficulties. Any dialog box with 15 fields will have interactions among the fields and possibly interactions with other product features. For example, the Page Setup dialog box for desktop publishing software has two different page orientations (portrait and landscape), and these will combine with the page's two dimensions (height and width) and four margins (top, bottom, left, and right) and number of columns (plus one "gutter" per pair of columns). Clearly, you must explain how changing the orientation affects the dimensions, and how this in turn affects the margins, columns, and gutters. Plus, there may be idiosyncrasies of the software that must be documented; for example, some desktop publishing software won't automatically reflow text if you change any of the abovementioned parameters of the page.
Complicated, huh? Yup. The basic idea is simple to state, but far more difficult to implement: Your goal is to learn how to break up a higher-level task into its most basic ("atomic") components because each of those components will typically take you around the same amount of time to document. Begin tracking the time it takes you to perform each of these lowest-level tasks. This tracking will increase the time it takes you to complete a job, and under deadline pressure, you won't have time to record a fine level of detail for every task. In that case, try to at least track times for the higher-level tasks. Obviously, this will provide less precise estimates, but the good news is that you don't have to track the times for every single task that you're tracking. Larger amounts of data provide a better idea of your long-term average, so you should certainly keep collecting this data for many different projects, but even a sample of as few as ten or twenty tasks will let you generate a reasonable average.
You'd think it's obvious that a "contractor" would work under contract, but over the past 20 years, I've seen an unending stream of problems that resulted from fellow contractors working purely on the basis of verbal agreements or a loosely worded contract. If you're going to all the trouble to track your productivities, it's foolish to throw out all that work. Instead, use it to protect yourself by including that information in a formal written contract. Hire a lawyer to create a standard contract for large or complicated jobs and review any modifications required to adapt that contract to a specific job. For smaller jobs or for work with a reliable, long-term client, a clearly written, simple, and precise description of the scope of the work may suffice.
As I noted earlier, you must create a clear list of all the tasks that you propose to perform for the client. All that information on dialog boxes, menu choices, and the like that I suggested you record now becomes your blueprint for the work you'll be doing. This list becomes the specifications for the job, and should be added as an appendix to the contract, accompanied by sentences similar to the following: "This contract applies exclusively to the work described in Appendix 1. Any added features to be documented must be added to this contract in an additional Appendix that has been dated and signed by both the client and the contractor. Any work not specified in Appendix 1 will be billed separately at a rate of..." Make sure that the client reviews and signs off on the list in Appendix 1 so they can't blame you for forgetting anything. If the scope of the project expands, create an Appendix 2 (and 3, and 4...) that defines the new tasks. Create as many of these additions as necessary.
Since the review process represents a major source of lost time, explicitly define how many reviews you're prepared to endure. My standard contract specifies that I will include one review and revision cycle in the initial cost of the contract. (That is, I will submit the job, receive a review document containing a list of changes, incorporate those changes, then return the revised document and go on with my life.) Each additional review and revision cycle will be billed separately. This encourages the client to do their reviews right the first time, since sloppy reviews that require additional rework will clearly increase their cost.
Don't forget potentially expensive details, such as "shipping and handling". Nowadays, most work can be done electronically and "shipped" by e-mail. But you may still have to cover shipping costs for the product, particularly if that product is hardware, and some clients insist on on-paper reviews that must be exchanged by courier. However, even software can become expensive; for example, you probably don't want to download a weekly 600 megabyte installation CD containing the latest build of the software, even if you have a high-speed Internet connection. If you'll have to travel several times to meet the client or their SMEs, send dozens of faxes when e-mail won't do (e.g., for signatures), or (like me) spend a lot of the time on the phone or in e-mail conversations to resolve difficulties that require a conversation, plan for those costs too. (Sometimes you can hold your conversations using instant messaging software. Sometimes you can't.) All these things take time and money, and you'll need to specify in the contract who pays for that time and those costs.
If you collect the kind of information I've described for each job, you'll develop an increasingly sound, objective basis for estimating jobs accurately—or at least as accurately is possible given that your clients will sometimes be Dilbert's pointy-haired manager. Earlier, I mentioned the concept of a base price. If you plan and bid on jobs based solely on this base price, you'll rarely finish when you predicted or earn your desired hourly rate, because Murphy's law inevitably affects even the most carefully planned project. More factors than I can possibly describe can foul up your schedule beyond belief.
These things include the necessity to hunt down elusive or reluctant SMEs, programmers, or engineers who are responsible for producing the product you're documenting. If you need them to explain obscure product features or review your documentation, their absence will cost you. Find out when they plan to go on vacation, and whether any of them have announced an intention to leave to work for another company. Plan for lost time when these people simply take a disliking to you and learn to avoid you, possibly because they're already highly stressed trying to meet an insane deadline and they don't have time for your repeated inquiries, no matter how reasonable and considerate those inquiries may be.
Then there's "feature creep". As we all know, a product interface can change dozens of times before a product ships, even when the same basic features are preserved, and the situation is worse if the project "managers" (to misuse a term) add features daily as the work progresses. The specifications checklist I mentioned earlier is your only protection against feature creep, but even with a clear list of specifications, someone must take responsibility for finding out what new features have been added so that the new features can be documented. Well-managed development teams can provide this information, but many times you'll simply have to budget time to explore the interface to find out what changed since the last build. Fail to do this, and you'll deliver incomplete documentation when the product is ready to ship, and that can lead to considerable unpleasantness.
You'll also discover that some clients are very high-maintenance—they require lots of handholding, endless conversations to reassure them, and countless nag notes sent by e-mail or voicemail to remind them to answer your questions or return documents sent for review. Time is money, and if you don't account for this ongoing maintenance, you'll lose that money on each project. Plan for a certain amount of this time based on your initial impressions when you discuss the project with the client, and the more hesitant, vague, or unprepared the client, the more time you should add.
Over time, you begin to develop a sixth sense for which projects are going to cause problems and how much these problems will delay you. Based on that feeling, you'll be able to come up with an educated guess—and never forget that this is only a guess—of how long a project is likely to take. If you get the feeling that a client is disorganized, and will require endless handholding, pad your estimate accordingly to account for this extra time and effort.
How much should you pad your estimate? There's no easy way to know. If you add too high a safety margin, you'll inflate the price enough to intimidate the client. You may even lose the job if others are bidding against you and working with less of a safety margin. If your existing clients have been satisfied with your work, they're more likely to accept an inflated price, particularly since it's human nature to willingly pay a bit more for the peace of mind that comes with confidence. For new clients and in competitive bidding situations, you may need to cut your safety margin to the bone to earn that critical first job. You won't earn as much per hour as you expected, but doing a great job for a bargain price may earn you the right to be their sole supplier, and based on the data you accumulated during that first job, you can come up with a better estimate next time.
If you can accept that planning and bidding on jobs will always be somewhat uncertain, you can use the techniques described in this article to minimize the unexpected, can learn to embrace that uncertainty, and can perhaps even come to enjoy it. But even if you can't, you'll sleep easier knowing that you've done your best to protect yourself.
©2004–2024 Geoffrey Hart. All rights reserved.