Project Managers Aren’t the Only People Who Define Scope

The Importance of Scope on a Documentation Project

According to the Project Management Body of Knowledge (PMBOK), the scope of a project is the work to be done on that project. The scope of a project is generally defined using a work breakdown structure (WBS) allowing the user to set goals, objectives, priorities, and deadlines making a project manageable. Knowing the exact scope provides the ability to create detailed cost estimation.

Defining the scope of a project so that all aspects of the project are determined and tracked to completion is not only important to make sure the project is on time and on budget, but also that all changes are properly managed. Change management can make or break a project as it can affect costs, schedule, and the deliverable itself. This may sound like a lot of work, but on large projects with extensive resources, tracking a project makes all the difference in how successful the result is.

What does this have to do with technical writing? All documentation projects need project scope clearly defined. A clear and detailed definition of the deliverable, especially larger projects such as extensive manuals, websites, and long-term documentation changes can help eliminate project overages and decrease project failure risk. What does that mean?

Scope creep and Project Completion Risk – Even Small Projects Can Suffer

If a documentation project, especially a larger one, isn’t clearly defined and tracked, it can lead to scope creep. According to the PMBOK, scope creep means adding features/functionality (to the project scope) without addressing the effects on time, costs, and resources. Scope creep can lead to project failure. If expectations for the project owner and all stakeholders are clearly agreed upon, stakeholders will know what they are getting upon project completion, which means it is easier to keep a project on time and within budget.

“Scope creep: Adding additional features or functions of a new product, requirements, or work that is not authorized (i.e., beyond the agreed-upon scope)” (Larson, & Larson, 2009, para. 4).

What should a technical writer watch out for? Lack of planning. Problematic project definitions such as incomplete requirements, lack of communication between stakeholders, lack of resources, failure to reach project milestones, schedule issues, lack of change management, quality control issues, indecision regarding the deliverables, and unrealistic expectations increase project completion risk.  

Defining project scope is important on any scale documentation project because it provides a clearly defined baseline plan of project objectives, schedule targets, and budget estimates negotiated at the start of a project. Preventing scope creep on documentation projects, or preventing your projects from going over budget and overtime without controls, helps you achieve your goals of completing the project as agreed. Once a documentation project scope is determined, get sign-off on the written scope statement from the primary stakeholders. Follow up by staying on top of changes, schedule, budget, and resources.

Additional Reading

Project Management Institute: Top five causes of scope creep … and what to do about them –


Larson, R. & Larson, E. (2009). Top five causes of scope creep … and what to do about them. Paper presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute.

Important Skills Technical Writers Need for Success (Part 2)

I’ve compiled a list of skills that are important to be an effective technical writer and technical communicator. In the first post of this multi-part series, skills discussed were grammar, usage, editing, and the ability to turn data into information that a reader can use to create knowledge. In part 2 we look at additional skills technical writers need for success.

Know Your Target Audience

An underrated skill in technical writing is being able to determine your audience and understanding how to write for them. This starts with a basic overview of the primary audience. Are they the general public or a specialized smaller group such as scientists? Is the target audience all ages over 18 such as a medical provider or is there a specific targeted age group? As a writer define the primary reader for the document and then determine the secondary audience. Who else might read the material either in the future (will the document be archived) and what do they want from it?

Determining targeted information is a great way to write for your reader. Knowing the audience will allow a writer to target the proper age group and education level and increase the readability of a document. A reading index is a great tool on grade and reading level for readability.

Knowing the target audience is key to writing a great document.

Understanding Complex Concepts and Processes

This seems like a basic principle. A technical writer needs to be able to grasp technical concepts, clearly and concisely. In the classes I teach on technical communication, students know I always comment on how clear and concise their work is. Clear and concise writing is extremely important.

How can a technical writer write about a concept if they don’t understand it clearly and concisely?  If a concept isn’t clear to the writer, it will come out in the writing. If the writing isn’t concise, you will lose the reader. Remember, more isn’t better in the case of tech writing. It is just more. Too much explanation usually means the tech writer does not understand what they are writing about.

Quality and Accuracy

Writers need to be concerned about quality. To be more precise, accuracy is important. There are times where the work must get out and so some quality is sacrificed. Accuracy should never be sacrificed, otherwise, there can be issues or failures related to the document. This in turn can be catastrophic in a safety or critical process. Injury, harm, or damage can occur to people and property. Can you imagine a mistake on a technical manual for a nuclear power plant or Standard Operating Procedure (SOP) for an industrial chemical process?

Accuracy is important to technical writing.

Style Guide Knowledge

Style guides are important, especially if a technical writer creates documents for conferences, symposiums, or academic white papers. The use of a particular style guide varies depending on a client/employer, conference, symposium, academic paper, or knowledgebase article. Technical writers should know the difference between APA, CMOS, MLA, and other guides. I’ve even seen the AP style guide used depending on the technical writing assignment.

Did you know there is a style guide for Physics? It’s called the AIP style guide. AIP Style refers to the citation format established by the American Institute of Physics. There are other style guides by the American Mathematical Society, Geological Society of America, American Medical Association, American Chemical Society, and more. Remember, style guides are your friend. They give clear guidelines on how to write for publications and companies. Do some research and see.

