Lead Writer: Kieran Morgan | Peer Reviewer/s: Steve Moss | Managing Editor: Kieran Morgan

This chapter guides technical writers in estimating the time and cost of documentation projects. It introduces essential project management theories and practical tools tailored for documentation projects. The chapter outlines a step-by-step process for developing an Estimating Sheet, crucial for creating a realistic work overview and basic cost breakdown. This is a precursor to making a Project Schedule, equipping writers with the skills and knowledge to confidently manage project variables like scope, time, and cost.

Who Should Read This
• Career Advancers • Cross-Domain Professionals • Managers of Technical Writers • Project Managers • Consultants
Table of Contents: Project Management for Technical Writers
Previous: Chapter 6: Define Review Team	Next: Chapter 8: Develop Schedule

1. Introduction

Imagine seamlessly planning the timing and cost of a documentation project, transforming one of the most daunting tasks for a technical writer into an empowering experience. Many of us, as technical writers, aren’t formally trained in project management and might feel out of depth with advanced tools like Microsoft Project, or even unsure about how to leverage them effectively.

But here’s the good news: you don’t need to be a project manager to ace this. With some clever tactics and the right tools, you can estimate the timing and cost of your documentation project.

In this chapter, we outline the process of developing an Estimating Sheet, an essential step before creating a Project Schedule. We demonstrate key techniques and concepts used by project managers, but tailored for documentation projects, making the process simpler and more straightforward for you. Think of this chapter, and the next, as a crash course in project management designed for writers.

This chapter helps in scenarios like:

• Launch-Aligned, Complex Project. Your documentation’s due date coincides with the launch of a product, feature, or sprint. Your main goal is to work efficiently, ensuring your documentation is ready by the launch date. But you’re concerned about completing a large project in the allotted time.
• Project Estimation for a New Project. You’re leading or bidding for a new documentation project. Your manager or client wants a realistic estimate of the time and cost involved, but you’re unsure how to approach this process and develop a professional-looking schedule and budget.

In both scenarios, following the steps in this chapter is beneficial. We introduce basic project management theory, enabling you to discuss project aspects confidently. Our step-by-step process will help you produce a realistic scope of work and a basic cost breakdown. This process is supported by our Documentation Project Estimating Sheet Template.

Developing a solid estimate is just the starting point. Next, in Chapter 14: Develop Schedule, we’ll focus on transforming these estimates into a Project Schedule.

2. [Theory] The Iron Triangle

Before you take the plunge into estimating and scheduling your documentation project, let’s get familiar with some basic project management concepts. This will give you the language you need to talk about the planning aspects of your project like a pro.

We begin with the “Iron Triangle,” a cornerstone concept in project management. It emphasizes that most projects, including documentation projects, hinge on four critical elements: time, cost, scope, and quality.¹ A deep understanding of these factors and how they interconnect with your project is vital. By mastering this, you’re better positioned to steer your project successfully towards its goals.

Yes, we know, four elements does not a triangle make; nevertheless, this is how it’s commonly referred to in the world of project management!

Here’s a breakdown of these variables:

• Scope is what you’re delivering in your project. It’s something you define in your Documentation Plan in its list of deliverables, and at a more granular level when you’re developing your Estimating Sheet. The table of contents that you develop in Chapter 15: Design Structure will give you a good starting point for that. See Chapter 10: Make a Plan for more information on Documentation Plans.
• Time is the amount of time it takes to complete your project, setting deadlines for activities like review and approvals, and milestones such as a publication date for each deliverable. Timing is usually graphically plotted in a Project Schedule or Timeline. Time is directly related to scope—the more scope you have, the longer it’ll take to finish, assuming you have the same amount of resources.
• Cost is the dollar cost of a technical documentation project. It’s calculated by multiplying the number of hours of writing effort by a daily or hourly rate, plus any fixed costs such as software licenses. In the practice section below, we’ll show you how to develop a cost breakdown for your project.
• Quality in a documentation project is a measure of how well your deliverables conform to norms of good writing. It’s usually achieved via a thorough review process. Part 8: Review provides guidance on how to manage reviews.

What Does That Mean?

