Lead Writer: Kieran Morgan | Peer Reviewer/s: Amanda Butler | Managing Editor: Kieran Morgan

This chapter offers a detailed, step-by-step approach to scheduling technical documentation projects. You’ll be guided from selecting a scheduling tool to creating a cohesive project schedule. Highlights include understanding dependencies, and distinguishing between parallel and sequential activities such as review and writing. By demystifying complex scheduling concepts through a worked example, this chapter equips you with essential tools for effective project visualization and stakeholder communication.

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 7: Estimate Scope, Time, and Cost	Next: Chapter 9: Manage Progress

1. Introduction

Think of your Project Schedule as your map—a tool that guides and shapes the journey of your documentation project. Much like a map charts a path for a journey, a schedule offers a detailed outline of where you’re headed, understanding that detours may happen along the way. Since a schedule can evolve in response to real-world challenges, it allows you to navigate through these unexpected developments, like an adventurer plotting a new route through complex terrain.

Have you ever felt constrained by someone else’s deadlines, feeling like your hands are tied? This is where your Project Schedule steps in, shifting you from a passive follower to an active planner. Forecasting the time needed helps you prepare effectively and empowers you to ask for additional resources when required. Developing a Project Schedule is more than just meeting timelines—it will help build your skill set and reputation as a senior writer confident in planning and managing their own work.

In this chapter, we introduce fundamental concepts of scheduling, such as dependencies, and the difference between parallel and sequential tasks. These theories are essential for understanding the intricacies of scheduling. In the practice section, we provide a step-by-step process so you can develop a Project Schedule. We use a worked example, detailed here: Sample Documentation Project Schedule.

We’ll also show you how to convert your schedule into a more visual format, like this Documentation Project Timeline Template, which is great for presenting to stakeholders or clients, especially if you’re a consultant. Unlike a detailed Project Schedule, a Timeline doesn’t reveal too many detailed milestones, which can help in managing expectations.

Once you’ve created your Project Schedule, you’re all set to kick off your project and manage its progress. Chapter 27: Manage Progress provides both the concepts and practical steps needed to keep your project on track right from the start.

Note

Do I Build My Own Schedule or Use the Team’s? Writers who are embedded in project or engineering teams may be asked to add their tasks and dependencies to an overall Project Schedule. This is common. It doesn’t mean you shouldn’t build your own schedule—if you’re confident doing so, it’ll help make any assumptions you’re adding to the overall schedule more realistic.

2. [Theory] Dependencies

In technical documentation, understanding dependencies is key to effective scheduling. Dependencies determine the sequence of task completion. You’ve probably noticed them in Gantt charts—they’re represented by a column labeled “Dependencies” or “Predecessors,” identifying the numerical ID of the task they’re dependent on. This is represented visually by lines and arrows linking tasks and milestones.

The most common dependency you’ll encounter, and the one used in our worked example, is the finish-to-start dependency:

• Finish-to-Start (FS) Dependency: This is where a task starts only after the previous one has finished. For instance, you can’t publish a document until it’s been approved.

Finish-to-start is the default dependency type in most scheduling software and is also the easiest to understand. While there are other types of dependencies, we won’t explore them here because they’re not common. However, they’re included in the accompanying diagram for a quick overview.

What Does That Mean?

Dependency A relationship between tasks where one task depends on another task’s start or finish. Examples include finish-to-start, start-to-start, and so on. Also known as a predecessor.

3. [Theory] Parallel and Sequential Activities

Understanding the difference between parallel and sequential tasks is key to efficient scheduling. This concept forms the backbone of your schedule logic, enabling you to create accurate linkages between tasks in your schedule.¹

• Sequential Tasks: Sequential tasks (or tasks “in series”), such as the writing and reviewing of a topic, require the completion of one task (writing) before the next (review) can begin. In this scenario, as shown in our example below, “Review Topic 1” is dependent on “Write Topic 1.” They must occur in sequence.
• Parallel Tasks: Conversely, parallel tasks can overlap with other activities, occurring simultaneously. In our example below, the review (by a subject matter expert) of Topic 1 can overlap with the writing (by a writer) of Topic 2. In summary, there’s no dependency between these two activities.

When putting together your schedule, it’s essential to grasp this distinction, or else your schedule may lack accuracy. To assist you, we’ve provided a pre-configured Sample Documentation Project Schedule which already outlines the parallel and sequential tasks.

Below is an example of what the above sequence might look like in a Gantt chart format.

Note

Modelling Parallel Tasks Parallel tasks can be tricky to model, as most scheduling software defaults to a sequential scheduling mode.2 This default setting can complicate the scheduling of writing projects, which often involve a mix of sequential and parallel tasks. Our Sample Documentation Project Schedule uses a consistent, structured sequence of dependencies to manage this complexity.

4. [Practice] Develop Schedule

This process guides you through scheduling your documentation project. It’s based on the Estimating Sheet developed in Chapter 13: Estimate Scope, Time, and Cost, which serves as the primary source of data.

Note

Be Careful About Raising Expectations When sharing your detailed Project Schedule, be cautious. It’s okay to share it with your immediate project team—that is, the folks who are working with you to progress tasks at a detailed level, such as your fellow writers and subject matter experts. Make sure everyone understands it’s a working document—something to be continually updated. If you publish it to the wider organization, it might create an expectation that you’ll hit every milestone exactly as planned. In reality, things often change once your schedule is put into action, so you’ll need the flexibility to adjust the timing of tasks as the project progresses. For this reason, we’ve also included a simplified Documentation Project Timeline Template that doesn’t display the timing of every task and milestone.

4.1. Step 1: Select Scheduling Tool