Interviewing Skills, SMEs, and Researching

A very handy set of skills any technical writer can possess includes interviewing, interaction with subject matter experts (SMEs), and research. I have met too many people who think writers of any kind sit pensively thinking out the perfect document and work alone, producing masterpieces all by themselves. Too many beginner tech writers feel they can do it alone in the first draft for manuals and then are shocked to find their materials are flawed, grammatically incorrect, or missing information. I have yet to find the perfect assignment handed in after more than a decade of teaching tech writing. Writing just a single draft is not going to lead with quality or accuracy.

The idea of a lone writer is silly. In many of the jobs I’ve held, I was the only writer but I always worked in teams with experts, inventors, engineers, management, certification consultants, and dozens of other stakeholders. So interviewing skills, especially with experts is important. Learn how to interview people. Practice is the best way to learn.

Here’s where research comes in. Not only is research necessary for documentation, but a technical writer should do their homework and research the topic they are interviewing the SME for before the interview. That way they don’t ask basic questions they could find the answer online and waste the short amount of time allotted with the SME. An SME may get frustrates and end the discussion early, refusing to discuss more. That situation makes technical writing more difficult.

Research is an important skill in your technical writing toolbox.


Ethical obligations are a part of technical writing. A big part. Ethics is in everything from representing technical information efficiently, clearly, and concisely so that the reader doesn’t feel like they have been tricked to avoid major safety concerns and potential loss of life. I consider ethics a skill because not only do you use common sense, a technical writer needs to learn legal implications as well as corporate culture in the organization that they work for to apply a broad scope of ethics.

Think about all the considerations there are for certifications in hazardous environments and what a business or technical writer needs to learn to work in certain industries. Diligence in making sure information is accurate affects all industries from pharmaceutical, oil and gas, nuclear, chemical, utilities, baby furniture, car seats, automotive, etc. Can you imagine incorrect procedural documents in the utilities or nuclear industries? There are also obligations to keep employers’ trade secrets, to the environment, the public, property, copyright, and liability laws. This list can go on and on. Remember, there can be legal repercussions to the technical writer if ethics are ignored.

Ethics is important to consumers as well as organizations and industries.

This wraps up the two-part series on important skills technical writers need for success. There are other skills like software but the type of software used varies from organization to organization. So every writer must decide what they need to learn.

Check out part 1 of Important Skills Technical Writers Need for Success.

Lu Kondor has worked as a technical writer for more than 20 years for major corporations. She has a Doctorate in Business Management and has worked in a large variety of organizations including entertainment, software, electric utility, manufacturing, oil and gas, chemical, and nuclear process industries. She is an adjunct lecturer in Advanced Technical Writing as well as Information Design for more than 14 years.

Important Skills Technical Writers Need for Success (Part 1)

In this multi-part series, I’ve compiled a top list of skills that are important to be an effective technical writer and technical communicator. This isn’t an exhaustive list but a basic outline of what most employers look for. Don’t underestimate simple concepts. Keeping things simple makes your job easier.

Don’t underestimate simple concepts.

Many people think they are really good writers but are they? Some writers are masters of prose, others are skilled in non-fiction and essay writing. That’s fine to think of oneself as a really good writer, but not all writing is the same. Anyone who writes for a living across multiple types of writing will tell you that. What you have to ask yourself is; can you write well as a technical writer?

Technical writing is different than prose or fiction. It is also different than business, textbook, or essay writing. Why? The goals of technical writing are different. Even though all types of writing have some things in common, the goal of what is being written is important. The goal of technical writing is to take data, whether raw or correlated, and decide what is important (and order of importance) and what isn’t important. Then turn it into coherent and cohesive information in a clear and concise written manner so that the reader can gain the knowledge they need. 

The goal of technical writing is to take data, whether raw or correlated, and decide what is important (and order of importance) and what isn’t important.

Excellent Writing Skills Are Important

I am often asked by students what kind of skills they need to be a technical writer. The first thing I say is “A technical writer requires excellent writing basics.” This covers two aspects or sub-skills.

  • Grammar and usage (including ability to edit)
  • Ability to turn data into information that a reader can use to create knowledge so that the final outcome is to perform a task, learn, or make a decision

The first is grammar and sentence structure. This is basic and almost anyone could guess why good grammar is important. Knowing grammar and sentence structure is the first step to writing a great document.  It also allows a technical writer to be able to edit material that comes to them as well as edit what they write themselves.

Do you know what an Oxford comma is and when to use it? What’s a run-on sentence? What is a gerund? These should be simple questions to answer. Remember, employers may ask about your skill sets, or even better, they will test you on it.

Catching Mistakes

Catching mistakes on documents is especially important in situations where catastrophic failure can result in injury, loss of property or life. For every poorly written technical document, there are repercussions even if there isn’t a catastrophic issue, an organization can still suffer a loss of revenue because of deficient documentation. If you have ever bought a product because you read it could do something, and then the product failed to follow the listed specifications, you understand.

