Technical writing in project management

Everyone does technical and professional writing, no matter your role in an organization. For example, project managers need to write project plans, status updates, and other forms of documentation. We asked a project manager about how good written communication plays a part in their role:

Let's start with an introduction: Who are you, and what do you do?

My name is Tim Eiler. Though my career started with work at NASA (training astronauts and flight/mission controllers, to be specific) I have been managing projects and teams of project managers for the past 26 years.

I'm a mechanical and industrial engineer by education, and I also have an MBA. I think this gives me a really unique perspective on solving problems in a business setting. I've often said that I built my career on standing at the intersection of technology and business and that I can speak both languages as needed. My industrial engineering background, with its focus on process improvement and quality, really provides the linch pin for that!

The largest project I've managed had a $150 million budget, with about 200 people working on it, and was projected to take 36 months. The people were spread across five different sites, mostly in the US, but also in Europe. The smallest had about three people working on it, a budget of about $35 thousand, and lasted about two months.

The project management office (PMO) teams I've managed in healthcare, finance, and other verticals, have ranged in size from five to fifteen project managers. In addition to the daily management of project work, this has included working directly with organization leaders to select and maintain the constituent project components of a portfolio of active projects. Of course, it required writing a lot of process documentation, too.

I grew up in a very small town (pop. 400) in rural Minnesota. I think this directly influences my work on a daily basis. I work hard and expect others to do the same. I am fairly direct, but in true Scandinavian descendant fashion, I work to soften that directness so as to avoid driving a wedge between others and me by causing hurt feelings.

Everyone does technical and professional writing. What are some typical things you write all the time in your role as project manager?

There is, certainly, the process documentation I mentioned earlier. Documentation like that includes instructions about what department policies are regarding how specific aspects of each project are to be handled - both "happy path" and deviations therefrom. It also includes written standard project processes and procedures.

As a project manager (PM) working directly on managing individual projects, though, I typically find I write project proposals, project scope statements, project requirements documents, project plans - both prose and Gantt-type or other "schedules" - risk management plans, project budgets, organizational change management (OCM) plans, and technical change requests, to name a few. As PM on larger projects, I only contribute to some of those documents, rather than writing them outright myself. The OCM plan and project requirements documents are specific examples of those, as they are often written by an OCM professional and business analyst (BA), respectively.

Then, of course, there are the ubiquitous status reports that need to be distributed regularly. These are perhaps the most difficult of the documents to tackle. They undoubtedly have multiple types of audiences, from C-level executives to individual contributors on the project team itself. Satisfying all of those types of people in just a short document is very tricky.

What's a type of document you write all the time?

I write status reports of various types all the time. Many people think the purpose is to convey data about what the team has accomplished and is planning to accomplish. That's only the "data" part, though. It's the PM's job to help leaders do their jobs. The purpose of a status report is simple: To let decision-makers (the project sponsor, for example) determine whether they need to intervene in some way to help keep the project moving at the needed velocity.

That difference may not seem like much until you're a PM writing a status report.

How important is it for a project manager to write well? What does it mean to "write well"?

It's incredibly important that a PM write well. That's less about whether that PM can write perfectly according to Strunk & White, though. "Well" in the PM's world is about being able to convey the right, needed, key information simply. Not that a PM can get away with terrible grammar and punctuation, mind you! Generally speaking, though, so long as the work is intelligible and usable, a PM can get away with it. Now, that said, the better PMs - the ones who most frequently get the promotions, for instance - write both incredibly useful and timely content and write that content in clear language that typically follows good writing standards of punctuation and grammar.

In terms of "writing a project plan," every company's format and content for a project plan will differ. So "good" is not so much about how a PM "fills out the template" as it is about how well written the content is.

Project schedules, all by themselves, don't really have a lot of writing involved. However, I find that it's incredibly important for a PM to write the titles of the tasks involved in the schedule extremely clearly. Sloppy formation of the task title is a sure way to get what you didn't want. Writing task titles typically in verb-noun or noun-verb structure most often is what I use. Many PMs write simply in the "noun alone" form. That doesn't tell the person who'll perform the task what's to be done to that noun.

In terms of other parts of an overall project, such as the risk management plan, communication, and such, the same holds true. How one writes the structure of risks, action steps, and such, defines how those things are measured and managed. If the PM doesn't write those things well, the structures of how they're implemented will be less than ideal and the outcomes will be negatively affected.

Most importantly, many parts of a project plan are not meant for the PM, but for other members of the project team. Write using PM jargon, or just badly in general, and the PM will confuse the other document users - or worse.

What other writing and communication skills does a good project manager need to have?

The first point I want to make here is that there is a difference between data and information. Sure, a PM has to ensure that the necessary data about the project is available, but a truly good PM will be excellent at summarizing the key parts of that data into information that a receiver of that information can use to make choices, decisions, etc. So, that data and information are the key tools in a PM's toolkit.

Communication from a PM's perspective needs to be incredibly concise. A lot of communication today favors tools like Slack and Discord over email, and while "PowerPoint" presentations are still a thing, they seem to be headed toward the eventual dustbin. No matter what medium is used, I use a "tool" called SBAR - Situation, Background, Analysis, Recommendation. It puts the need or expectation up front and then provides the supporting information in the back.

Most of the project documentation I do is created using a tool like Microsoft Word. Tracking is done in Word, Excel, or a more-specialized application.

A lot of planning, including initiation schedule planning is done in tools like Miro or Mural. A lot of PM communication isn't terribly "formal." It is pragmatic, though!

What should someone know if they want to become a project manager?

I've often said that project management is really just codified common sense. The tools used are pretty simple because of that. A word processor (like Microsoft Word), a spreadsheet (such as Microsoft Excel), a flowcharting application (like Microsoft Visio): All of those are basic and, though a new PM wouldn't be expected to be a wizard-level user, solid skills are expected.

Scheduling is a ubiquitous part of a PM's role, so it's critical to have a reasonable level of basic skills with one or more scheduling tools. Such tools might include packages like Microsoft Project, Monday, SmartSheet, and any one of a dozen others. (In the 1990s, I probably would have said hundreds!)

Communication is 90% of a good PM's job. Projects are a team sport, after all! The other tools above serve to provide the key info to communicate to the overall project team and those impacted by the project. Were a PM to simply create those documents, budgets, schedules, etc., and then not share information about what they "say," it would be a wasted effort to have created them.

Thanks to Tim for this insightful interview about the intersection of project management and professional communication!