Hey associates, this lecture concerns project management strategies and genres for technical, professional, business, and personal productivity contexts. I’m going to talk about documents to capture, document, and provide direction: three verbs that are essential for staying productive and accountable in project and collaborative environments.

• The first section explains the WHY of documenting the actions and situations in a project.
• The second section dives into the most common genres across workplaces with practices for effective writing.
• The final section covers more roles and niche-specific genres to be aware of and their uses.

You can listen along to the podcast episode, which has the same content as this chapter (you are currently reading a formatted transcript of the podcast lecture).

You can use the notetaking guide to help organize your thoughts and Big Actions–the “what will I do because of this information.”

Recap Sections

I will list the topics and key points you need notes on in these blue boxes. This box doesn’t replace reading the section; it is just a guide to help you check your notes.

• Try different styles of notetaking! You can doodle, make cartoons, create a slide deck, color code your points, and use interactive tools like OneNote (which allows making flashcards) or third parties. Don’t limit yourself to a bullet-point list–if you find that boring or ineffective. Take control of your learning and make it more engaging, creative, and useful.
• If you tried doodles in the last chapter, try a different style this time. College–and especially these general education courses–are meant to let you explore learning strategies and practices so you are prepared and equipped for your more challenging major classes and professional development.

Section One: The What and Why for Projects

To begin with, let’s consider the life cycle of a project. There are many ways to manage the development cycle of projects, which we will discuss in the lab activities, but a project never just goes straight from idea to existence. We have to take steps and stages, and the more thought and seriousness you put into your project cycle, the more efficient and quality your output will be.

We start with an idea, and then we work through four stages of project management.

✨The first is the pre-project planning stage. Before investing too much time developing an idea that might not be needed, we need to do some pre-planning to..

• • Define the problem – identifying needs, goals, objectives, and constraints.
  • Research the context
  • Identify potential variations and alternatives
  • Consult with stakeholders

In a class project, this pre-planning stage might look like reviewing the assignment and brainstorming some options. You would do light research to make sure your topic options have enough substance or quality to them for the assignment. And then you can meet with your professor to answer any questions and confirm your topic will work. That stage saves you a lot of trouble than if you just dive into the first idea you have. Remember: you can only make the best CHOICE if you give yourself viable options.

✨Once the idea’s viability is considered, we get into the project development stage. Basically, now that you know the idea holds up, you can start working toward it by

• • Writing the plan (timeline, budget, tools, etc)
  • Developing or designing detailed concepts
  • Submitting or responding to RFPs with formal proposals

In our classroom example this development stage is when you create your sketches, outlines, and organize your project. Here you set your personal due dates and milestones.

✨Since you created a clear plan in the development stage, you can get into the project implementation next. Here, you actually do the work.

• • Write contracts and apply for permits for construction and building sites.
  • Report on your progress along the way
  • Document and record the project elements
  • Continue research and design improvements.

Here is where drafting, checking in with your professor, working with your study groups, and using all the resources to finish the project come into play.

✨And finally, the project completion stage. Being “finished” doesn’t mean the project is done, though. We still need to:

• • Provide final reports and documentation such as a project completion report or retrospective
  • Close contracts and pay the people.
  • Build out any ongoing Support: user guides, FAQs, assessment plans, maintenance schedules, and follow-ups.

Here is where you wait for the grade and possible make revisions or resubmissions (if the professor allows it), review the feedback to incorporate in future projects, and generally assess how it all went and where you can improve.

1.1 Reasons for Documentation

One of the main reasons we write things down is to create a paper trail–in a very logistics and personal accountability focused way. And so, for better or worse, there definitely is an idea, especially in American workplaces, that the person who’s really good at documenting, expressing, and sharing what is happening gets this kind of edge of authority. Something in writing is typically viewed as more valuable and official than verbal accounts or agreements.

Also, documenting what you plan to do, what you did, how it got done, and any incidents that occurred show more accountability. No matter kind of what workplace you end up in, whether it’s more in the business administrative side, if it’s more of like a technical side, a field side, a medical side, an engineering side, whatever kind of job you end up in– your ability to capture what is happening around you, explain to somebody the actions that you’ve taken, and recommend the actions moving forward, definitely can give you some ethos–credibility and authority– and be a strong way to show your value and contributions.

The big picture, the big thing to remember, for why we will talk about any of these genres at all is because we want to document what’s up and drive action forward. And so the genres we’re going to talk about that are really good at doing this is going to be the personal correspondence–emails, memos, letters– things like incident reports or accident reports, progress reports, and certain briefs. And all of these genres really explain to, you know, the folks in charge, the folks on your team, your clients, whoever, even yourself, just what is happening around you and what needs to happen next.

There are four kinds of basically common or likely scenarios that I guess you’ll probably encounter across any kind of job or workplace or industry you end up in–at least, it is the things I and my friends across various technical and creative industries experience.

✨So, the first one is if you need to summarize a situation. So maybe you travel for the project, and then you need to submit something like a trip report that explains all of your expenses and the outcomes of your trip. Again, it’ll be super short, and often, companies have a template or online submission portal for you to document the activities, how they relate to the project or work, and the receipts. Or if something happens, like your lab equipment maybe breaks down, you need to document what happened, how it impacts the workflow, when it needs to be fixed, and if parts need to be ordered. All that is just about summarizing a situation. So that way, you can hand it off to the powers that be and get that resolution you need.