Scope The sum of the deliverables (like user guides, manuals) or services (such as editing, proofreading) to be provided in a technical documentation project. Quality A measure of how well the work matches generally accepted—but not always stated—standards of good technical writing, including accuracy, clarity, and organization. Activity A task, action, or milestone in a process or schedule. In technical writing, as in process analysis, activities are commonly expressed as verb-noun phrases—“define scope,” “write first draft,” and so on. Also known as a task. Task See activity. Milestone A significant or noteworthy point in your project schedule, such as the approval of a document or the launch of a product. Milestones are typically represented as activities with a “zero” duration.

3. [Theory] Work Breakdown Structure (WBS)

A Work Breakdown Structure (WBS) offers a visual representation of your project’s scope. It organizes the scope into a hierarchical tree structure, making it easier to see your project as an integrated whole.²

The WBS is particularly effective for planning. It not only includes project-level activities like planning and designing but also encompasses document-level tasks, such as writing and reviewing chapters and topics. This approach gives you a holistic view, showing how every part of your project fits together.

Our Documentation Project Estimating Sheet Template provides a template to get you started. You can customize this example to suit your project. It uses the phases in the technical writing process—plan, design, write, review, and publish. Remember, using a WBS is optional. It provides an alternative, visually engaging way to outline your project’s scope, which many find helpful.

Note

Isn’t a WBS for Financial Systems? For many, the term “WBS” is synonymous with coding budget items in financial systems like SAP. You might encounter some confusion if you discuss a WBS in terms of project scope. The concepts are closely interlinked—a WBS for scope can be used to create a cost-coded WBS for budget line items—but the nuances are often lost in translation. This is something to keep in mind when talking with stakeholders.

4. [Practice] Estimate “Iron Triangle” Variables

This process guides you through estimating the “iron triangle” variables of scope, time, and cost for your documentation project. This is the foundation of your detailed planning and provides essential information for the next steps: developing a Project Schedule. This section utilizes the Documentation Project Estimating Sheet Template to break down scope, time, and cost.

Insight

What If I Get It Wrong? You probably won’t nail your estimate the first time. When you’re estimating, it helps to build in some contingency in case something goes wrong. Adding an extra 10-20% to the most likely timing for each task is common—you don’t want to be overly pessimistic, or overly optimistic. Here are some common issues in documentation project scheduling: • Underestimating. You thought something was a topic, but it balloons out into a chapter. This often happens because you’re not quite sure what the product does, or the true scope of a process, and only after hands-on experimentation does the full extent become clear. • Overestimating. What you thought would be a chapter ends up being a topic, so you finish sooner than expected. This can help balance any time lost from underestimating. However, finishing too early isn’t always ideal. It can raise questions about the reliability of your estimates. The best thing you can do to guard against the above is to do your homework. Getting a close-to-accurate draft table of contents based on interviews with subject matter experts will put you in a strong position, making for a more reliable estimate. For more information on identifying risks and strategies to manage them, see Chapter 27 Manage Progress > 3.7. Step 3: Manage Issues.

What Does That Mean?

Contingency A reserve of time set aside in case something unexpected delays the project, or if the initial assumptions prove too optimistic.

4.1. Step 1: Break Down Scope

The first step in planning your project is to break down the scope. This helps you grasp the amount of work involved. To start, you’ll need a basic understanding of the internal structure of your deliverables, like a draft table of contents. For tips on creating a table of contents, see Chapter 15: Design Structure.

In the example below, a tree structure represents a straightforward documentation project. This example is from our Documentation Project Estimating Sheet Template. It follows the same scenario as the sample Work Breakdown Structure (WBS) mentioned earlier. Notice how it includes planning tasks such as developing a Documentation Plan and designing stylesheets and templates? These steps are crucial precursors to the actual writing and can be time-consuming, so don’t overlook them.

4.2. Step 2: Estimate Complexity

Next, you’ll need to build an understanding of the complexity of each task. This will give you the information you need to estimate the time it’s going to take to complete each one. To do so, use your own experience to do the estimating, or obtain a “benchmark” from another writer in your organization who’s done similar work.

What Does That Mean?

