Project Management: The Next Logical Step

I don't know about you, but I've heard the job title known as "project manager" thrown around quite a bit. I also met a few project managers who were technical writers at one point.

What's interesting is that I've seen career maps for technical writers and one path is project management.

If you don't know what project management is, that's okay. I was in the same boat not too long ago as well. I'll try to explain what this job is the best I can.

My question is why do some technical writers become project managers? Is this a logical progression for those of us who've been in the documentation trenches for a while? I'm not sure. But I think I have a guess as to why this seems to happen.

Now before I give my hunch on why technical writers become project managers, let me explain what project management is.

According to Wikipedia, "project management is the discipline of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria."

In others words, you're doing everything possible to make sure a project gets properly executed. You might manage different people, such as technical writers, to make they do their part with the project.

You might coordinate with various teams to make sure they work together to move the project along.

If there are trouble spots or impediments with the project, you might need to make some adjustments anywhere from shifting people around to coming up with a new plan on how to execute a project. As a project manager, you're there to see the project through.

Now what does project management have to do with technical writing?

Believe it or not, project management is built into technical writing. As a technical writer, a document is like a project. We are responsible for doing everything possible to make sure a document gets published and goes out the door with the product or service.

We come up with plans on how to complete a document. We also create an outline of what the document would look like.

Project managers have to create plans on how to complete a project. They need to have a bird's eye of the project.

Do you see a parallel here?

We have to work with different SMEs to get different pieces of content for a document, especially if it involves multiple chapters or a team of developers or engineers. You have to coordinate to make sure who does what and when. When you work with SMEs, mostly likely you'll be working with their manager to coordinate the deadlines.

Again, with a project manager, they need to coordinate with different people, teams, and managers to do their part of the project.

Collaboration and coordination are inherit in both technical writing and project management.

And finally, we technical writers have to juggle multiple documents to make sure they go out at the right time and are done well. Project managers have to juggle multiple projects to make sure they're executed correctly and on time.

I could go and go on about the similarities between the two, but I think you get the picture.

So what's my guess? It's understandable why technical writers become project managers. They want better recognition and pay for what they have been doing all this time.

Documentation and Gardening

Whenever I get a chance, I enjoy giving my green thumb a workout and caring for plants that bear fruit. Unfortunately, I'm not doing any gardening right now because of a drought and other factors. However, I'm still nursing an orchid plant. Where am I going with this?

I haven't suddenly shifted gears and turned this blog into a gardening one.  But I think gardening and documentation have something in common: they both take tenacity and patience.

Let me draw some parallels between the two.

Plan ahead. Before you plant a garden, you need to do some research. For example, what kind of soil are you going to use. Does the plant need more sunlight or more shade? How often do you need to water the plant?

With technical documentation, you need to do something similar. For example, you need to find out who the audience is that you're writing for. What kind of document are you writing? What kind of questions do you need to ask the SMEs? How will you structure the document?

Answering these questions will go a long way to help you to successfully complete a technical document and create a good garden. 

Be persistent and flexible. To make sure your garden thrives, you need to be active in caring for your plants. Constant care will help your garden grow. You also need to be willing to make some shifts when your garden isn't flourishing.

For example, you might need to change the location of your plants so they get more sunlight. If you have trees that have been bearing fruits for a while but the harvest declines each year, you need to prune them. There's also a possibility you need to completely uproot dead trees and plants because they're diseased or dying.

It's the same thing with documentation. Documentation isn't going to write itself. If you need to submit a technical document, you need to write it first. You may need to make adjustments to your document as it grows or evolves. For example, what you started off with may need to change because it's not reflecting the product, service, or the subject anymore. Or let's say you're documenting software and there are some new features for the upcoming release. You need to write the documentation to reflect these changes. There may even be documentation you need to trash but it's simply not applicable anymore

As a technical writer, expect you may need to do a writing and rewriting with documents you slaved away for hours, days, months, or even years. And the same thing with gardening, you may need to start over after a long time of caring for that one orchid. But if you are persistent and flexible, you should be able to overcome any obstacle that comes your way.

Factor in the unexpected. A disease might kill your plants. This actually happened to my zucchini plants one year. Or you might have seeds that are D.O.A. It's the same with documents. The "powers that be" might pull the plug on a project and the documents will die with it. Or the project goes in a completely different direction and the documentation needs to do the same. What if a company folds or someone you're working with suddenly quits? These are things that can happen and you need to account for these possibilities mentally when writing documentation. 

Be patient. Your garden isn't going to grow and yield fruit overnight. You shouldn't expect documentation to be completed overnight either. Sometimes, you'll be waiting for SMEs to get around to your questions when you want to finish up a section of the document. You might be waiting anywhere from hours to months to finish this up. Even if you try to follow up with the SME, he or she might not simply have the time. You need to move on with another document until they're ready.

If you are willing to deal with the dynamics of this universe, then you should be able to write technical documentation and plant a garden.

{