✨The next thing that you might use it for is sharing progress status. And so if you have a lot of long-term projects..anything that spans 3+ weeks…you need to keep tabs on the work and update people. Your clients, supervisors, or parallel teams, all these different people on a project, need to know that you’re still on track. So that way, everybody knows that you are spending their money accordingly, you’re spending your time accordingly, actual results are happening, and the deliverable will come. We more commonly use the informal versions to just send over to your team as a quick check-in, as well as mid-formal versions for maybe your project manager, your product manager, or your supervisor. Those ones might go in a file or even come up with performance reviews, too. And then we have formal versions that might go to your investors or clients if you’re contracted to do something more external. Formal reports every longer period–quarterly or annually, for example– is really common for funding, right, because if people are giving you money, they really want to know that their money is going towards something.

So, summarizing situations and sharing a progress status are the two most common document needs across the general job market. And if you own a business, you’ll probably want to expect those from the people working under you so you know what is going on.

✨The third situation is to request stuff or complain or, you know, ask for adjustments if something goes wrong. So these are kind of specific, but it’s really like, if you end up working with budgets in any way, it will be pretty common for you to file official reports to request more money, basically for what you need on the project. And you’re going to have to explain how much you need, why you need it, why there are no other alternatives, where it’s going to come from, why this specific thing service product good is necessary, and why you can’t get some other alternative (especially if there are cheaper options and such). All of those are things that you would put in your documents about the project to justify and explain and ultimately request what it is that you need. We like to have that paper trail, having that clear thing that you can reference back to, even if it just for yourself.

For example, when I launched my freelance LLC, I still documented why my “company”–even though it is literally just me and my spouse– needed and chose certain software, new equipment, and other budget items. Creating those documents required me to stop and actually think, research, compare, and justify–to myself–which options were best and worth the investment costs. And now we have records in case, even though the need for audits and such are low for us.

You also might need to submit formal letters or documents to manufacturers or service providers that you can’t just order online. And so as you get into that scaled-up, super expensive industry level, ordering is different. It’s not like going online and just adding half a million dollars of stuff to your shopping cart like we get to do as consumers. It definitely is more common too, you know, need actually to reach out to their salespeople, possibly submit this kind of request for bids and quotes, then you have to generate a purchase order which is reviewed and approved by your companies purchasing and finance folks, and all tracked very carefully and officially. Then, the quote, purchase orders, final delivery receipts, and any other materials are saved in the fiscal year spending records and pulled back up during budget reviews and internal (or external) audits.

My job in college was working in this type of business office, and every summer we had to ‘pull’ all the records from the past year and reconcile every document to the accounting sheets from all the department purchases, travel, etc. It was super annoying to track down missing, incomplete, or just terribly documented spending.

And last, if something goes wrong with that order, you might need to submit or at least document what happened. It could be just a complaint letter, basically sending the information back to that service provider or manufacturer. Here’s what it was supposed to be. Here’s what it is. What’s wrong with it? You know, the adjustments, the refund, and the replacement part are what we are asking for. You just put that together in a document again to save it, reference it, and track it throughout the process until you get your resolution.

So, requesting stuff is a little bit more specific. Some of us will use that a lot depending on our jobs. Others will probably not really see it, or you might just see a copy of one that you’re purchasing people bought or submitted on your behalf.

✨And then the last situation is where we need to document things for the overall direction, vision, KPIs, and strategy of a project or initiative. When you start a new project, you need to write it down–so everyone can see it and refer back to it for their individual roles–what we are doing, when we are doing it, why we are doing it, and who we are doing it for. Highly formal versions of this are probably more for you looking at leadership-level roles, while the informal versions are used widely.

I had to do this type of formal project management writing a lot when I was working at a Director level. Every decision and initiative I came up with needed to be carefully documented and justified with the outcomes. My formal documents were then often reviewed by the even higher-level decision makers for budget approvals and resource management. I also edited them into less formal versions, tailored to the people helping and working on the initiatives with me.

We also see these formal directives in the government sectors, especially where they send out memos for new policies that the other agencies need to comply with. Folks seeking grants or any special project funding need to document proposals and formal plans, too. If you aren’t writing these directives and plan documents, you will probably need to READ them from your leadership team. If you, you know, get the opportunity to oversee an intern or something in your workforce someday, or if you are just leading a smaller team and you become the project lead, you might write these on a smaller scale, too. I would need 10+ pages for year-long success initiatives, but as a project leader, you might only need 2 pages. But if you even just have a project team, you need to at least document in some informal ways the action that is happening.

So overall, we have many reasons why capturing and writing about your situations at work come up. Super often, you won’t find these expectations specifically listed in your job descriptions, though. Instead it is an implied aspect of whatever role you– the type of writing and documentation that goes in in the background to make your main responsibilities happen with a paper trail.

1.2 Ethics in Project Management

This segment discusses the specific examples and applications of ethical principles in a project management situation. We discussed ethics broadly in the introduction to the technical writing lecture. As a quick recap on those ethical principles:

• Technical writers have an ethical obligation not to mislead readers, so information should be presented in an accurate, complete, and unbiased manner.
• We also have 6 big principles, but the two most important for today are Honesty with specific expectations to not perform work outside our job scope during hours compensated by clients or employers, except with their permission, nor do we use their facilities, equipment, or supplies without their approval. When we advertise our services, we do so truthfully. And quality, where we negotiate realistic agreements with clients and employers on schedules, budgets, and deliverables during project planning. Then, we strive to fulfill our obligations in a timely, responsible manner.

You might need to adjust or update what the deliverables or the end product are going to be. That isn’t uncommon. So you need to send a status update of, “Hey, we thought it was going to be this, but here’s what it’s going to turn out like.” You have an ethical and professional obligation to provide realistic agreements that you can fulfill within the job scope.

✨I like to follow a general PR creed of “Acknowledge the situation, Move through issues, and Redirect the focus” with news and project changes like that.