Benchmark A point of reference against which the progress, performance, or quality of a technical documentation project can be measured. For example, the average time taken to write a topic of a certain complexity.

4.2.1. Define T-Shirt Sizes

If your team doesn’t have a standardized way to measure complexity, you’ll need to develop one yourself. There are many methods for this, but we like the “t-shirt size” approach, which is both straightforward and commonly used, especially by Agile teams. Ensure you include a wide range of estimates to provide the granularity needed for different-sized tasks.

4.2.2. Estimate Complexity

After defining your t-shirt sizes, estimate the complexity of each deliverable and topic in your project. If you’re unsure about the time it takes to write a topic, try benchmarking—ask a fellow writer how long it took them on a similar project. Keep in mind, though, that their estimate might differ from yours, influenced by their experience level and familiarity with the organization’s products and processes.

Tip

Getting a More Accurate Estimate One of the most important considerations in developing an accurate estimate is securing time with the subject matter experts to fully understand the requirements. You’ll also need to factor in time for familiarizing yourself with the product or process you’re documenting, grappling with the complexities of the writing tools you’ll be using, and time dedicated to capturing screenshots or other images. The more homework you do, the better your grasp will be of what’s required for each chapter and topic.

4.3. Step 3: Calculate Effort

Next up, it’s time to calculate the effort involved in writing each deliverable and topic. Don’t forget to include time for updating them after a review. Effort refers to the units of labor—usually yours or a writer on your team—needed to complete an activity, rather than the total duration. Our Documentation Project Estimating Sheet Template uses the t-shirt size values you’ve assigned to automatically calculate effort. Be sure to sense-check everything, including the formulas, before moving on to the next step.

What Does That Mean?

Effort The units of labor required to complete an activity, typically measured in hours, days, or weeks. For example, “It took me 6 hours (effort) spread over 2 days (duration) to write that document.” See also: Duration. Duration The total time taken to complete an activity, regardless of the effort (units of labor) involved. See also: Effort.

4.4. Step 5: Estimate Review and Approval Duration

This step involves estimating the review and approval duration for each document requiring it. Duration refers to the total time it takes for someone to respond with feedback or approval. Review and approval are crucial for quality control and governance, and they must be factored into your project’s timeline.

When estimating review and approval duration, consider these factors:

• Review Cycle Time. What’s the usual turnaround or “cycle time” for reviews? Sometimes, reviewers and approvers have a standard cycle time, especially more senior individuals inundated with review requests. Other times, you’ll need to ask them how long they think it’ll take—and then keep a close eye on whether reality matches their estimate.
• Number of Cycles. How many “cycles” or rounds of review and updating are needed to reach the final draft stage? Often, particularly with complex topics, several cycles of review may be necessary. Be mindful that multiple rounds can significantly extend a timeline, so realism is key.

4.5. Step 4: Assign Resources

Next, you’ll need to assign resources to each activity. In project management jargon, “resources” refer to the people responsible for doing the work—that is, human resources! Each resource has a different hourly cost, which needs to be factored in. This will help you complete your Project Budget. It also helps you keep track of who’s doing what at a granular, task level in your Project Schedule. If you’ve completed the steps in the previous chapters, you can use the relevant sections in your Documentation Plan Template as a starting point to populate this section.

4.6. Step 5: Estimate Cost Breakdown

Finally, estimate the cost breakdown of your project by multiplying the cost of the effort by the daily rate of the resource for each activity. Our Documentation Project Estimating Sheet Template automates this process. The sum of these costs gives you the total forecast cost for your project. Don’t include costs for duration-based activities like review and approval—they’re generally considered part of the project’s overhead and aren’t costed separately.

Once you’ve completed this step, you’re ready for the next one: developing a Project Schedule. This is covered in the following chapter, Chapter 14: Develop Schedule.

5. [Template] Documentation Project Estimating Sheet Template

Documentation Project Estimating Sheet Template

1. Pollack, J., Helm, J., & Adler, D. (2018). What is the Iron Triangle, and how has it changed?. International journal of managing projects in business, 11(2), 527-547. ↩︎
2. Project Management Institute. (2023). A guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.). Project Management Institute, p. 81. ↩︎