Using Simulation to Teach Project Management in the Professional Writing Classroom

It hardly bears noting that when we teach professional writing we focus on helping students learn to analyze complex communication scenarios, conduct careful research to support their position, and to responsibly and succinctly apply the process of writing any number of supporting documents. Developing these skills are essential to effective professional writing; my omission of these topics should not be misinterpreted as minimizing those efforts. Rather my goal here is to enrich and elevate what we traditionally view as the process of professional writing by suggesting that we strengthen the role of project management in our professional writing efforts. In order to accomplish this goal, we have to challenge conventional wisdom in how many of us—myself included—often construct assignments.

When we tell students that writing assignments have constraints that include page length, the genre to be employed, artifacts that must be composed, and deadlines for completion we are practicing project management. Whether explicitly or otherwise, we assume that defining the scope and time involved in completing a project frees our students to focus on what really matters: the process of composing. We might also argue that doing so simplifies the overall process so that it doesn't overwhelm less-experienced writers. Nevertheless, these decisions privilege one part of the writing process: composing, over managing the process itself. To be successful workplace writers, students need experience with both.

Project management is a fairly broad umbrella that could encompass a variety of activities. Because I am first and foremost teaching professional writing, I limit project management to include: project plans; stand-up meetings and status reporting; time-tracking; heuristic reviews and basic usability testing; issues reporting; and final deliverables and project memos. My goal is to provide an overview of a process for managing writing projects, while also helping students understand that project management may vary significantly from organization to organization, and from situation to situation.

The reality that students will face as they transition into the workforce, however, is that shrinking resources and tightening deadlines make project management more important than it ever has. As a case in point, George reports that "work that adds no value in your customers' eyes typically comprises 50% of total service costs" (3). This presents us with a significant opportunity for improving the speed, quality, and cost associated with the work that we do, and project management offers us the strategy for accomplishing those goals.

My goal here is to illustrate how one assignment, a classroom simulation involving role-play, might introduce students to applying the preceding project management strategies to research and writing activities in a professional writing classroom. Additionally, my goal is to present a fairly easy-to-implement project management process that steers away from both software development processes (e.g. Agile, Rational Unified Process, triple-constraint model) and the technologies (e.g. Microsoft Project) and processes (e.g. Lean, Kaizen, Six Sigma) often associated with project management. Although many of the sources I use in this article derive from the Lean Six Sigma approach, my goal is to focus less on the analytical tools that are the hallmark of Lean Six Sigma, and to focus significant attention on what we can learn about communication, team dynamics and the softer skills associated with managing a project.

The Simulation: Web Analytic Dashboards

The goal of simulation is to take students outside of traditional academic writing practices and offer them opportunities to practice work-place writing that as closely mirrors the experience as possible. In this particular simulation, students are presented with the following scenario:

You are a business analyst for a relatively new on-line retailer. Your CEO has just returned from a conference where he was told by leading business consultants that every company should have a Web Analytics Dashboard. All he can tell you is that a dashboard is a small handful of screens that will allow her to track the most important metrics associated with the company's Web site.

By the end of the week, your task is to create a prototype that will allow him to share the idea with the senior executive team. In addition, he has also asked that you research and document what other companies are using with dashboards. He will use your documentation to educate and seek approval from the executive team for the development of the dashboard.

There are a couple of additional features to how I use the scenario in class:

• Students are asked to complete the scenario in teams;
• Students may complete the scenario however they choose; however, every student is required to participate to some degree in both conducting research and in developing one or more prototypes;
• Students play the role of business analyst; at the mid-point of the simulation, I play the role of CEO and allow students 20 minutes of un-structured time to ask questions and share initial thoughts to gain feedback on their work;
• The simulation intentionally involves a shorter-than-ideal amount of time to complete the project;
• The simulation occurs very near the end of the semester after we have covered genres like annotated bibliographies and reports, oral presentation skills, graphic design and other skill sets necessary to complete the simulation successfully.