• Provide concrete– yet big picture– details of why the original deliverable isn’t going to work, describe what is changing and how so the project can move forward, and redirect everyone to the solutions, new outcomes, and continued responsibility to finish the work.
• Don’t dump every detail in there and bury the important information behind a wall of text. Because that’s also an ethical principle, burying bad news and details and fine print or the presentation of information.
• Creating new prototype renders, diagrams, and other visuals can be helpful when presenting the changes to the deliverable so the client can visualize what is altered and how it can still meet the project goals. So basically, just say what’s up and make sure you have those key details and changes, and it’s clear and easy for them to see even if it might be the end of your project because they don’t like or want the new deliverable.

The other more common ethical challenge with project management is when projects fall behind and budgets need to change. So the deliverable is still working…it is just delayed or more expensive than you originally planned. And so the important thing is that you document what the changes are, why they’re happening, and what the new projections will be. Make it very clear and very direct for whoever is approving those changes so that way they can make the decision that they need.

Some may say underpromise and overdeliver in bids, quotes, and proposals…. Sure… but I say document and estimate as accurately as possible. It is easier to create realistic and feasible estimates for schedules and budgets if you have carefully and accurately documented and SAVED all your past projects. Then, you can pull up the materials for similar contexts and use them as tools and reference points for the expectations. So again— another time for those in back tuning out–documenting what is going on with projects is useful and important for BOTH your stakeholders (clients, supervisors, and teams) and for yourself (future-you who needs to reference and gauge what has gone in the past to better plan for a current project). Don’t rely on memory because it more often fails us. Write it down and reference the specifics to help you improve the planning process.

A quick story: So this situation happened to me when I was working on a freelance contract to do some technical writing for an organization, and I was actually teamed up with another freelance contractor. We were supposed to work on this project together. And that person had to drop out for personal reasons as life happens. The project manager and I sat down and created a new timeline for the deliverables. My new timeline was based on my knowledge of myself–how fast I’ve been able to turn out similar video, research, and presentation materials in the past–and my schedule. I was able to say here’s how much more time I need to make up for the work. And then I also requested a change in the budget. Hey, since I’m now doing more of the work, can I revisit my pay for this contract. Both of those changes–the new deadlines and the increased pay–were documented and signed. And then just as the project continued, I sent updates. Hey, I’m on track, I’m on schedule, and I finished right on the timeline I had estimated. It really wasn’t that big of a deal all around. But it would have been a big deal if my teammate had just ghosted instead of sending that initial change. And then suddenly it’s like, what are we doing? What am I supposed to do? Why aren’t things getting done?

So overall, I found that most people, shareholders, and stakeholders aren’t that upset when plans change because we have all been through it. If you have ever had to manage any kind of project or plan any kind of event or just work with groups of people at all, we know that things happen, right? And we have lives outside of our specific jobs. And so I personally have found that people don’t tend to be that upset that the plan is changing as long as they are told about it right away and clearly and completely, right? Going to them with the new solution or timeline with answers for potential questions ready to go. The problems tend to creep up when you kind of withhold or just avoid, you know, writing that document or sending that email or, you know, explaining it in that meeting. So as soon as you figure out that things are changing, you document it, send the status update, offer some solutions, have a clear path forward…and things usually are all right within an extent. And if you lose the contract– document all that too and use it to improve your planning and estimates in future situations.

That completes section 1 of this lecture. Please take a long break to let your mind refocus– try to take at least an hour off and come back another day. When you are ready, continue to Section 2 🎶🎶🎶

Section 2: Genres of Project Management

In this section, we will discuss general qualities for project management documents and specific genres you may encounter. You will probably write these documents and even more likely need to READ these documents in your various careers. I’m starting by discussing the idea of genre and the project management set of genres.

These project management documents are similar in the situations they are used in and in what to expect content-wise, though there might also be some variations.

2.1 Features of Project Management Genres

So, here are some features of these project management genres to look for and hold…the things that make them a “comedy film” and not a “horror film.”

✨First, typically, we will put things like contact information and other situational identifiers on the document, usually upfront. Right. And this may or may not appear in other genres and types of writing. But for these types of reports, it’s super important. Basically, think of your email headers or all the business contact information in a letter or an invoice. Right. We need the who, what, and when of the situation for incident reports, progress reports, meeting agendas, and such. Since these are about action, we like just to make sure that the reader knows who is doing the documenting and where to go for help. The next steps and more information. So contact and logistics definitely show up big time for us in project management.

✨The second thing is going to be things like the scope expectations. And so basically, you know, we include what we just call the scope of our project, which are the boundaries of that situation. These reports are short, so they want to be super focused. You will have a different project report for every project…and potentially a different variation or sub-report for the different stakeholders. So you’re telling the reader this progress report or this proposal is just about ‘Project A.’ Here are the details. Then you would write a completely different document with a scope of ‘Project B.’ Or this incident report is just incident 1 at ‘Site A’–maybe there was a big accident at the site–so you would have scope for the individuals hurt and then a larger scoped report investigating the overall that happened so you can track and support each person separately or reference a full investigation later.

✨And then the last thing is how these documents are very action and management-focused. So, we will always focus on the next actions and the timelines. And so basically telling people what happens next. What are the upcoming tasks? What is the new timeline? If you do have to do something like an incident report, often you’re going to outline the timeline of both the accident and then there going to be an investigation. Is it closing? What are the next steps?

So those are going to be our three big features, which, again, just help us think about these specific genres and documents that we’re going to talk about here: situation details, situation scope, and situation timelines/actions.

2.2 Proposals

Proposals can be super formal or informal, representing your documented event plan. I will focus on the formal variety because it is easier to scale down.

