How soon is now?

How early do you get involved in a project? At the start? Part way through once the scope has been set? Or once the design has been agreed? Or do you swoop in at the end and document whatever you find?

One common complaint a lot of technical writers have is that they aren’t included early enough in lifecycle of a project. The downsides are that by the time work hits your desk you don’t have a full picture of who the customer is, why they want whatever it is you are building, and how they want it provided to them. All of which directly impacts the information being created.

So how do you, the lowly technical writer, make sure you are involved early in the project? By offering your services as a master information curator, task analysis guru and all round user advocate, that’s how!

During the early stages of most projects, there will be a period when the main requirements are gathered, ensuring the pain points are covered, and that the main scope of what you are building is agreed. A lot of those discussions are largely focussed on collating information from the heads of various subject matter experts (SMEs) and stakeholders, and gaining agreement on it in a singular form.

Sound familiar? I hope so, as it’s not all that far removed from discussing a new product feature with some of the guys who helped build it, and coming to a consensus on how it should be used and, therefore, how it should be documented.

As one of the core competencies of a technical writer, it’s something many of us have forgotten we do, largely because, hey, it’s just our job. However it takes a unique skill set, one that not everyone possesses, to be able to focus a number of different viewpoints into a cohesive story.

This type of work is often performed by a business analyst, but there is no reason why you can’t fulfill a similar role to some degree. The project team get the benefits of your skills, removing some of their early pain, and you get to be involved from the get-go. Win-win, right?

Well, almost. One caveat is that being involved in the early stages of a project is likely to overlap with the end of the previous one, so whilst you are wrapping up all those little issues (you know, unmentioned features and changes) you may struggle for time if you are also helping in the early stages of the next phase.


It’s a hard balance to find, but if you really want to get in early, and I think the benefits outweigh the downsides and if needs must you may need to get support from your boss to reschedule some work to free up your time to be involved. It’s a simple enough, progressive, argument:

Understanding the customer and the requirements leads to better information. Better information leads to better use of the product. Better use of the product, lowers support calls, leads to new product features and increased sales.

Which, I think, is a pretty powerful statement to make to your boss when you are asking to clear time in your schedule so you can start this cycle.


  1. I think it’s helpful to be involved early on so I can have some input re GUI and usability issues, rather than raising such things as bugs later on.

    However I don’t like to devote much time to a project until there is software to use, otherwise it takes much longer to write help that is less good.

    I suspect most authors and writers (and hopefully developers) would agree. The difficulty is deciding what that means in any particular project, e.g. half a day a week for X weeks then full time for Y weeks.

Comments are closed.