Frequently Asked Questions
How much will it cost?

Our rates are hourly and are competitive by today’s standards. The hourly rate quoted for a given project will depend on the complexity of the project and the project completion date. We will be glad to give you more information upon request, but we cannot give you a firm quote until we have met your project.

Generally, rush jobs and jobs with a drop-dead deadline will be priced at a higher rate than a project with a reasonable, somewhat flexible deadline, as they put a greater strain on our resources. By planning ahead and allowing us to get started early enough, you can ensure that your project is assigned a lower rate. If your project is initially priced as a rush job but later becomes a less urgent project with a more “leisurely” deadline, we will adjust the hourly rate for the remainder of the project accordingly.

How do you determine time and cost?

We prepare a statement of work (SOW) based on the information that you have given us about your project. The SOW defines the scope of the project and details all of the work that must be done and the approximate number of hours each part of the project will take. We give a best case (minimum number of hours) and worst case (maximum number of hours) estimate for each. The totals of the expected maximum and minimum number of hours determine the expected price range.

As long as the project was accurately presented to us and nothing was held back, this range is a pretty reliable guide. The worst case scenario allows the inevitable minor changes, bug fixes, etc., that occur with developing software to be absorbed into the estimated price. If changes or additions are made that significantly increase the work time, or if the project scope was initially inaccurate, the estimate will be revised to include the additional work so you will have an accurate picture of the probable cost.

Does the maximum/minimum estimating method you use to determine the cost mean that you will charge a minimum price for every item, regardless of how long it takes?

No, it doesn’t. The maximum and minimum estimates are used only to come up with a realistic estimate of your total cost. We charge for the actual hours spent. During development, some items may take less than the minimum expected time while a few may exceed maximum. Most fall within the specified range. Usually, everything averages out and the total number of hours falls between the maximum and minimum estimates, and that's what we ultimately bill for.

Why don’t you charge by the page instead of by the hour?

A page doesn’t signify a measurable amount of work. Some pages can take up to an hour to write and require significant editing if the content is difficult and technical, while others, such as a page with three instruction lines accompanied by three screen captures, will take only a few minutes to write (including the screen captures and any necessary labeling) and will not require significant editing. A page that contains an illustration that we must create or reproduce may take longer than a page of easy text or instructions, even though there may be less text to write on that page. Pages are also somewhat fluid and change as the document develops and text is added or rearranged. What is actually on a given page is not stable until the manual is in its final stages. Charging by the page would make as much sense as charging by the pound.

Does specifying a maximum number of pages help control cost?

Only if your content actually fits within the number of pages you specify. If it does not, additional hours must be spent cutting the existing text to fit the number of pages. In other words, it costs more. The only other alternative would be to stop when the requested page limit was reached, even if only half the information necessary was included—not a particularly desirable solution. Other things being equal, letting the content drive your manual length is probably the cheapest.

There are, of course, documents where page count does matter, but keeping within the limits does cost more. When we edited the SME machining quarterly, we were strictly limited to eight pages. The raw content we were supplied with usually exceeded this limit by four or five pages. In addition to editing for readability, we had to cut the articles to fit. It took us 40–50 hours to complete these 8-page documents. A 20-page proposal, on the other hand, which was content-driven took 35.

If your reason for wanting to limit pages is to give the user a less overwhelming manual for a complex product or to cut printing expenses, a better approach might be to limit the scope of the printed manual to the basic information that all product users must know and cover the advanced features by other means. For a complex software package, for example, you could cover a basic subset of the available features and functions in a getting started guide, then present the complete documentation in an on-line help file.

Do you do fixed price work?

Generally, no. Most products we document are in development and it is impossible to give a fixed price. We can, however, provide you with a “not to exceed” figure, which we will not exceed without your approval. This “ceiling” price is based on the maximum number of hours estimated + 10% to provide a cushion for the “unknowns.” If the scope of the project was accurately represented and does not change, the project can be done for this price (but you do not have to pay the ceiling price if we do the job for less). If new features are added or substantial modifications to the product make extensive rewriting necessary, the ceiling price may need to be modified to accommodate the additional work. We strive to address such changes as soon as they become apparent rather than springing “surprises” later down the road.

When is the best time to involve a technical writer for product documentation?