Proposals are often written in response to a Request For Proposals (RFP) by a government agency, organization, or company. The requesting body receives multiple proposals responding to their request, reviews the submitted proposals, and chooses the best one(s) to go forward. Their evaluation of the submitted proposals is often based on a rubric that grades various elements of the proposals. In that way–it is building on the skills you practice in EVERY class when you read an assignment sheet, deliver on what is asked, and get judged on how well you accomplished the task.

Usually, an RFP—and then sections for proposals generally—asks for the key elements of a good plan.

• Introduction and/or background
• Statement of problem to be solved (or opportunity to improve or innovate)
• Purpose/motivation/goal/objectives
• Definition of scope and approach (limitations)
• Situation Analysis… Political, Economic, Social, Technological, Legal, and Environmental factors in the market
• Technical background
• Project description
• Schedule of work/timeline
• Validation plan or Quality Assurance standards
• Budget
• Qualifications
• Conclusion

There are 4 kinds of proposals, categorized in terms of whether or not they were requested and whether they are meant to solve a problem within your own organization or someone else’s. From the following descriptions, you will see that they can also overlap:

✨Solicited Proposals:  an organization identifies a situation it wants to improve or a problem that it wants to solve and issues an RFP (Request for Proposals) asking for proposals on how to address it. The requesting organization will vet proposals and choose the most convincing one, often using a detailed scoring rubric or weighted objectives chart to determine which proposal best responds to the request.

✨Unsolicited Proposals:  a writer perceives a problem or an opportunity and takes the initiative to propose a way to solve the problem or take advantage of the opportunity (without being requested to do so). This can often be the most difficult kind of proposal to get approved.

✨Internal Proposals:  these are written by and for someone within the same organization. Since both the writer and reader share the same workplace context, these proposals are generally shorter than external proposals, and usually address some way to improve a work-related situation (productivity, efficiency, profit, etc.). As internal documents, they are often sent as memos, or introduced with a memo if the proposal is lengthy.

✨External Proposals: these are sent outside of the writer’s organization to a separate entity (usually to solicit business). Since these are external documents, they are usually sent as a formal report (if long), introduced by a cover letter (letter of transmittal). External proposals are usually sent in response to a Request for Proposals, but not always.

So, a few considerations in language to help us get that strong plan:

• Remain solution-oriented and constructive: you are seeking to improve a situation and not just point out everything that is wrong.
• Be clear and coherent: don’t confuse your reader with unclear ideas or an illogically organized structure. When people feel confused or frustrated, they are less likely to approve of what you need.
• Stay concise and courteous: don’t annoy your reader with clutter, unnecessary padding, inappropriate tone, or hard-to-read formatting. Again, confusion and frustration are not our friends when persuading folks.
• Focus on the concrete and complete details:  avoid vague generalities; give specifics. One of the best lines I have ever heard, which has honestly helped me be so much more productive in personal and professional situations, came from Switch, this book about change leadership by Chip and Dan Heath. ✨They provided the mantra: Soon is not a time. Some is not a number.✨ Basically, what that means is to stop and define every element in the plan so it can be measurable and held accountable.
• Spend effort to be correct:  don’t undermine your professional credibility by neglecting grammar and spelling or by including inaccurate information. If there was ever a time to triple spellcheck with our tools, print a copy of your document to read carefully, give a copy to someone else to mark potential issues, and then spellcheck again… your high-stakes proposal is for sure. Reading backward–starting at the end and looking at the sentences starting with the period– makes me pay attention to every word. When we read and reread our work in order, it is easier to miss mistakes because our brains know what we meant to say and fill in the correct thing.

Write persuasive proposals by focusing on solutions, clarity, and evidence. Even if a formal proposal isn’t necessary for the situation–like in many school projects or personal projects–figuring out your plan and writing it down somewhere increases the likelihood that you will finish it successfully and with a higher quality. Plans are good. Proposals are really just formal and super detailed plans.

If you need a little break… take 90 seconds to refocus. Then, we will talk about Personal Correspondence.

2.3 Personal Correspondence

Once your proposal is all done and approved, you must stay in touch with everyone involved. We do that with personal correspondence documents… emails, memos, and letters.

The confusing thing about our email, memo, and letter situation is that they can be both the document itself or the medium to deliver content. An email can be just an email, OR it can be how I deliver my memo to the company. A memo can be a memo, OR it can be the container for my progress report.

Email, memos, and letters share common structural elements as a document form and package.

• First, you’ll have a letterhead—or the company’s contact information, basically. This is when you see a logo and all the ‘official’ elements at the top (or sometimes the bottom) of the page.
• Then you have what you just called the attention line. Think of that as the “TO” line—basically, who needs to ‘pay attention’ to this document?
• Then, you’ll have some sort of subject or headline for the overall topic. In your email platform, you have a form field to type. For letters and Memos, it can go after all the addressee information. The subject line makes it easier to store, search, and reference.

If you use the email, memo, or letter as a cover document or delivery indicator for another document, we also include an “Enclosure” statement. That is a holdover tradition from when we were faxing things around– I never experienced that– but I understand things would get shuffled or not transmitted after the first page sometimes. Of course, today, with our digital files, we see the “Attachment” note in the email platform and the page count in Adobe Reader when we open a packet. Still, it is a good safeguard to write the “Enclosure: budget spreadsheet for Q3” in your email, memo, or letter to be direct and let people know there is more.

Content structure-wise–they follow a narrative sequence, meaning each section really builds on the prior. We still allow and low-key expect the audience to skip and scan…but the intention is to start with the Context/Situation to set up the Body/Details and end with the Conclusion/Summary. You can use headings, bullet lists, and the other Skip, Scan, Skim design features. It is less common to include visuals in these documents, but this could happen if the situation needs it.

