When are We Going to Stop Talking About Ratios?

Home/Publications/Best Practices Newsletter/1999 – Best Practices Newsletter/When are We Going to Stop Talking About Ratios?


December 1999

When are We Going to Stop Talking About Ratios?

CIDMIconNewsletter JoAnn and Bill Hackos

“How many engineers or programmers are in the development organization? Then, we’ll know how many technical writers we should hire. Our company hires one writer for every 25 engineers. Is that the right number? Somebody wrote a book about Microsoft that said they have one writer for every three programmers. Should we follow that? What about our competitors?”

“How much money is in the budget for developing the new Grand Widget software? We should figure on 10 percent of that budget for the documentation. Or maybe the right number is 15 percent? What does Microsoft do? The Old Widget software has been around for five years now. They’re using a small staff of off-shore maintenance programmers to fix bugs and add features. The budget is really low for this product now. Does that mean we should cut the documentation budget the same amount?”

You’ve all heard comments like these. Some of you have even made them. We’ve been hearing them for the past 20 years. Engineering management seems to want a magic ratio that they can use to allocate a budget for technical documentation. If we could just come up with the right ratio so that we could get the job done. In fact, we have conducted many studies of the numbers of engineers and programmers (product developers) versus the numbers of information developers several times over several years. The ratios have varied enormously from 3:1 to 33:1 among all those studies. Ratios that vary by a factor of 10 actually give us almost no information. In fact, the variation suggests that the ratios are arbitrary, simply a matter of chance and the peculiarities of budgeting in each company.

The 1999 Study Design

In the 1999 study, we decided to pursue a different study model than simply counting heads or dollars. We asked Center members to recruit all the information developers from a single project to respond to a questionnaire and keep interaction diaries. The questionnaire asked about

  • the type of project (hardware, software), the number of information developers on the project (employee and contractor), the number of product developers on the project, the geographic locations of the product developers and the information developers, and the physical locations of the product developers and the information developers
  • the involvement of information developers in usability studies, the types of deliverables being created, and the level of satisfaction among the information developers with the information they get from the product developers

In the diary, we asked the information developers to record over a two-week period the following information:

  • the name of every person they interacted with on the project
  • the percentage of the information developer’s time spent interacting with each person
  • the phase of the project in the information-development life cycle

Ten Center members participated in the study, with a total of 30 information developers returning questionnaires and diaries.

Study Results

We found that, on average, 1 information developer interacted with an average of 7 product developers or other people during a project. Of the 30 information developers studied, we found this ratio to be as low as 1 and as high as 23. If we leave off the extremes on either side, we find that the number is between 3 and 10 with an average of 7. However 73 percent of the responding information developers spent most of their consulting time (50 percent or more) with only one or two product developers. The information developers interact only intermittently with the remaining product developers.

We found that most information and product developers spent all of their time on one project. A few were working on more than one project during the study period and, accordingly, dealt with product developers on the other projects as well.

We were especially interested in learning that there is little crossover between information and product developers when multiple product and information developers work on the same project. Each product developer has his or her own writer and generally does not interact with other writers on the same project. It was much less common for several writers to have interactions with an individual engineer but it did occur in a few of the companies we surveyed. In those instances, these multiple interactions occurred for most of the information developers on the project.

Study Picture of the Product-Oriented Organization

The emerging picture for the majority of the departments studied looks like this:

The initial picture suggests that the information developers, by aligning themselves with product developers, are organized according to the structure of the product-development activities. Individual product developers are typically assigned to a hardware or software feature or function and rarely work outside this narrow focus. Most product developers will readily admit that they don’t have much perspective on the product as a whole. The information developers, gathering information from each developer on the project, learn separately and independently about the feature or function each developer is working on. This one-to-one relationship is fine if the information developers’ role is to document the structure of the product. In this product-oriented case, the documentation tends to follow the organization of the product.

If, however, the information developers’ role is to instruct the users on how best to use the product to achieve their goals, this alignment and organization of information developer to product developer may be ineffective and possibly detrimental.

Study Picture of the Cross-Over Organization

In the product-oriented case described above, an individual information developer “owns” a product developer and is the only person interacting with that developer. We found, however, at least two departments in which the alignment differed from the typical.

In these cross-over departments, multiple information developers on each project interact with the same product developers. Instead of one-to-one, these organizations have many-to-many. The implication of the cross-over case is that the organization of the documentation does not follow the organization of the product, as it is likely to do in the product-oriented case. In these cross-over cases, the documentation may be organized by the needs of the users, the trainers, customer support, or even field engineering, or in other ways designed by the information-development management or the information developers themselves.

Here’s an example of how the information being developed might differ depending on the organizational model followed.

Product-oriented case
If the information developers each work with their own product developers, we might find a user guide with these sections for a fictional software product:


Section 1

Entering data into the system (completing fields and forms) organized by each data-entry function in the system (generally screen related)

Section 2

Maintaining the database (searching, backing up, archiving, and so on)

Section 3

Generating reports (printing, organizing, and so on)

User-goal-oriented case
If the information developers work as a team with a team of product developers, and the information developers understand the users’ information needs, we might find a user guide for the data-entry clerk with these sections:


Section 1

Opening a new customer account (gathering information from the customers, printing a paper copy report of the customer information, searching through customer accounts to find information)

Section 2

Handling a customer event (searching through the customer accounts, retrieving customer information, preparing a custom set of reports, printing a paper copy of the customer’s report)

To create information that focuses on the context in which the user performs a task, the information developer may need to know what is being developed by a host of individuals within the development organization.

However, if we want our information developers to create information that supports users in reaching their goals, they need to produce completely different information. The fictional customer information above leads to a software manual would help users know how to get started creating the appropriate information about their customer and how to create the information needed for the customer event. Notice that some of the information will be repeated in more than one context, a redundancy that users appreciate but developers often do not.

To create a manual with this information, our information developers not only would have to talk to many different developers working on diverse parts of the product, several of our information developers would have to talk to the same developers. In addition, they’d have to interact with people in the organization who could help them understand the users’ goals. But, most important of all, our information developers would need to learn about the users directly and thoroughly understand the context in which they plan to use the software product.

Organizational Structure Matters

What the CIDM ratios study demonstrates is that the organizational structure that governs the relationship between information and product developers is extremely significant. We need to look at structures carefully because they may define how well we support our users.

If our budgets and staffing are determined by the number of developers, we are likely to emphasize supporting the developers and creating product-oriented, system-focused information.

If we are focused on supporting users rather than developers, we must develop our own projections of the scope of our work, independent of the product-development activities. We must learn what users need to know and how best to provide them with information that supports their performance. In fact, we may have to spend more resources supporting users on products that may have small development budgets.

We need to remember that Form follows Function, not in terms of product functionality but in terms of user functions. The form our information takes must follow the needs of our users to be successful in their jobs. To do so, we must allow information developers to focus on the users rather than on the developers. CIDMIconNewsletter