See instructions below on how to use the calculator.
If you see only a grey box, please install the current Java Runtime Environment (JRE) application.
Click here to download the JRE - Click on "Download J2SE JRE"
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
||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.
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.
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
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
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
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.
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.
|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
|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
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
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
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
Composite scores for the product-stability dependency
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
- 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
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
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.