In addition to creating impactful, useful dashboards (these examples illustrate the typical dashboards students create:

and research artifacts, there are two additional goals that I have for this project. First, the simulation affords students the opportunity to practice the decision-making process of both choosing and successfully writing and adapting the appropriate artifact in a specific situation. In this simulation, students have successfully created memos, annotated bibliographies and research reports to support their dashboards. Giving them the opportunity to see that one might successfully employ different genres in solving a problem is a useful experience. Second, the simulation provides an opportunity for us to discuss project management. 

For my students, this scenario creates some specific challenges. First, they often don't realize that they know less about Web analytics than they think [1]. Second, they quickly recognize that they've apparently been asked to do a fair amount of work in a relatively short amount of time. It's the combination of limited knowledge and limited time that lead us, as a class, to a review of project management and how we might apply it in this particular situation. What follows are some of the techniques students adapt to this scenario.

Introducing Project Management

When I talk about project management in class, I start with an overview of why project management is important:

• Inasmuch as writing is a process, effective writing implicitly shares many common points with project management;
• Students need to continue developing a sense that they have the responsibility and control to ensure success with their writing;
• Life is about setting priorities and making sacrifices, and project management helps manage the decision-making process;
• Individuals on project teams don't always set priorities or see solutions in the same way as their peers;
• In a business setting, project management helps to save cost, time as well as to ensure the delivery of a quality end-product;
• An increasing number of project teams in the business world do not necessarily have dedicated project managers; and
• Effective project management is difficult to out-source.

If I start with any of what I would consider typical descriptions of the writing process, I'd likely encounter something nearly identical to Markel's planning, drafting, revising, editing and proofreading (33) outline. Although all writers might approach this process a little bit differently, this discussion at least helps acknowledge that this is often an inherently iterative process.

For beginning writers, whether we're explicitly aware of it or not, we set boundaries on assignments that are intended to help them manage their projects. For example, if I ask students to write a letter to their congress person on the impact of stimulus money in their community, to limit it to no more than 500 words, to use standard business letter convention, and to have it completed within a week, I have established the scope of the project—what students are going to produce, and what it looks like as a finished product. I've also established the time or effort we expect will be required. The only real difference between this approach to managing a writing project in an academic setting, and in a business setting is that most real-world projects also have cost associated with them.

As suggested in the list above, however, it is often easy to overlook the manner in which students set priorities and make sacrifices in our classrooms, relative to their other courses, and in relationship to their personal lives. An important part of the planning process includes encouraging students to have an honest, straightforward conversation about their priorities, and their impact upon the project. To facilitate this discussion, I encourage students to complete a worksheet (the worksheet is available as a Word document here) that attempts to make those priorities more visible to students so that they might more rationally discuss them with their peers, and set their plan for this project accordingly.

In our classrooms, I think we can acknowledge that following the writing process and the project management parameters outlined by scope and time don't always result in success in the same way that it doesn't in a business setting either. If we return to our planning, drafting, revising, editing and proofreading outline, we might ask questions of it that a project manager might ask:

• How long will planning take? What planning tasks are most relevant, and which should I do first?
• When does drafting end?
• If I'm revising, how do I recognize that I might need to go back and conduct additional planning? What impact does that have on the amount of time I have to complete the project?
• In a team setting, how do I divide the work equitably and efficiently?

As a class, once we have a foundation for what project management is, and why it's important in writing and design work, we move onto a discussion of some of the tools that are available to help ensure we deliver successful final projects.

Project Plans

Project plans are often a matter of reverse-engineering a process. Students are encouraged to start with their due date and their understanding of what they need to deliver, and then to work backward developing a plan for completing the work. In a very tactical sense, good project plans outline the work that needs to be completed, and the deadlines for completing key tasks. As Williams recognizes, however, there is one key concept that determines whether or not a project plan will be successful in guiding the work: "each and every deliverable needs to have an owner" (77). Students often will misinterpret this to mean that each deliverable is worked on by only one person. In the case of the Web Metrics simulation, it means that one student is responsible for ensuring that the prototypes get built, even though every student on the team is responsible for sharing in the work.

In some respects, one might think about traditional writing assignments as situations where the instructor is the project manager who creates the project plan. Asking students to write a business letter that is no more than one page in length, for example, possesses many of the elements of project planning in that it dictates both the genre and the scope of the final product. With the simulation, I am giving student teams both the responsibility and the freedom to determine their own project plan.

In putting together project plans and assigning work on the team, there are a couple of questions that I ask students to discuss. Part of the goal of these questions is to help them be more thoughtful in assigning the right work to the right person (if someone on the team is passionate about proofreading, they're going to do a better job leading the task, than someone who is not); part of the goal is to open dialogue on the team so that students start to develop trust in their team. Some of the questions I ask students to consider include:

• What is the most difficult aspect of the project? What makes it difficult?
• For each of them, what are their goals for the project? Are they more interested in research or in prototyping?
• How important is the final grade to them?

As much as possible, where students are able to match motivation and task, the more likely they will succeed.

In a practical sense, a basic project plan identifies the milestones and tasks associated with the project, assigns a responsible person, and establishes a target due date. One of the advantages of creating a project plan for developing writers is that they begin to see that it's no longer adequate to assign a deadline for completing a draft of a report (a milestone), but necessary to break the process of completing the draft into a series of tasks which might be either process-oriented (e.g. audience analysis, conducting research) or product-oriented (e.g. creating deadlines for individual chapters or sections of a document), or some combination of both.

I provide students with a basic template in Word (the template is available here) to use to create a project plan. If the goal is to reinforce that it's the process of creating a plan that's most important, this is an easy way to create an effective plan. However, if one would also like to introduce students to the technology associated with project management, tools like BaseCamp [2], provide a free online way of creating and sharing basic project plans.

Stand-Up Meetings and Status Reports

The best-made project plans remain just that: plans. One of the most significant challenges in managing collaborative efforts is in recognizing that project management doesn't end with the project plan. Students need to check-in with each other on a regular basis, and they need to have developed a level of trust that allows them to share problems with each other.

Stand-up meetings provide one opportunity for sharing project status and for discussing issues. Quite often many of us are accustomed to being penalized when we make mistakes: we receive lower grades, we incur additional banking fees, and we might lose out on a promotion. Within the safety of our team and the classroom, however, we need to recognize that projects don't always go as planned: if we're doing our jobs well, we might learn information in our research that causes unplanned re-work on our prototypes. Instead of ignoring these issues, the goal of our stand-up meetings is to foster an environment that is tolerant of mistakes, but resilient in its pursuit of success.

In the simulation, students are encouraged to gain experience with two types of status reporting. The first is the type of informal feedback that one provides within the workgroup to ensure that peers know how your work is progressing. It's also an opportunity to raise issues and ask for feedback from the rest of the group. The goal of in-group meetings is to provide frequent, but efficient, feedback. Often, it's the in-group status reporting that alerts the team to the fact that the project plan may need revision. Status reporting is a reminder that for a plan to be truly useful may require frequent revision—it's not the sign of a bad plan that it needs revision, but the sign of a functional process that it gets revised.

As with any real-world project, there are individuals outside of the workgroup that need to understand project status. That might be one's department, project stakeholders, and company management.  Often, this status reporting is more formal, and may include supporting documentation in the form of a written status report, Power Point presentation or other document. Within the context of the simulation, status reports are given to the class. Primary emphasis is placed upon providing a very brief overview of the work completed, and remaining, with a more extensive sharing of issues the group is encountering. The goal with this kind of status reporting is to help students understand that groups never work in isolation. As George, Rowlands, and Kastle remind us: "There are always people not on the team who have knowledge or skills the team could use" (32). For this reason, in-class status reports that focus on breaking down barriers between teams is a significant challenge: we're used to assessing individual and individual team efforts, but don't always encourage students to work across those boundaries.

Time-Tracking

Although I have acknowledged that project plans are imperfect documents, it is still important to discuss the ways in which future project plans might be made better. One of the most significant challenges associated with project work rests with estimating how much time individual tasks are going to take. Some of us grossly underestimate how long things might take; others are just as likely to overestimate. One of the only ways to develop a true sense of how much time things will take is to keep track of time spent on projects.

In the case of this simulation, students use an open source application called Anuko Time Tracker [3]. I expect students to report all of the time they work on their project, to the closest 15 minute increment; they have the option of reporting work as they complete it, or providing a summary of time worked at the end of the work. My primary goal is to help introduce students to the concept that many of them are going to have to track the time they spend on projects as professionals. It's also important for them to begin to understand how much (or how little) time goes into completing various types of tasks—it's an opportunity to help them ultimately learn how to create more accurate project plans. This is also an opportunity to talk to students about how we often become more proficient as we encounter similar writing tasks over the course of our careers.

In my personal experience, students are largely honest in reporting the time they spend on a project—or not reporting time when they're not putting forth the effort expected of them. As a result, with a fair degree of accuracy, it allows us as instructors to gain a general feel for the effort students are committing to a project. Longer term it means that we can adjust requirements, team sizes and other parameters if we've mis-judged the effort required to complete a particular assignment. In short, it helps us manage our assignments better as well. Where students are not as honest with their reporting, a combination of the stand-up meetings and status reports, mentioned earlier, and the final project memos (see below), typically make that fact evident.

Heuristic Reviews and Usability

There are significant parallels to draw between what a Web Developer or Software Engineer might refer to as a Heuristic Review, and what a writing class might perform as a Peer Review. In both instances, students are asked to serve as experts and provide feedback on a peer's work. Although there are many heuristics available, one of the most consistently used heuristic in Web design comes from Jakob Nielsen.

Both prototype and research document (whether a report, memo, annotated bibliography, or some combination therefore), can be subjected to the rigors of a heuristic review. To be successful with a heuristic review, one must understand the goals and expectations of the readers and stakeholders involved with the project. Especially with tight deadlines, and other priorities, it's not possible to thoroughly test one's prototypes and research documents. With that in mind, students are encouraged to develop and implement a heuristic review of their dashboards, but rely on more traditional peer review for gaining feedback on their supporting documentation.

One of the biggest challenges, however, rests with helping students see the subtle difference between viewing heuristic reviews as identifying problems, as it is in helping to resolve any issues before it's presented to stakeholders. Done well, heuristic reviews provide formative, rather than summative, feedback on the project.

Issue Tracking

In software development, the team will often use software to track bugs and other issues associated with their work. In this project, it's important—as it was with time tracking and in the development of project plans—to point out that the tool is not the important decision here. What's important is determining what to track, and how to track it to benefit the team.

For this project, then the template (available here as a Word document) provides a simple way for the team to record and track progress against outstanding issues. This is also a way for issues to get captured and not serve as stumbling blocks. Too often teams get stuck trying to resolve an issue when they might be more productive placing that work on hold and completing other tasks. For those readers with experience in software development, you'll notice that this template and approach is extremely light-weight, and it's important to make sure students know that in other situations issue tracking may be a much more extensive process. In my experience, however, groups don't typically encounter a significant number of issues. Keeping a fairly simple list is more than adequate, and this template serves as a reminder that we need to adapt our project management tools and processes to the situation [4].

Final Deliverables and Project Memos

Final deliverables in my professional communication courses often means not just a written artifact, but an oral presentation as well. Giving students the opportunity to hone their speaking skills is crucial. In many business situations, decisions are often made as much on the merits of information presented orally in a meeting as on the written artifacts themselves. It is not my goal here to describe what I consider to be an effective oral presentation. I do think it's important to point out, though, that the informal group status reports and more formal classroom-based status reports give every student multiple opportunities to practice presenting in increasingly higher-stakes settings. As a result, most students are fairly well-prepared by the time they are expected to present their work orally.

One of the issues that both students and instructors need to acknowledge is that final deliverables are artifacts that are largely silent on the issue of how they were created. In empowering students to manage their work processes, I'm less interested in monitoring their activities closely than I am in helping them to critically assess how they complete work so that they can improve upon it over time.

The project memo is an opportunity for students to reflect on their work. Typically, I ask students to respond to a short, seemingly simple set of prompts:

1. What did you do? How did you do it?
2. What went well?
3. What didn't go so well?
4. What will you do differently in the future?

Largely, these prompts culminate in the last question: the goal is to not only be aware of issues, but to begin developing a sense that problems don't always just happen. Even if they do, we often have means at our disposal for dealing with them.

Project management done well is not busy-work, but a conscious effort to ensure that the way we approach writing and composing processes is most likely to yield success.  Project management done well, however, is also malleable. While some groups may need to be reminded that project plans will never be perfect (nor will their research or their prototypes), others may need assistance developing processes for managing how they deal with conflict or make decisions. In teaching students to become better project managers, it's also our role to serve as project managers ourselves in providing the support and empowerment that teams and students need to be successful.

Notes

Works Cited

George, Michael. Lean Six Sigma for Service. New York: McGraw Hill. 2003.

George, Michael L., David Rowlands, Mark Price and John Maxey. The Lean Six Sigma Pocket Toolbook. New York: McGraw Hill. 2005.

George, Mike, Dave Rowlands and Bill Kastle. What is Lean Six Sigma? New York: McGraw Hill. 2004.

Markel, Mike. Technical Communication. 8^th Edition. Boston: Bedford/St. Martin's. 2007.

Nielsen, Jakob. "Ten Usability Heuristics." Useit.com. Downloaded from: http://www.useit.com/papers/heuristic/heuristic_list.html, Aug. 30, 2009. (Date Accessed: Sept. 19, 2009).

Shore, James and Shane Warden. The Art of Agile Development. Sebastopol, CA: O'Reilly, 2008.

Williams, Meri. The Principles of Project Management. Collingwood: sitepoint. 2008.