The second is the ability to turn data into information that a reader can use to create knowledge. The outcome for the reader is to have enough knowledge to perform a task, learn, or make a decision. The ability to convert data into information for a targeted audience so they can skim for basic information, scan for a particular piece of information, or read word-for-word to learn as much as possible takes practice. All of these methods provide knowledge to the reader. The reader applies that knowledge so that they can decide how to take action. That action may be as simple as performing a task, learning something new, or making a decision.

Performing a task can be simple. How to load software on your computer, assemble a piece of furniture from the local box store, or execute a standard operating procedure (SOP). It can also be complex, such as a SOP that provides a safe method for taking a boiler offline for maintenance, learning what instrument readings to monitor to prevent an explosion, or setting up a temperature transmitter in a hazardous environment.

Learning can take many forms and can be tied to task performance or decision-making. Learning can stand-alone as well. A person can learn for the sake of learning or to build future skills. For example, reading on updated industry certification standards for equipment or learning a new computer network technology. Learning can easily be tied to a variety of technical writing formats. Learning can also come from video, interactive applications, podcasts, or other media. Have you ever watched a video on a newly released phone, tablet, or device just to learn what all the buzz is about? Then you have watched technical writing in action.   

Decision-making for a reader is probably one of the more complex aspects of document usage in technical writing.

Many users will need to make a decision on spending money, procuring a service, or taking (or not taking) an action. For example, many process industry engineers read specification sheets to determine if they will recommend the purchase of a particular brand and model of safety device. CTOs may read up on particular enterprise-wide software or hardware investments. Organizational leadership receiving an environmental report passing EPA requirements for environmental hazards may decide no further action is necessary until the next required testing. Still others such as human resources could read a SOP and determine it is missing a newly updated safety standard required by regulators and will take action to have the document adjusted.

Many users will need to make a decision on spending money, procuring a service, or taking (or not taking) an action.

There are a number of reasons why users need to make a decision, perform a task, or learn something new. This concept ties in with knowing the target audience of the document and their needs. That is why the best way to begin is to start with the basics. A technical writer that has a strong knowledge of grammar, sentence structure, and the ability to take a broad range of data and organize it in a coherent and readable fashion is at an advantage. But remember, a document needs to be designed not just for the readability of the document’s target audience, but it must adhere to any rules, regulations, and ethics required to make the document clear, concise, and accurate for the user. Lives may depend on it.

Read Part 2 of Important Skills Technical Writers Need for Success includes a style guide discussion, knowing your target audience, quality control, interviewing subject matter experts, and more.

Lu Kondor has worked as a technical writer for more than 20 years for major corporations. She has a Doctorate in Business Management and has worked in a large variety of organizations including entertainment, software, electric utility, manufacturing, oil and gas, chemical, and nuclear process industries. She is an adjunct lecturer in Advanced Technical Writing as well as Information Design for more than 14 years.

Try a Reading Index to Check Your Readability

What is a reading index? I’ve been asked that many times in the past. A reading index is a way to calculate writing to see if the text matches a reader’s grade level. This is also known as readability.

There are a number of reading indexes out there including Flesch-Kincaid Grade Level, Flesch Reading Ease, Gunning Fog Index, SMOG, Automated Readability Index, and more. If you use Word, you are probably familiar with Flesch-Kincaid Grade Level and Flesch Reading Ease. You can see this by using grammar and spell-check. If it doesn’t show up after you have used spelling and grammar, select it in the options (for the reading index) in the preferences and get the results for your document every time you run spelling and grammar.

Results from Word (for Mac) showing Flesch-Kincaid Grade Level & the Flesch Reading Ease

Rudolf Flesch worked on the Flesch Reading Ease in 1948 and later co-created the Flesch-Kincaid grade level in 1975 (Readable, 2021).

The Flesch-Kincaid grade level is calculated using a simple formula.

Flesch-Kincaid grade level formula

The Flesch-Kincaid Grade Level and Flesch Reading Ease are arguably the most popular reading indexes, although some organizations prefer using other choices such as the Gunning Fog depending on usage. The Flesch-Kincaid grade level is for overall general usage while some reading indexes are focused on other types of documentation such as education, healthcare, and business. The Gunning Fog is generally used for business and health (Boztas, 2017, et al.) as well as government.

While there are plenty of online reading index calculators, a writer can do the math themselves. The Gunning is calculated somewhat like the Flesch-Kincaid grade level.

Gunning Fog index calculation

A reading index is just another tool a writer can use, just like a spelling and grammar checker. Remember, it provides a method to calculate the complexity of written materials to match the intended audiences’ reading level. Be aware that reading indexes are useful but not perfect. Whatever formula you decide to use, a reading index is helpful if used correctly.


Boztas, N., Omur, D., Ozbilgin, S., Altuntas, G., Piskin, E., Ozkardesler, S., & Hanci, V. (2017, November). Readability of internet-sourced patient education material related to “labour analgesia.” PubMed Central (PMC).

Readable. (2020, November 10). The Flesch Reading Ease and Flesch-Kincaid Grade Level.