First, you’ll need to select a scheduling tool. We’ve used Microsoft Project for our worked example in this chapter, but if you’re not comfortable with it, there are plenty of alternatives out there. Look for a tool that lets you create Gantt charts, map dependencies between tasks, allocate tasks to different resources, and—preferably—automatically levels resources to avoid overloading them.

Note

A Note on Our Worked Example Microsoft Project is an advanced tool, available in both desktop and online versions. The online version is both more affordable and less feature-rich. If you’re not comfortable with it, consider using an alternative, like a project management platform or a Gantt chart template in Microsoft Excel. Platforms such as Monday.com or Smartsheet offer similar functionality, without all the extra bells and whistles you might not need.

4.2. Step 2: Set Non-Working Time

Before you dive into scheduling, it’s essential to set aside non-working time for your region, like weekends and holidays. If you skip accounting for public holidays and extended office closures during traditional holiday periods (think Christmas and New Year), your schedule could end up being too optimistic. To avoid this, make use of your scheduling software’s built-in functionality, as shown in the worked example below.

Tip

Adding Contingency for Unexpected Events It’s good practice to add a little contingency for the unexpected. Unanticipated delays can be caused by anything: a lead writer becoming ill, or transportation strikes affecting multiple workers. In our discussion about estimating the “Iron Triangle” variables (Chapter 13: Estimate Scope, Time, and Cost > 4. [Practice] Estimate “Iron-Triangle” Variables), we emphasized adding 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.

4.3. Step 3: Copy Estimating Data

Next, copy the data from your Estimating Sheet into your scheduling tool of choice. Transfer as many of the data fields as possible, and correct any formatting errors. For example, adjust the nesting of your tasks to ensure it mirrors the indenting in your Estimating Sheet.

4.4. Step 4: Derive Dependencies

Now, identify the dependencies for your project. Linking tasks can become quite complex, especially in schedules with multiple layers. To avoid confusion, it’s best to keep the schedule straightforward. An overly complex schedule could lead to losing track of an intricate web of dependencies. Remember, if it’s hard for you to grasp, others will likely struggle too!

Note

Writing and Review—Sequential and Parallel Activities In the worked example, we’ve linked the writing tasks as dependencies, not the review tasks. Why did we do this? Generally, reviews can happen in parallel with other tasks since they’re duration-based. For example, you can start writing Topic 2 without waiting for the review of Topic 1 to finish. However, writing tasks, being effort-based, must be done sequentially.

4.5. Step 5: Incorporate Review and Update Cycles

Next, you’ll need to include review and update cycles. In the Estimating Sheet example in Chapter 13: Estimate Scope, Time, and Cost, we’ve included two review cycles for reviewing and updating Topic 2. Now, let’s add them to our example schedule and link them up. This will help you plan for the additional time and effort expected for reviewing and updating Topic 2.

4.6. Step 6: Review Schedule

Next, you’ll need to review your schedule for any potential issues. But first, make a backup! Changes you make now, such as resource leveling, can significantly alter your schedule.

Here are a few checks to consider:

• Logic and Sequencing. Ensure the dependency mapping and sequencing of tasks you’ve created are logical. Do they reflect reality? If it’s too complex and you struggle to understand it upon review, consider simplifying it. Otherwise, you might face challenges managing progress later.
• Timing. Are the timings for activities reasonable? Avoid being too pessimistic or optimistic. Aim for the most likely scenario, adding a bit of contingency (about 10-20%) to each task to cover unexpected issues.
• Over-Allocations. Look for resource over-allocations, a common scheduling problem. To resolve these, use your scheduling software’s leveling functionality to automatically distribute the workload, or adjust resource quantities, like increasing the number of writers or reviewers.

4.7. Step 7: Manage Progress

Finally, it’s time to manage the progress of your documentation project. In this phase, which underpins the end-to-end lifecycle of your project, you’ll be regularly reviewing your Project Schedule and adjusting it as the assumptions and estimates you’ve built in meet the ever-changing reality that’s a feature of project life.

It’s also perfectly okay to not use your Project Schedule on an ongoing basis—it can simply form the basis (and source data) for a simpler progress tracker, such as a Status Tracker or Kanban Board. We discuss these options in detail at Chapter 27: Manage Progress.

Tip

Use Schedules for Scenario Planning We’ve written this chapter with the end goal of developing a schedule as a foundation to manage progress. But that doesn’t have to be the only use. Schedules are versatile tools that you can use to model scenarios. Let’s say you’re interested in taking on a new project, or adding a significant chunk of scope that’s a “stretch goal” but not mandatory. In this case, you might use a schedule to model the feasibility of these scenarios, giving you insights into how they could play out in reality. Learning to use schedules to model scenarios will give you an decision-making, before you have to commit to anything binding.

5. [Practice] Create Timeline

Timelines are an excellent way to provide a bird’s-eye view of your project. They’re simple visual tools that can be created using widely available programs like Microsoft PowerPoint, or any tool with shape-drawing capabilities.

A timeline offers your stakeholders an easily understandable overview of your project, without overwhelming them with details. It’s an effective way to highlight key dates, while keeping more detailed planning within the team, as illustrated in the example shown.

You can use our Documentation Project Timeline Template as a foundation for your own timeline.

6. [Example] Sample Documentation Project Schedule

Sample Documentation Project Schedule

7. [Template] Documentation Project Timeline Template

Documentation Project Timeline Template

1. Burke, R. (2013). Project management: Planning and Control Techniques. John Wiley & Sons, p. 201. ↩︎
2. Levine, H. A. (1994). Resource leveling and roulette: games of chance. PM Network, 8(4), 25–27. ↩︎