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” (https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/#18b81a832071), 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: https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/#18b81a832071