Let’s talk about why with each specific example of personal correspondence.

✨Emails

So, if I am writing an email and treating it as the genre, it will almost always be a much smaller audience–a One-to-Few situation. We place the direct recipients in the “To” line that indicates you expect a response or that person to take action on the information.

If you’re sending an email to many people and you don’t really expect them to reply, you’re probably using email as the delivery method to get some other genre out… like a newsletter or announcement.

A great example of this from class: when I email you directly–let’s say your project file isn’t opening for me–I expect a reply and action from you. Only your email address is in the “To” line and I’m using email as THE message. But when I post an announcement to Canvas, which does trigger an email to the whole class, I don’t expect any responses. In that case the email is a secondary delivery system for the “announcement.”

With email formatting…

Your letterhead is built into your email platform with your email, the recipient’s email, and the date. And then you have your subject line. One and two, you know, just too much to process. Give them the big picture, draw attention to actions or expectations, and let them know the content. Anything more than 8 words will probably be cut off, depending on the recipient’s screen size.

For example, if you are sending an email about the upcoming budget meeting to your team.

Don’t overthink this…just say, “Hello, Name.” For the body of the email, start with who you’re addressing it to with any variation of Hi or Hello. I avoid time-based greetings because people will read your emails at different points, depending on their schedules.

Then, give them the content. Generally, max out at 500 words because anything more becomes visually difficult to read with all the surrounding stuff on an email platform. Also, many people use their phones to check their email, and that width resizing quickly becomes a long scroll. If you have more than a few hundred words… or a few thick paragraphs basically, then consider writing the information in a document to deliver via email. When we open a PDF or whatever, the reading experience is optimized for lengthier content, even on mobile devices and small screens.

So let’s talk about email as delivery real quick.

This is getting a little bit easier and less confusing, I think because we are now using things like OneDrive or Google Drive to share the files directly. So we don’t always have to attach it in an email anymore. Instead, publish and share the link directly to people or send the link over a chat system like Teams, Slack, etc. If you need to use email, then follow the same practices for the subject line and write just 1-3 sentences that just explain you’ve enclosed/attached the document and any action steps you need to complete. Ensure they can open the attachment, so be mindful of any programs–like sending .pages to a non-Apple/Mac user–and the editing permissions on a document appropriate to the audience. If you need them to collaborate and make comments or edits, you need to send the shared Cloud version and not “attach as a copy.” Sending them a copy (or if they download and save their own copy) means that you will have completely separate file versions. You adjust the editing or view settings on both Google and Microsoft when you generate the share link or attach the cloud file.

I’m going to describe a real-world example email that I received to discuss a few other elements.

The subject line reads: What is your computer model and serial #; other gear we bought?

It begins with Hi, Hayley–because it is a personal correspondence to me and me alone.

The opening sentence states: I’m doing my annual computer inventory, and I don’t have your gear listed on the sheet I have to submit to the powers that be.

The big topic is the computer inventory, as stated in the first clause of that sentence. In this case, the purpose statement is implied. The author doesn’t say… “this email requests that information for you” or anything.  And for emails, that definitely happens more and is okay because they are typically so short and direct. I do want you, though, to focus as you start out by writing more explicit purpose statements as best practice. But in this case, the orientation is, hey, this is about the annual computer inventory, and I’m missing some information. Then, the purpose I understood was basically that I’m writing this email to ask you for the information. Then, they have the information in another context. It lists three specific questions I need to answer in my reply. The whole thing is about 100 words broken into three distinct paragraphs or sections: the intro, the questions, and a concluding thought.

They sign off with a “Peace” and their name.

Sign-offs are personal to you. I go with “Vibes.” The common professional ones are thanks, best, and regards. They work for all messages, no matter your familiarity with the audience, unlike sincerely, truly, and yours, which have a bit more of a personal relationship edge to them. You can search for memes and Reddit threads on “what your signature means about you” as a joke but not a joke and make your decision from there. But do keep it to 1 or 2 words and then your name unless you want to be a little unhinged or bizarre.

In emails, we finish with the signature line. Typically, you should include your position/role, company/organization, and alternate contact info (like a phone number or Chat handle). You can customize your signature line with logos, banners, personal links, pronouns, and name pronunciation keys as well.

In a different, longer example, I received a one-to-many email message instead of a one-to-one one like before. It follows the same structure just with more content and instructions.

The subject line reads– Please Complete: Spring “No Show” Progress Survey.

It tells me right away what content and actions are required, making it easy to search my inbox with keywords like ‘progress survey’. The 200-ish-word email is then broken into paragraph 1, orientation on the academic progress reports.

The purpose statement is: ‘we are using Starfish to make reporting as easy and efficient as possible’

The implication is that ‘this email explains that process with your action steps.’ They have a call to action with my deadline and then a bullet list of which courses I need to complete the action. Next, they use italics and bolding to draw my eye to the help resources on completing the requested actions. They end with a final tip. There is no formal sign-off or signature because this email is generated by a department on a campus-wide scale instead of a true personal correspondence.

✨Memos

Memos are the older version of an email in many ways. But they stay as a core form of business, professional, and technical writing because we can contain a lot of information in a skip, scan, skim package that holds formality and is easy to reference. The main reason is that memos are written in word processors (so you draft them in Docs, Word, whatever) and then send them out as attachments for folks to open, save, archive, and organize in their own folders. They are also designed for printing and maybe posting in the copy room or whatever.

When you draft your memo in your blank document, include the following features:

