See instructions below on how to use the calculator.

If you see only a grey box, please install the current Java Runtime Environmnet (JRE) application. Click here to download the JRE - Click on "Download J2SE JRE"

Evaluating complexity

In any decision-making process, of which estimating is an example, we evaluate the risks associated with each possible decision. For example, when I decide to build a new house and apply for a mortgage, potential lenders evaluate the risk of the investment. They estimate the probability that I will be able to repay the loan. In this estimate, they may include such risks as the likelihood that the government will change the tax laws and disallow the deduction for interest payments. If this happens, what is the chance that I will still be able to repay the loan? They consider the likelihood that property taxes will increase or insurance costs will go up.

For complex decisions of this type, it is possible to use probability calculations for each of the risk factors and look at the effect of the accumulation of risk factors on the ability to repay a loan or to make money on an investment.

In determining the risks involved in completing a publications project on time and on budget, some years ago my organization developed a simple assessment tool that we call a Dependencies Calculator.

The Dependencies Calculator uses straightforward linear relationships that are weighted according to level of importance to allow a project manager to assess the risks involved with a project. The Calculator asks the project manager to assess dependencies, or factors, that may influence the success of a project or make it easier or more difficult to perform.

To assess a dependency, the project manager rates the dependency on a scale of 1 to 5, where 1 is the best case and 5 is the worst case. For example, if the project manager knows that the technical team on the current project rarely completes its reviews on time and review comments are often incomplete or indecipherable, then he or she may choose a factor of 4 or 5 on the scale for the review dependency.

This means that the problems associated with publications reviews in the organization are likely to increase the difficulty of completing this project in comparison with other projects in which reviews are handled in a timely and professional manner.

Deciding that, in terms of reviews, the current project is about average for his or her organization, the manager would choose a 3 on the scale. The 3, as the center point of an odd-numbered scale, represents the average project for a particular organization. A 1 or 2 represents a better than average project; a 3 or 4 represents a worse than average project.

The first five dependencies in the Dependencies Calculator are labeled external dependencies because they describe risks outside of the publications organization and the project manager's sphere of control. The external dependencies are

product stability/completeness
information availability
prototype availability of the product
availability of subject-matter experts
effectiveness of reviews (information inspections)

The four internal dependencies are those that may be within the project manager's ability to influence. The internal dependencies represent the publications staff's

technical experience
writing and document design experience
audience understanding
team experience

The following table lists each dependency and provides an interpretation of its meaning. Let us look at an example of the application of the dependencies to a project. At Fateful Software Company, the publications project manager, Eleanor, knows that they produce user guides at an average of 5 hours per page at the company's standard level of quality. However, user guide projects vary. Some are easier to complete; others are more difficult than average.

Dependency	Interpretation
Product stability/completeness	The amount of change the product is likely to undergo during the course of the project. A product that changes drastically during the development cycle, especially when major changes occur late in the development cycle, its likely to require frequent changes to the draft publications.
Information availability	The existence and quality of written information about the product, including marketing studies, requirements definitions, specifications, user profiles, task analyses, and other information that will help the publication team understand the audience and product as quickly as possible. A lack of planning information may mean that publications is being included early in the development cycle. It also may mean that little planning has been done for the project—a good predictor of numerous and late development changes. Information availability is one of the factors that may contribute to a reduction in hours per page for revision projects. If the publications team is working with a high-quality earlier version of the documentation, then the job of learning the new information and fitting it into the existing structure is made easier.
Prototype availability	The existence and quality of a prototype of the product under development. The existence of an early prototype often indicates the sophistication of the development team in their planning. It also reflects on the stability of the product design. The lack of a prototype may make it difficult for the publications team to develop an accurate use model (a picture of how the user will perform a task using the product).
Subject-matter expert availability	The availability of the Subject-Matter Experts (SMEs) to aid the publications team. SMEs, or technical experts, are important sources of information for the publications team. If they are too busy, unavailable, or lack knowledge about the development effort, they may impede the progress of the publications effort. Cooperative SMEs who look upon publications specialists as equal development partners can greatly reduce the difficulty of a publications project.
Review experience	The likelihood that reviews will be thorough, complete, and timely. Thorough and timely reviews or technical inspections of draft documents are essential to the success of a publications-development project. Poor reviews can impede progress or require costly reworking at the end of the project life cycle.
Technical experience	The degree of technical experience your team has with the new product. Every publications team has a learning curve on a new technical project. The writers and others involved in the project must learn the technical matter to be addressed. While not every team member needs to be technically skilled in the area of interest, team performance accelerated if some team members are reasonably familiar with the technical subject matter.
Writing and design experience	The amount of writing and design experience your team has with the type of publications. Especially when they are involved in designing documents that represent a new approach to the information and the audience, publications-team members may also experience a design learning curve. When the document types are familiar and the team experienced in their design, this learning curve may be reduced. This dependency may also be used to account for changes in the word-processing and desktop-publishing tools available to the publications team.
Audience understanding	The degree to which your team understands the audience requirements. While we expect the publications team to conduct a user and task analysis at the beginning of the planning phase of a project, the more they already know about the intended audiences, the more effective they may be in designing and conveying information.
Team experience	The amount of experience your individual staff members have working on teams. If you are a project manager of a publications team, the experience you have in working with the individual team members and their experience working together effectively may enhance your ability to complete the project on time and on budget. The less experience you have working with your team members, or they with one another, the higher the risk.

