Project Management Approaches in Technical Communication

The 13th chapter of Solving Problems in Technical Communication (Johndan Johnson-Eilola and Stuart A. Selber, 2013) asks a solid question: “How Can Technical Communicators Manage Projects?” (page 310). That is definitely something my work team tries to keep a handle on, and we’ve tried several of the methods identified in this chapter.

By and large, my proposal team follows a version of “most traditional project management system” (page 314): the waterfall system. Our project phases are defined and executed in order, where one phase typically does not start until the prior phase is completed. We follow the waterfall outlined as a best practice by our professional organization, the Association of Proposal Management Professionals (APMP): Market Identification -> Account Planning -> Opportunity Assessment -> Opportunity Planning -> Proposal Development -> Negotiation -> Delivery. Depending on the scenario, we may decide to skip a phase. For example, if we’re trying to start a second project with an existing client, we may skip the Market Identification and Account Planning phases because the sales team may already have “second location” in their strategy plan. Either way, we follow the same waterfall process with each proposal so that we are consistently thorough with each opportunity.

Agile development has been a trendy phrase over the last few years, but we have not found that to be particularly user friendly for our needs. Similar to the user-centered design approach, Agile asks “audience members and developers [to] create ‘stories’ that are scenarios of user tasks to be performed and features needed to perform those tasks” (page 326). The project is then developed in short stages, each stage focused on a single “story”; iterative testing occurs for each stage and the project does not move forward until the stage is deemed complete and successful. However, this can be a tricky approach for technical communicators to adapt. Agile works well if for teams that are willing to embrace the iterative approach, or for teams that work out of one location and can meet daily for status meetings. At a conference I attended last May, the Agile seminar was one of the more popular sessions but nearly the entire time was spent asking questions: most of us just don’t know how to adapt the ideas of Agile (which is most definitely an IT-heavy concept) to the world of technical writing. Because it can be more complicated to implement, there are some people who feel Agile will soon no longer be a preferred approach. In an article for Forbes, Kurt Cagle wrote “The End of Agile” (, in which he details why Agile’s longevity may be at risk.

In consulting, we sometimes used the user-centered design approach, especially if we were doing system design projects. We often would create scenarios that were representative of employee tasks and would then modify the system to accommodate those scenarios. User acceptance testing was done by the employees to make sure there were no unanticipated hurdles and, many times, the feedback from those tests impacted the final design of the system.

Ultimately, there doesn’t seem to be a right approach or a wrong approach to project management in technical communication. The type of communications and the types of environments we find ourselves in may dictate which approach we use, particularly if the company already has a preferred method. Whichever approach we adopt, we must be comfortable and confident in leading the process.


Johndan Johnson-Eilola and Stuart A. Selber. Solving Problems in Technical Communication. The University of Chicago Press, 2013.

Kurt Cagle (2019, August). The End of Agile. Fortune. Retrieved from:

Classification-Driven Analysis and Prototype Theory

I focused my last blog post on Activity Theory as presented in Chapter 6 of Solving Problems in Technical Communication (Johndan Johnson-Eilola and Stuart A. Selber, 2013), and with additional detail from the Technical Communication Body of Knowledge (TCBOK) website ( As our professor pointed out in feedback to my last post, Kirk St. Amant is a professor and researcher who studies Activity Theory in detail as it pertains to international communications. I was excited to see him make an appearance in Chapter 10 of our text.

In Solving Problems, Karen Shriver introduces “three models technical communicators use to understand audience: classification-driven, intuition-driven, and feedback-driven analysis” (page 239). She defines classification-driven analysis as “[proceeding] ‘by brainstorming about the audience and by cataloguing audience demographics (e.g., age, sex, income, education level) or psychographics (e.g., values, lifestyle, attitudes, personality traits, work habits)’” (Solving Problems, page 239-40; Karen Schriver’s Dynamics in Document Design: Creating Texts for Readers, 1997, page 155). Her interpretation of classification-driven analysis can focus “on how cultural differences – from differences in values and perceptions to differences in the way tasks are organized and conceived – affect the content or design of documents” (Solving Problems, page 243).

St. Amant then supports this idea with his thoughts on localization, with the book using website design as an example of documentation being catered to meet “values and expectations of users in different cultures” (St. Amant, “A Prototype Theory Approach to International Website Analysis and Design,” Technical Communication Quarterly, 2005).

St. Amant suggests prototype theory, “a complex theory of how humans categorize new information and images by comparing them to established information” (page 244) as a possible method of developing ideas on localization. Using prototype theory, St. Amant suggests two steps:

  1. Document creators could “identify a representative site and create a checklist of its features, looking especially for patterns that would indicate acceptable ranges of associations”; and
  2. Document creators could then “test this checklist against other sites in the same cultural context” (page 244).

Together, these steps could be completed by technical communicators to determine an audience’s “acceptable and effective” (page 244) elements for their own documents.

Although the example in our textbook focuses on website design, this approach by St. Amant could be applied to a variety of documents. I have always followed these steps in my professional career when creating documentation without realizing there was actual theory behind it:

  • If I needed to create a process guide for a client, I studied existing guides the client already had and noted phrases, acronyms, images, and color and font style choices.
  • If I needed to create process flows, I looked at existing flowcharts and noted use of color, what shapes were utilized, and the flowchart layout.
  • If I was creating policy documentation, I looked at existing policy documents and noted overall tone, document sections, and the level of detail.

I always aimed for my documents to “match” existing documentation so that it would be a cohesive bundle of documents and so that the client would easily accept the new documents as something familiar and legitimate. I was, intentionally but without knowing the theory behind it, trying to make my documents “acceptable and effective” for my readers.

(If you’re looking for additional information on using prototype theory to examine existing materials, I found St. Amant’s full article online. He explores the idea of website design for an international audience in greater detail, and, if you’re like me, you might find it interesting.)


Johndan Johnson-Eilola and Stuart A. Selber. Solving Problems in Technical Communication. The University of Chicago Press, 2013.

Karen Schriver. Dynamics in Document Design: Creating Texts for Readers, 1997.

Kirk St. Amant. “A Prototype Theory Approach to International Website Analysis and Design,” Technical Communication Quarterly, 2005.

Activity Theory

As the class dives deeper into technical rhetoric heuristics, we are focusing on Situating the Field. In Chapter 6 of “Solving Problems in Technical Communication” (Johndan Johnson-Eilola and Stuart A. Selber), tools of technical communication are introduced as components that “shapes both the practice of technical communication and the social interactions that technical documents foster” and “shows both the plentitude of tools around us an the subtle ways that they alter our perception of the world” (page 149). These tools “mediate the work of technical communication by shaping and organizing how writers conceive of and carry out their projects” (page 146).

I was really drawn to the concept of using activity theory to study mediation. According to Johnson-Eilola and Selber, activity theory “advocates understanding the mediating influence of a tool in a larger historical and cultural context” (page 151). It “considers a community and its rules, structures, and divisions of labor” (Cole and Engeström 1993). Johnson-Eilola and Selber go on to further describe the application of activity theory:

  • It “suggests that all tools are situated in a social activity, a goal-oriented task, through which one participates in a community” (page 152);
  • It “reminds us that tools also mediate how users relate to other people” (page 152); and
  • It “tell[s] us to look for design histories” because “tools change in significance and meaning as they become associated and disassociated with particular contexts and tasks” (page 153).

When you live in another country – or perhaps even when you travel to another country – this concept of activity theory becomes a necessary consideration. To communicate effectively with those from a culture different than your own, it is vital to understand the historical and cultural context of the environment in which you are communicating. This is also important in writing: I have worked in a role in which most of the company operated outside of the United States, and any technical communications I worked on needed to be sensitive to those other cultures, the tools they had and preferred to utilize, and I was mindful of the context I used in documents.

I did some additional research and found several articles on the Technical Communication Body of Knowledge (TCBOK) website (

The TCBOK has several wiki pages devoted to activity theory. On these, they define activity theory as “a rhetorical framework that is used to understand discourse and how it affects those who both read and use text” ( In this wiki page, “the most basic and most important aspect of Activity Theory is the interaction process, which happens at many levels inside of businesses and organizations.”

Another TCBOK wiki page details five principals of an Activity Theory Model (

  1. Hierarchal Structure of Activity: “The unit of analysis is an activity directed at an object . . . the constituents of activity are not fixed, but can dynamically change as conditions change.”
  2. Object-Orientedness: Our reality is objective, and components of our reality have properties “considered objective according to natural sciences but socially/culturally defined properties as well.”
  3. Internalization and Externalization: “[Internal] activities cannot be understood if they are analyzed separately from external activities.”
  4. Tool Mediation: “[Human] activity is mediated by tools” which “are created and transformed during the development of the activity itself and carried with them in a particular culture”; thus, “the use of tools is an accumulation and transmission of social knowledge.”
  5. Development: As a general research methodology, Activity Theory “is not traditional laboratory experiments, but the formative experiment that combines active participation with monitoring of the developmental changes of the study participants.”

Our text by Johnson-Eilola and Selber does not go into this much detail, but I think the five principals given by the TCBOK are important to consider as we move forward to “situate the field” in our heuristics. If we’re going to consider tools and how they are situated in contexts of activity, we need to keep in mind that the variables (the tools, the contexts, and the activity itself) can change at any moment. We should be open to change and willing to adapt our communication approach accordingly.

Heurstics in Technical Communication

I have been involved with technical writing for almost ten years, both as an external consultant and as internal staff. I completely agree with the idea that change is the only constant in this field: where Microsoft products were the tool of choice, now we also have Google applications; where we used to work on a document one person at a time and email it back and forth (heaven help you if a file size was too big to fit in an email and your collaborator was off-site), now we have cloud storage and library repositories that can store documents and track version history; and where we used to chase people through buildings to collect signatures, now we have DocuSign.

Throughout it all, though, I’m not sure I ever heard the phrase “heuristic.” Yes, I had general frameworks for how to approach a project, or previous projects I could use as a baseline template, but there was not a formal name for it. As described in the introduction to “Solving Problems in Technical Communication,” every project I’ve worked on has been different. With each project, solutions were chosen based on previous projects and successes, and then each solution would be adjusted to fit the new project. We were identifying tendencies and commonalities and using those as a jumping-off point for the new project.

The detailed description given of the four phases – Mapping the Field, Situating the Field, Understanding the Field Approaches, and Developing Field Knowledge – was very interesting. I think most technical communicators, sometimes unintentionally, go through some or all of these phases with every project they tackle. My peers and I did not follow a true heuristic approach, probably because we were not familiar with that phrase. There was no second level of analysis; we just moved on from one project to the next and repeated the process of identifying and utilizing a previous solution that best matched the current project. There was no retroactive assessment of the problem and its solution, no identifying what worked well and what failed. It seems like such a basic concept to evaluate a completed project and I’m a little embarrassed to say we never did. As they say, hindsight is 20-20.

As the text points out: “technical communication problems are – at their core – ill-structured, complex, and messy, defying easy or pat solutions.” I completely agree with that assessment. Each project, or problem, has its own set of parameters, metrics, and rubrics for success, and each project may have its own audience or stakeholders which require unique handling. Because each problem is so different, I definitely see the value of utilizing all four phases of a heuristic to continuously refine the approach to communication.

The first two phases focus on context. Mapping the Field asks problem-specific questions and Situating the Field asks broader questions. The text states it does not matter which of these phases occurs first, which is good. I cannot remember an instance where I asked broad, general questions after asking for specific details; I think my default is to situate the field first and map the field secondly.

In technical communication, the broader questions are the first things I look for: what type of document will be required, have I done something similar that can be used as a template, and who are my stakeholders? Then I ask the specific questions: what are the formatting requirements, and does the delivery method impact the tools available to create the document?

When I step back and think of technical communication as a field, I think it does make sense to map first and situate second. It makes sense that a “concrete snapshot” should be captured before moving on to consider or develop theories that may be applicable to that particular snapshot.

The third and fourth phase address the broad applications before moving to the specific applications, which fits better with what my instinct says: ask how we can do something and then ask what we need to do it. Much of the time when I ask these questions – again, unintentionally following these phases in a project – I am only asking to understand the practical application of them; I do not consider the theoretical application of them. I’m excited to see how this book encourages using the four phases of heuristics so that I better understand the rationale for each phase and how I can apply it my own technical communication projects.

Introduce Yourself (Example Post)

This is an example post, originally published as part of Blogging University. Enroll in one of our ten programs, and start your blog right.

You’re going to publish a post today. Don’t worry about how your blog looks. Don’t worry if you haven’t given it a name yet, or you’re feeling overwhelmed. Just click the “New Post” button, and tell us why you’re here.

Why do this?

  • Because it gives new readers context. What are you about? Why should they read your blog?
  • Because it will help you focus you own ideas about your blog and what you’d like to do with it.

The post can be short or long, a personal intro to your life or a bloggy mission statement, a manifesto for the future or a simple outline of your the types of things you hope to publish.

To help you get started, here are a few questions:

  • Why are you blogging publicly, rather than keeping a personal journal?
  • What topics do you think you’ll write about?
  • Who would you love to connect with via your blog?
  • If you blog successfully throughout the next year, what would you hope to have accomplished?

You’re not locked into any of this; one of the wonderful things about blogs is how they constantly evolve as we learn, grow, and interact with one another — but it’s good to know where and why you started, and articulating your goals may just give you a few other post ideas.

Can’t think how to get started? Just write the first thing that pops into your head. Anne Lamott, author of a book on writing we love, says that you need to give yourself permission to write a “crappy first draft”. Anne makes a great point — just start writing, and worry about editing it later.

When you’re ready to publish, give your post three to five tags that describe your blog’s focus — writing, photography, fiction, parenting, food, cars, movies, sports, whatever. These tags will help others who care about your topics find you in the Reader. Make sure one of the tags is “zerotohero,” so other new bloggers can find you, too.

Create your website at
Get started