• List the names of the people receiving the information–usually, a memo is going to a range of people so you can list them alphabetically or by rank– and typically include everyone’s job titles unless your company specifies otherwise. The memo might also be sent to a whole department, so you would list the department name.
• After all the attention (the to and from stuff), include the date. Consider writing out the whole month instead of a numeral format just to account for multicultural companies and readers and to reduce potential confusion overall.
• Everything is similar to an email… The subject line is the specific topic.  Ensure people can scan the header and know what the memo is about. The content should start with the orientation and purpose, deliver however many paragraphs of information you have, and close with action items and a summary.

Memos often use headings, tables, and visuals–all the design stuff of any other dense technical document.

As an example, every semester I receive a “Faculty and Staff Memo” from the office of the registrar with the purpose statement  “the Office of the Registrar would like to remind you of some important policies and deadlines.” The 5 ish page memo goes on to list Significant changes, key policies, a table for registration related timelines, information on dropping courses, and more. They use a lot of color, bolding, and bullet points under each heading so it is easy to scan for the information I need. It is a helpful reference that I save to my desktop for easy access… often actually faster and easier than searching their website or trying to google the information.

Saving the MEMO document is also way faster and more versatile to open than saving the email. It is a better experience for that CAMP site (context, audience, message, product).

✨Letters

These are considered the most FORMAL and respectful professional, personal correspondence and are used in really specific situations. Usually, they are for external audiences but can also be used for internal documents when respect and formality are at peak levels.

So I’ve needed to write:

• cover letters for job applications (this practice is more common at higher-level roles and various by industry)
• for job offers to the interns I hired (and you should expect to receive an offer letter for most careers you are preparing for),
• and–as a really niche situation–with research submissions as a grad student and faculty member. So, I needed to submit a revision letter, for example, to the journal publication editor explaining how I addressed the reviewers’ requested changes.

That last situation is less common to most of you, but for those interested and considering graduate school, that is the environment where I’ve written the most letters.

Use or look for the official company letterhead (if you received a letter). It usually has their logo and all the attention information…their full address and your name and address. If anything looks suspicious there–just note it and consider double-checking through a trusted channel with that company, especially if they are requesting sensitive information, indicating you need to pay them, or telling you to go to any websites to complete actions.  Subject lines are optional in a letter, but it can be helpful to write one. Then the letter includes a salutation..the greeting… usually followed by a colon (:) instead of a comma (,). Those are the two vertical dots on the shit+ semicolon key. But that isn’t necessarily a hard rule that is always followed. Then, give them the content, the same basic structure of orientation, purpose, details, and summary.  If you have a second page, restate the subject and date in the header information. End with a signature block… (Sincerely or whatever) and your name and title… and leave space for the e-signature or your physical signature between your close and your name.

We have four big types of letters in the professional space:

1. Letters for documents (a letter of transmittal for a formal report or a cover letter for a job application) that highlight the content of a larger document or packet. These are the ones I’ve personally needed to write the most often.
2. Inquiry letters to get information about goods, services, and opportunities
3. Claim letters are basically polite and formal complaints over goods and services, which are responded to with adjustment letters.
4. And offer letters for job candidates that detail the salary, start date, benefits, next steps, and any other details of a new job. Offer letters can double as a contract, too. The candidate, hiring managers, and supervisors are signing the agreement…So if you negotiate for anything when getting a job–from moving expenses to a specific salary to a delayed start date–you need to ensure it makes it into the offer letter before you sign anything.

Letters are often sent electronically—through email, direct share, or application portals–and printed and mailed, too. If you have to write one, be as formal, polite, respectful, and professional as possible.

• Instead of: I want this job because I will be good at it and have the qualifications you listed.
• You might say: I’m eager to contribute my skills and perspective to this position, as my experiences align with the requirements outlined in your job posting.

This is where our AI interns can be really helpful in revising the tone, grammar, and spelling for ideas on how to turn your casual language into more formal versions. But the interns can also create overly complicated prose–so the choice and arrangement of words–that don’t sound natural or make sense, too. Use them as a starting point for more formal writing and then edit to read in your voice and make sense for you.

That was emails, memos, and letters. We have one more subsection on the common genres for project management and general workplace documents. Then, we will take a break and end with Section 3 on Specialized Projects and Workplace documents.

2.4 Progress Reports

As you continue through your project, you may need to update people on the progress. Your progress report might show up as an email sent to your specific boss more regularly, a memo sent to the larger team on a longer timeline, or as a standalone report sent out to the clients or formal stakeholders.

✨So no matter how you are delivering your progress report, there are four big things you need to keep in mind.

1. Introduce the scope and purpose. Provide a refresher or a background on a project and where this progress report exists in the overarching timeline. Is this the initial progress report? How long has it been since the last one, and how many months of work will this update cover? That sort of context. If it is a quick progress status update to your supervisor as an email, that might just be one sentence because they’re probably also super in the loop with what you’re working on. If it is a standalone report to people who are investing millions of dollars into this project, your introduction, your scope, and your summary sections are probably going to be a couple of pages as the scope is probably a lot bigger, and the readers need to catch up on the details. That is why they are reading your report… to check back in on all the details.
2. Then, you always need to make sure that you outline the status of the work and give them the progress. Again, it might be a couple of bullet points if it’s just going to your teammates or your supervisor, or it might need to be much more in-depth, broken down with graphs and a calendar. You might make a Gantt chart, which is basically a timeframe of the project displayed out with typically horizontal bars. Usually, the x-axis is the weeks, and the y-axis reflects the tasks or stages. They are great at visualizing how tasks overlap, the sequence dependencies, and a big-picture timeline view. A Gantt Chart can be annoying to make from scratch with the tools inside Word and Docs, so consider exporting it from a project management tool that has a template and schedule builder for you. Jira is pretty big across technical spaces, but there are loads on the market with free plans. Microsoft has a light project manager– Planner and Projects–to play with as students.
3. You also need to talk about the budget since it costs time and money to do these projects. So make sure you give them the money situation and how many hours you put into it since hours translate to billing in the budget. If you need more resources or any other significant update, here is the time to share.
4. And then you’ll just end with any conclusions. If you have requests that you need to make the project work moving forward or other recommendations, you can put that at the end.