Eleanor uses the Dependencies Calculator to decide on the direction and degree of variance from the norm. After studying the risk factors, Eleanor details the current project as shown in the following table.

Dependency	Interpretation
Product stability = 4	The current project is being handled by one of Fateful's best software development managers, Janice. Janice has a reputation for extensive planning and allowing few changes to the product after initial specification and prototyping. However, the marketing manager is often late in bringing in requirements information, a problem that may affect product stability. In addition, Eleanor's team is new to serving on the development team and will have to learn to react appropriately to the inevitable design changes that occur early in the development life cycle.
Information availability = 5	The publications team will be involved from the first day of the product-development cycle. That means that little if any information will be written about the product. However, the publications team will be involved in the analysis of the audience and tasks and will have sufficient time to learn about the product during the team meetings. While the involvement in early development activities may mean that little information will be available at project start-up, early involvement will have a positive effect on other dependencies and the overall success of the project. The early activities will require more time from the publications team since they have never been involved this early before.
Prototype availability = 3	The product manager, Janice, is well known for designing and testing software prototypes. The publications team will be involved in evaluating the design and recommending changes to decrease the volume of information required to support the product.
Subject-matter expert availability = 2	Janice always insists that her development team cooperates with publications. The SMEs are usually available and genuinely interested in the success of the publications. However, two of the engineers have difficulty communicating in English, which may present some degree of risk. And, there's a user group meeting scheduled for Germany that will take three top engineers away at the same time.
Review experience = 1	The reviewers on Janice's projects always do a good job. Careful reviews are part of their assignments.
Technical experience = 2	Eleanor believes that the technical content of the current project is about average for her team. They have worked on similar technologies before. One senior member of the team has considerable technical experience in the area; the more junior team members have less experience. One important point, however, pushes Eleanor's thinking toward a 2 rather than a 3 rating for this dependency. The entire team will be involved in the development of the product from start-up. They will have the opportunity to learn about the product as it is being created.
Writing and design experience = 4	The publications department has designed and written user guides of this type before. Nonetheless, Eleanor wants to challenge the team to think creatively, especially in terms of a more minimalist approach to the information. In addition, Eleanor has a number of new employees to work with who have strong credentials but lack experience with Fateful's design guidelines.
Audience understanding = 3	Marketing wants to direct this product toward a different audience than previous Fateful projects. The team will have work to do in analyzing the new audience and understanding how its needs differ from Fateful's traditional audience. However, they will have the early development life cycle to work on the analysis. Eleanor selects an average value of 3, rather than a higher risk factor of 4 or 5 because of the special circumstances.
Team experience = 5	Eleanor is concerned about the inexperience of several members of her team in working together. The most senior member has been a strong individual contributor but has a reputation for impatience and intolerance for less experienced people. Several of the team members are new to the company. Eleanor knows she has considerable work to do to weld these individuals into a smoothly working group.

In summary, Eleanor's choice of dependencies ratings looks like this:

Product stability = 4
Information availability = 5
Prototype availability = 3
Subject-matter expert availability = 2
Review experience = 1
Technical experience = 2
Writing and design experience = 4
Audience understanding = 3
Team experience = 5