It depends on the project. As a general rule, the ideal time is as soon as your project is defined and under way and some tangible product development has taken place:

  • For software, tangible development may be a working build of a portion of your application (one or more basic modules in place). We can document your modules/features in any order. We don’t need to start with chapter one.
  • For hardware or machinery, we can start working from drawings, prototypes, etc., and have the documentation fairly well roughed out before we see the actual beast.

Do not wait until product development is complete to call a technical writer in if you want to release the documentation with the product. If you have a long testing/quality control period scheduled (2 or 3 months) and the documentation can be written in that length of time, starting the documentation when testing starts is possible, but you should still involve the writer earlier so he or she can be ready to hit the ground running when your product is ready.

How much time should we allow for documentation?

Again, it depends on the project. The bad news is that it is usually a lot longer than you think. The good news is that much of our development time can be concurrent with product development so, if you start early enough, it should not impact your product delivery date.

Three to four months is probably ball park for the average (low to moderate complexity) software user’s manual. A manual for a small piece of hardware (such as an expansion card) with simple installation instructions and software setup can be done in two or three weeks. A complex computer-controlled machine or an enterprise-level software system with multiple manuals can take six to 12 months, depending on complexity and, for the latter, the number of persons working on the documentation.

Keep in mind that we are talking about “calendar time” here and not “person time.” You must not only allow time for us to do the job, but also for your personnel to review document drafts, test instructions and help files (if applicable), and approve the final version. If your reviewers cannot dedicate a block of time to the review and must review it piecemeal, you will need to allow more calendar time for them to complete the review. Extended calendar time, however, does not affect your cost, because we charge only for the hours we work, not the time we spend waiting for your review to be completed.

When necessary, we can speed up calendar time at our end, by increasing the length of our work day and/or adding people to the project when practical (no matter how adroitly you manage it, 9 women cannot have a baby in one month). However, we cannot significantly cut the amount of person time needed to do the job without cutting corners that may compromise the quality of the document.

Do you do on-site work?

We do not generally take on jobs where we are arbitrarily required to perform the work at the client company site. It is usually more efficient to do the work in our office, where we have the appropriate and necessary tools to produce your documentation. However, we are willing to spend as much time at your facility as necessary or feasible to meet with your staff, get acquainted with your product, and get the information needed for your documentation.

In most cases, once a project is underway, most communications (querying your technical personnel, sending or receiving information, submitting document drafts) can be handled via e-mail or, in cases of extremely large files, FTP. This is much more convenient for all concerned, as information can be exchanged quickly and at the convenience of the personnel involved. It also saves travel time and expense. When direct discussion is needed, it can often be handled via phone at a mutually convenient time. On-site visits can usually be limited to the occasional meeting and whatever time is needed to work with non-portable equipment.

Do you take on only local projects?

That depends on what you mean by “local.” Basically, we consider any location within a reasonable driving distance of Ann Arbor local. However, we do not limit ourselves to projects that meet our definition of local. We are willing to consider other locations as well. The determining factor is how much we would need to be on site to work with your project. If you think you might like to work with us, don’t let our “non-localness” stop you from inquiring.

For some projects, on-site time is not necessary. Software projects can often be handled entirely off site and we have done so with great success. As long as we have a copy of the software or access to it through the Internet, we can handle everything via e-mail and phone. Any product that can be shipped to our office (e.g., computer peripherals, cards, etc., or small machines or machine parts) can also be handled off site. For non-portable machinery or equipment, we would have to be able to schedule at least one on-site visit in order to do the job.

Can you work with companies that use the agile software development methodology?

Yes, definitely. But we must be involved in the project from its inception. These projects are difficult to estimate and it is not generally practical to prepare a comprehensive SOW, but the methodology keeps the cost under control. Because features are developed and integrated quickly and the documentation must keep pace, it is very difficult to run up the cost exorbitantly.

How can you possibly write documentation for a product or application that you are unfamiliar with?

We learn fast. But there is more to it than that. First of all, we have developed a body of broad technical knowledge over the years, from both our own experience and work we have previously done. Many times we have done documentation for an application that is similar to the unfamiliar application.

We may have never done a computer-controlled instrument that does what yours does, for example, but we have done other computer-controlled machinery and understand the basic control principles and how it operates. We can transfer this knowledge and our computer expertise to your project. All we need to do is learn what yours is used for.

What kind of applications have you written documentation for?

Click here to display a list of applications we have documented and the types of documents produced by each. They are grouped by application class.


Note: This does not currently work in Firefox. We're working on it.