The heart of a progress report is the reporting of progress. Reporting progress means discussing the work completed with any notable outcomes, the work under review, and the remaining work. Compare the work milestones to the initial plan or proposed timeline to show how things develop.

✨We have a couple of options for how you want to structure that.

Okay, so you could do it more of a time-based way where you kind of say, okay, over the last month, we completed the XYZ task. Next month, we’re going to complete 123 tasks. Think of it more like a calendar with goals. The other option is task-based, where you say task one happened last month and took this long. Here’s what we did. Okay, task two, you know, got started a couple of weeks ago. Here’s what we are doing. Think of this as more of a to-do list. Both include details on the actions taken and the timeframe. The difference is that time-based emphasizes the time period, and task-based emphasizes the stages.

Time-based structures can be really helpful if a project has a hard timeline set and delivery date. Things that take place over a longer period, a six-month long project, a year-long project, or a multi-year project might lend themselves better to a time-based approach because you work in these big chunks. We’d be like, okay, over the first quarter, here’s everything we did. Also, more agile projects–the ones that focus on continuous development and iterating, even though they might not have a hard timeline–can be easily shown in a time-based structure because you discuss what was accomplished during a particular Sprint or window of time.

Shorter projects might work better for task-based projects, or if there are a lot of tasks associated with them, they must be done in a clear sequence. So, if your project can be finished in 8 weeks, it probably isn’t as useful to talk about last week vs. this week. Instead, it is more direct to discuss the tasks: we completed this test, this task, and we hit a roadblock, but we’re getting started on this task. I find that more traditional or waterfall-managed projects are easily reported in a task-based structure as each stage—and the associated tasks in that stage– provide the organization.

You can and will use both–sometimes even in the same report. You might want to introduce the progress section with a big-picture Task-based structure to refresh readers on all the steps involved. But then, we need to explain some time-based elements as subheadings or for detailed points. Or the other way around. It depends on the time period, your stakeholders, and the type of tasks you’re doing.

I recommend taking a longer break here as we end section 2. If you can come back another day, do that! It is good for breaking up information in your brain. Start Section 3 of the lecture on the more specialized project management genres when ready.

Section 3: Specialized Project Management

We are starting the final section of the lecture. These documents are less general for all careers and situations and more specialized to circumstances and roles inside technical fields.

3.1 Incident Reports

For when shit goes down. So, there are other names for incident reports and accident reports, I suppose. They describe any event that needs a record..like a paper trail–usually for liability, safety, or reporting standards. The common reasons are because of an accident, or if you have damaged equipment, whether you broke it or you just came in that morning and it was broken, or for trauma at work like an HR violation, sexual harassment, discrimination–any unsafe, hostile, or toxic working environments. If anything like that happens to you, find your company’s or your organization’s incident report to ensure it gets documented clearly.

Most places have established forms and reporting procedures because they’re so important. RED FLAG if your company doesn’t🚩🚩🚩

For almost any business, you will need to detail–and write as exactly as possible–a few pieces of information.

✨First, it’s things like the date and location. So, usually, they need to know where at work (field site, the breakroom, the client’s office). Check the time as soon as an incident happens, if you can, and get the minute—or at least the nearest quarter hour.

✨Second, you’ll probably have to do things like the parties involved. It could be people, but it could also just be like equipment.

✨Third, you’ll need to think about the outcome. So basically, just making sure you have a really good, clear, rich description of what went down. Especially if something is damaged or someone was hurt, you’ll need to explain what you or they were doing when it broke, any noises the equipment was making, and external factors–did a dust storm kick up at the site or did an alarm go off, elements of the environment–was it too dark, etc– try to get everything you can.

Incident reports guide any investigations, identify patterns of concern, and prevent future issues. For example, if you were following the steps in the SOP when the event occurred,  then that would indicate that they need to revise the user manual or adjust the workstation setup. And then, if you did get hurt, workers’ compensation and HR staff usually require the incident report to be filed within a short time period as the official record.

As an example from UCCS. So they start with who is the Person Filing with space for the name, role, and email address. Then they ask where it happened? So they want the building on campus and room number or area–like the grilling pit in Alpine village or whatever. Next form fields are for the date and time, which they request a specific month, day, year and 12-hour clock format, so the AM/PM structure. After that we fill in the parties involved with contact information, if known. That section is not a required section because your incident might not have other parties..like if you caught the grill on fire or just slipped in the shower or something. Then they get into the details. Select what type of incident from things like injury to fire alarms to theft and damage.

Your company might have one report specifically for sexual harassment and discrimination and a whole different report just for equipment. Or it could be one report like this, where we have things like property damage and the same list of options as a personal injury. It just depends on your company.

And then, yeah, you can just put like who was contacted– police, counseling, ambulance, etc. And then we have a description at the bottom. So you could also write this out in more of a letter form as well. That open box description is where you can add all those details about the environment, steps, and external context of the incident.

All right, those are incident reports. Let’s turn to happier situations.

3.2 Briefs

A brief refers to a short summary of a longer project idea. Usually, we’ll send briefs to get a stakeholder or a team on board with a plan. You can almost think of it as like a pre-proposal because you still have to put work and effort into it, but a lot less time than doing a full proposal.

✨Creative Brief