When Eleanor runs the Dependencies Calculator, she finds the current project to be somewhat more than 10 percent more difficult than average. Since 5 hours per page for user guides is average at Fateful, Eleanor estimates that the current project will take 5.6 hours per page.

Guideline: Develop a dependencies calculator of your own to reflect the situations that are likely to affect the difficulty of getting a project done in your organization.

Using the Dependencies Calculator

To calculate the hours per page (hrs/pg) for the current project:

Multiply the average hrs/pg by the total composite risk factor.
Or, project hrs/pg = average hrs/pg x total composite risk factor (see the calculation below).
The average hrs/pg is derived from your company or organization's previous experience. Fateful's average hrs/pg for user guides is 5.

To calculate the total composite risk factor:

Using the 5-point scale, rate each dependency.
For the product-stability dependency (the first factor in Figure 8.19), find the composite score in the table below for the risk level, or factor, you have selected.
Composite scores for the product-stability dependency

Factor Composite score

1 0.80

2 0.90

3 1.00

4 1.10

5 1.20

Note: The composite scores for product stability are twice the scores for the other dependencies. This indicates that product stability is weighted more heavily than each of the other eight dependencies.
For each of the remaining dependencies listed in Figure 8.19, find the composite scores in the table below.
Composite scores for all other dependencies

Factor Composite score

1 0.90

2 0.95

3 1.00

4 1.05

5 1.10

Multiply all nine composite scores by each other. For example, for Eleanor's current project the multiplication appears as follows:
1.10 x 1.10 x 1.00 x 0.95 x 0.90 x 0.95 x 1.05 x 1.00 x 1.00 =1.135
Multiply the composite score by the average hrs/pg. In Eleanor's example, multiplication appears as follows:
Project hrs/pg = 5.00 x 1.135 = 5.7

For the nine dependencies, each composite score represents an increase or decrease in difficulty of 5 percent from the average. When the rating factor equals 3, the composite score is 1, indicating no change from the average. For product stability, the increments above and below the average are 10 percent. Note that a project that is perfectly average would have ratings all equal to 3 and composite scores all equal to 1.00. Multiplying nine 1.00s by each other yield a product of 1.00. Multiplying this total composite score by the average hrs/pg yields a current hrs/pg exactly the same as the average.

The Dependencies Calculator is based purely on empirical data, the many years of experience I have had estimating projects and comparing actual project data with the original estimates. To find the right mix of dependencies and factors for your organization will also require trial and error. I suggest that you experiment with the values presented here and make modifications as you learn more about the factors that affect the complexity of your projects. If you want to change the composite scores, always be certain that the midpoint (factor = 3) is 1.00. The increments above and below 1.00 need not be equal, but if they are not equal, the relationship among the scores will no longer be linear. Be careful about assuming nonlinear relationships without carefully testing the results.

The nine project dependencies have worked well for years in helping us to assess difficulty of performing a particular project. However, you may find it advantageous to develop your own list of dependencies. If you elect to do so, look closely at the risks that exist in your organization. What influences project success? Why do some projects go over budget and schedule? Why do others finish on time? What is the difference?

Guideline: Use the dependencies calculator to evaluate the composite risk factors of your project.

Calculating total project hours

Armed with a dependencies calculation of the relative complexity of the current project and your early indicator of the size of the project, calculating the total hours required to complete the project is now a simple matter. The total hours required to complete the project equals the number of pages in the document times the calculated hours per page (complexity metric).

For example, Eleanor, the Fateful project manager, calculated the hours per page for her current project to be 5.7. Based on the Information Plan, she and her planning team believed that the user guide for the new product would resemble a user guide created for a similar project 2 years earlier. That guide was 168 pages long. Using her previous experience, the team then looked at the functionality of the new project and compared it with the older one. They found that marketing had suggested that the new product would have more functionality than previous projects. The early indicators, then, suggested an increase of about 15 percent. Using this information, they calculated the size of the new user guide to be 192 pages, or 15 percent larger than the old user guide.

Then, Eleanor multiplied 192 pages by the complexity factor of 5.7. She found that she could estimate that it would take 1,092 hours to complete the current project. The total of 1,092 hours would include all the time required for project management, writing, research, editing, illustrations, and production of the camera-ready copy, as well as the time required to see the book through printing and into the correct distribution channels.

From the book, Managing Your Documentation Projects, by JoAnn Hackos.