One place we see and use them a lot is in creative projects. In PR, social media, video production, or any sort of creative project, we start with a brief. You want to ensure the clients are on board with the vision, goals, and elements before you put in all this work, creating assets and such.

Start with the project description and the objectives. The objectives should be SMART–specific, measurable, achievable, realistic, and time-based to ensure you guide the project forward. For creative briefs, we always write out the audience and persona we target with the event, campaign, video, etc. So we practice that rhetorical situation, coming up with our audience statements–who they are, what they want, why they want it. For example, the project is an eBook launch to drive 4,500 downloads and generate new leads. The audience is entrepreneurs aged 25-55, college-educated and interested in outside-of-the-box ideas for business growth. So we know the age range and some of their education. What are they interested in? Generally, what is their deal? Then we go into the message and tone for how we want to communicate with the audience.

Write out the adjectives for the tone and provide an example so that everybody–clients and your team working on copy and graphic assets– knows what the vibe will be. You also state the types of assets and deliverables needed with any inspiration, branding, mood boards, or style notes. You might put things like approval processes, the roles of the team, the budget, and the timeline. Then, note the final distribution channels.

You may have heard of a “brief” on competition TV shows too–like Project Runway gives the contestants a brief–which is all the details of the vibe, deliverables, and expectations to guide their creative process along the episode theme. So a creative brief is just all the things, right, your creative team needs to know to start working on that project and the stakeholders need to approve the project.

You can turn your creative brief into your progress reports, too. You already have all this great information that you can rewrite and turn into a summary section. Then you have your different tasks because you broke down all the deliverables and product details.

✨Technical Brief

We also have technical briefs that function similarly to a creative brief but are specialized for describing product prototypes, process plans, and development scenarios. A technical brief is a concise document that summarizes complex technical information for decision-makers, project managers, engineers, or other stakeholders who need to understand the key points without getting bogged down in excessive detail. It’s designed to bridge the gap between subject matter experts and everyone else.

Technical briefs are more common in certain fields–a lot of government contract areas–and technical development teams. The government tends to favor and release technical briefs because they release information to the public as stakeholders. The public funds them. They are helpful resources in any complicated product or code development for the same reason creative briefs are helpful to those teams: they explain everything we need in more relatable, short ways to get everyone on the same page quickly.

There isn’t a true template or clear expectation for what goes in your brief because it is so topic and field-specific. But generally, your brief will follow the outcomes of any other project management genre to describe what is going on:

• Introduction: Provides context and background information on the topic.
• Technical Discussion: Presents the technical details of the project, product, or research.
• Actions and Recommendations: Summarize the key findings, processes, and outcomes and provide recommendations for action.
• References: Lists any sources cited in the technical brief or related resources.

So basically, a technical brief is too long; I didn’t read or didn’t need to know THAT much information about your technical situation. It could be a discussion of a new manufacturing process for the executives, the architecture of your software application for investors or a quick roadmap for the devs, or an explanation of a financial model for a client. As an example, the National Park Service has a library of technical briefs on things like “Archeology and Civic Engagement” that basically explains social capital and suggests how archeologists can contribute to civic engagement.

✨Research Brief

The last type is a research brief, which is used to inform less technical audiences about key research, such as the CDC on health research, or to explain the background of your project to a stakeholder. I see the technical brief more as explaining a concept, a tool, a function, or something. The research brief is more explicitly like, “We did research, we did this study, and here are two pages explaining the study to you.”

You need to talk about the problem and purpose of the study, your procedures and data collection, and the key takeaways you found. In many ways, we can argue that a Research Poster is a form of a research brief…just printed on giant paper and hung in a conference hall instead of a handout document.

For example, a research brief on an “equity measurement challenge in a Statewide Scale-up of Discipline Reform” study begins with four bullet points explaining the Problem and Purpose. Then the author provides how they measured and monitored discipline disproportionality with bullet points and a table of data. The second page has the What We Found heading with charts and graphs. They end with a Key Takeaways section that has bullet points for research conclusions and then practice and policy implications. The collaborating universities and author information is in the footer.

I’m sure the full report was 30+ pages long. It’s a pretty standard research manuscript length. But they condensed it into just these two pages for the brief. They use some really nice colors, layout, and design to make a really hard-to-read full research paper into something the general audience and policymakers working on equity challenges could understand and do something with. Usually, research briefs are created AFTER the project is complete to share the results. Creative and technical briefs can be made at the start of the project and referenced throughout the work.

Conclusion

All that is left is a big-picture summary. Please look over your notes as we review the big actions and fill in any missing information.

We started by explaining why documenting our work in a project is important, including some key scenarios and specific reasons. We need documents for a paper trail to:

• capture the action happening
• summarize a situation
• request like information or actions that need to happen
• document like incidences
• or give progress and status updates

Then we discussed some ethics in project management, so you should have TWO big ethical elements about the bad news we tend to deliver when managing a project.

We then discussed the genres and expectations for emails, memos, letters, progress reports, incident reports, creative briefs, technical briefs, and research briefs.

Alright. Use your note-taking and project guides to apply these concepts to our projects. Return to these materials whenever you need to reference an aspect.

Thanks, associates,

Vibes.

Credits and Sourcing

Information and content in this lecture are derived from the following sources and the creator–my–personal experiences in education, technical environments, and professional roles. This content is licensed under the Creative Commons Attribution-NonCommercial-Share Alike, so you are free and encouraged to distribute and remix any part in any new medium for your goals. Please ensure your creations are available under the same license to keep the information spreading.

Practical Strategies for Technical Communication. Copyright 2019 by Mike Markel and Stuart A. Selber in Published by Bedford St. Martin’s.

Technical Writing Essentials Copyright © 2019 by Suzan Last is licensed under a Creative Commons Attribution