Five Open Source or Free Applications to Use in Technical Writing

 

 

 

 

 

 

 

 

 

Technical writing can get pretty expensive. You have to have applications that will help you in writing technical documentation and proposals, creating flowcharts of all kinds, modifying and manipulating images, and the list keeps going. The applications, like Microsoft Office, Adobe Photoshop, and Visio, usually come with a hefty price. Wouldn’t it be great if you didn’t have to sacrifice the quality if your technical documentation and proposals without having to pay $500 for an application? I have found some open source or free alternatives to the expensive applications that you will need for technical writing. I have listed the five main ones here:

1. Office Suite

 

 

 

 

 

 

 

 

 

 

 

Everyone needs an office suite that allows you to write documents, spreadsheets, presentations, and more. This is regardless if you are in the technical writing field or not. People usually think of Microsoft Office when they want a word-processing software. NeoOffice and OpenOffice are great alternatives without the price. Like Microsoft Office, NeoOffice and OpenOffice have everything you need to write and develop documentation, spreadsheets, presentations, etc. I prefer NeoOffice, but it’s only for Mac. However, both applications can get the job done. The great thing about both is that there are tons of templates on their web sites. Furthermore, you are able to download the templates from the Microsoft site, and open them in both applications (I’ve done that a few times). One thing to remember is that people are still using the Microsoft extensions, like *.doc, *.xls, *.ppt. Therefore, you have to remember to convert your documentation into those extensions instead of the extensions used in NeoOffice and OpenOffice.

2. Creative Suite

 

 

 

 

Even though the graphic design is left for the graphic designers, Technical Writers usually need to have some knowledge on image editing and manipulation. Adobe is well known for their Creative Suite, which includes Photoshop and Illustrator.  The suite is extremely expensive. It is definitely worth it if you have the money, but if you don’t, then you can just keep on dreaming. If this sounds like you, then you should check out Aviary. Aviary is an online creative suite that allows you to do almost everything you could do using the Adobe Creative Suite. A great addition is if you use Mozilla Firefox or Google Chrome, Aviary has extensions that you can use to manipulate images that you find online. It also includes a screen capture application as well. If you want a more in-depth review of the Aviary online creative suite, then click here to check out what I wrote when I was writing for the awesome tech blog MakeTechEasier.

3. Project Planning

 

 

 

 

 

 

 

 

 

If you write project management documentation, then you know all about Work-Breakdown Structures (WBS) and Gantt charts. WBS and Gantt charts aid in planning how the project tasks will be broken down by time. It is something that needs to be done if you want to have a successful project. Without proper planning, a project will fail. Therefore, having a WBS and Gantt chart are useful because you have to think about how you will measure the success of the project during various phases. Also, you really consider the resources, which are usually actual people in roles, that you will need to ensure that the project tasks get accomplished. The usual application used to do this is Microsoft Project. I will have to admit that it’s probably one of Microsoft’s best applications out there. A great alternative is OpenProj that is very similar to Microsoft Project. You are able to easily create a WBS and Gantt chart that have milestones, resources, and attached to a time schedule. Additionally, you can specify dependencies. These means that if this task doesn’t get done first, then another task can’t be completed. I was very impressed with OpenProj, and it’s one of the applications I have on this computer.

4. Flowchart Creation

 

 

 

 

 

 

 

 

In many kinds of documents, like project plans, system architecture documents, and proposals, you always include flowcharts of all kinds. These flowcharts can be design flows, organizational charts, or workflows. It is a great way to show readers a complicated process in a simplified way. I usually use Microsoft Visio to create these. However, if you don’t have the money to spend on the application, then OpenOffice and NeoOffice both have Visio-like applications in their office suites. It doesn’t have templates in the application that you can use to quickly start your flowchart, which is something Visio has. However, if you go on their site, there are some templates that you can download, so you can use it to create your own flowcharts. There is a new service, Flowchart.com, that is currently invitation only, and it seems promising. However, I still don’t know the details, but I’ll keep a lookout for it.

5. Desktop Publishing

 

 

 

 

 

 

 

 

Technical Writers usually work in different areas. One day, you will see them writing a design document; the other day, they are working on a brochure. Therefore, a desktop-publishing software is something that every Technical Writer should have handy. There are some great desktop publishers out there, but they come with a hefty price. If you are starting out, and can’t afford to pay for one of them, then Scribus is an alternative you should consider. Scribus is an open source desktop publisher that allows you to create all kinds of publications. For instance, you can create publications like newsletters, brochures, postcards, etc. It doesn’t have any templates, so you kind of need to know what you are doing.  However, it has all the functionalities that you need to create a successful publication.

BONUS: Document Collaboration

 

 

 

 

 

 

 

 

 

 

 

Document collaboration is very important in technical writing. You are usually writing documentation that needs others input, or you are working in a team that is working on different pieces of a huge document. Therefore, you want to use an application that allows you to work together when writing and editing various documents. If it has version control and a mistake is made, then you can quickly revert back to an older version if an error was made. Google Docs is is my favorite way to collaborate with others when creating documents. If you haven’t checked it out, Google Docs allows you to chat with others while creating and modifying documents and spreadsheets. Additionally, it allows everyone to see the changes almost instantaneously, which is a huge plus. There is also version control in Google Docs. If you make a mistake, then you can revert back to an older version. Google Docs is a great alternative to Microsoft Office.

What are some of your favorite open source or free alternatives to popular but expensive applications?

 

 

Proposal Writing Blog Series, Day 5: Cost and Past Performance

This is part of a five-day blog series on how to write a winning proposal. It will go discuss actually writing the proposal. If you want to get more in-depth information, examples, and what to do before the proposal, check out my “How to Write a Winning Proposal” handbook.

Cost Section

During the Reviewing the RFP Process section, I mentioned that usually the RFP has a Section B, which details the way the organization wants the cost information to be shown. There are times where they just want you to copy and paste your cost schedule. Other times, they want your cost broken down by a timeline that they specify, or they want you to.

Past Performance

Like resumes, having a Past Performance template will help in having uniformity in the proposal, and make it easier to add the information. Usually, an organization wants the following information to be covered in a past performance:

• Company/Division Name
• Period of Performance
• Title
• Contracting Agency
• Point of Contact
• Contracting Number
• Type of Contract
• Task Requirements
• Level of Effort (Labor Hours)
• Total Cost of Contract $ Value
• Original Completion Date
• Current Completion Date
• Program Director/Manager

In the majority of the RFPs I have seen, they usually will tell you what information they want in a past performance, and how many of them they want in the proposal.

However, if they don’t specify, ensure that you have at least three past performances where the work was of similar scope and size. The Past Performance section is usually in the body of the proposal. However, if the organization doesn’t want it to be part of it, you can usually place it as an appendix.

End of Blog Series

We have come to the end of the Proposal Writing Blog Series:

• Proposal Writing Blog Series, Day 1: Writing the Cover Letter
• Proposal Writing Blog Series, Day 2: Executive Summary
• Proposal Writing Blog Series, Day 3: Management Approach
• Proposal Writing Blog Series, Day 4: Technical Solution
• Proposal Writing Blog Series, Day 5: Cost and Past Performance

I hope that you were able to learn a thing or two. Please check out the handbook that is filled with examples and more tips.

Proposal Writing Blog Series, Day 4: Technical Solution

This is part of a five-day blog series on how to write a winning proposal. It will go discuss actually writing the proposal. If you want to get more in-depth information, examples, and what to do before the proposal, check out my “How to Write a Winning Proposal” handbook.

You have written the Management Approach, and now it’s time to start talking about the actual solution.

You have done all the analysis, talked to SMEs, and really thought about the best way to solve the organization’s problem. It is now time to write it on paper. The Technical Solution section is a great way to do some preliminary thinking of the future solution that you will present to the organization. Even if you do not win the contract, you will have the foundation in developing a sound solution for future contracts. It is like a Concept of Operations (ConOps) document within a proposal. If you don’t know what a ConOps is. A ConOps is a useful technical document that can aid you in envisioning the perfect system to tackle a current issue that you are trying to solve. One thing that I will stress is that you should only offer one solution. You might want to offer an alternative as well. Don’t. It will make you look indecisive. You are the expert, so you tell the organization what it is they need.

Here are the main sections that a basic Technical Solution section usually has:

Introduction, Including Section Overview

A Technical Solution section has an introduction. As I stated before, the person reading the Past Performance section is usually not the same one reading the Technical Solution section. Therefore, you have to treat it as its own document, so a person could rip it out of the proposal and still understand what is going on. You should introduce your technical solution and briefly let the reader know how the section is organized.

Client’s Issue

Before you can discuss the proposed solution, you have to give stakeholders a bit of history of the issue you are trying to solve. The background and history of the current issue is very important because you want to show stakeholders that you fully understand how the issue evolved. It will also help you in designing a better solution.

If there is already a current solution in place, then you want to discuss that as well. You want to detail everything about the current solution and/or issue. When you are writing about the current issue, you want to ensure that you get everything down from your interviews with Subject-Matter Experts (SMEs and stakeholders. If you don’t fully understand what is currently going on, how can you find the proper solution?

Therefore, take your time in gathering everything you can about the current issue and its history.

Technical Solution Description

You have done your research, and you have written all you could about the current issue the organization is having. It’s now time to discuss how to solve the issue. You want to really take a week or longer to really come up with a solution that will be better than what is currently in place. You want to start off by giving a high-level overview of the future solution. Please make sure that you use “will” and not “shall.” The latter is requirements talk.

After giving a high-level overview, you want to go into the detail. You want to explain the reason you approached the issue the way that you did. This is kind of a bridge between the organization’s current issue and your solution. It gives the Technical Solution section a better flow.

You want to discuss any policies and constraints that the future solution will have. Additionally, you want to ensure stakeholders that you will adhere to any current and near-future policies that are in place. Also, that it is interoperable with other systems. Organizations and government agencies have realized the importance of being able to work alongside other groups, so if you can show that your future solution can do that, then stakeholders will be almost sold.

The impact that the future solution will have to the users, everyday operations, and other systems is the best way to conclude this sub-section. You want to reassure stakeholders that you have thought about this, and you will ensure that everything is smooth sailing, or as near to that as possible. This is something you should go into further in the next sub-section, Implementation Plan.

Implementation Plan

If the organization already has a solution in place, you want to discuss how you plan to phase that solution out, and implement yours. This includes processes, equipment, and strategies. Also, you want to discuss how you will measure the plan to ensure that it is highly effective. This could be done by having a schedule that includes milestones. If you reach the milestone before or on schedule, then you know that you are on the right track. You might be thinking, “I haven’t even gotten to the point of creating a full schedule.” The best way to handle this is by breaking things down by phases.

You can explain to the organization that you will work with them to create a more detailed implementation plan and schedule when you win the contract. However, you still should show the organization that you have put some thought as to how you will implement your solution.

One thing to remember is that even though you have done tons of research, interviewed SMEs and the client, and have applied your expertise, there are always going to be a few gaps. This is where assumptions come in. You will have to state the assumptions, why you made it, and why you weren’t able to find out that information before writing your proposal. If you have done your homework before you made the assumption, then usually the assumption has a likely chance that it is true.

You can now start writing the Executive Summary and Cover Letter.

Proposal Writing Blog Series, Day 3: Management Approach

This is part of a five-day blog series on how to write a winning proposal. It will go discuss actually writing the proposal. If you want to get more in-depth information, examples, and what to do before the proposal, check out my “How to Write a Winning Proposal” handbook.

We have discussed the Cover Letter and the Executive Summary. We now get to the first main section: The Management Approach. I’ve written project plans for various projects. The Management Approach is a similar concept. This is where you assure the organization that if you win the proposal, you have a plan in place that will monitor the project to ensure that it remains on time, within cost, and on task. The Management Approach usually contains the following areas:

• Program Management Approach
• Roles and Responsibilities
• Resumes
• Program Monitoring
• Program Schedule and Timeline
• Contract Deliverables
• Training

Program Management Approach

In this sub-section, you let the organization know the way that you will manage the project. There are several ways to do it:

• If the organization wants to be aware of everything occurring with the project, then you want to ensure them that you will be working closely with them to do this.
• If the organization is more hands off, then you want to let them know that you have experienced project managers who will be on top of things.
• If the organization wants to have more of a team environment, then you want to ensure them that you have the proper team to ensure the project is successful.

Roles and Responsibilities

The roles and responsibilities are important for the success of the program, so you have to show the organization that you have setup the best team to ensure that this happens. A great way to make it visually easier for the organization to see roles and responsibilities is by placing them in a tabular view. The table column headings you want to have are the following:

• Role – The job role title
• Description -A high-level summary of the user role
• Responsibilities -A bulleted list of the main responsibilities that role will perform.

Unless the RFP, or Statement of Work, wants the resumes as a separate section, you want to place the resumes in this sub-section.

Program Monitoring

In this sub-section, you discuss how you will monitor the project to resolve any issues that might come along. Some of the things that you might mention in this area are if you have any kind of review process in place. Also, will you be providing weekly and/or monthly progress reports to the organization?

Program Schedule and Timeline

An organization is not going to expect you to have a detailed project schedule on a proposal. However, you want to have some preliminary sketch of what is to be expected. You want to show the organization that you put some thought in the most effective schedule for the implementation of the solution.

Contract Deliverables

Documentation is very important in any project. Therefore, you want to tell the organization that you will have some documents that you will deliver to them. There are standard documents that you will more than likely have on your list. Here are a few:

• Project Management documents (e.g. project plan, training plan, configuration management plan, test plan, etc.)
• Risk and Action Items logs
• Progress Reports
• Quality Assurance Plan

Training

If users will need to be trained, then you want to write a brief summary about your intent on providing training, and a high-level description on how you plan on doing it. If you will be writing a separate training plan, please indicate that, and that you will be working alongside them in developing one.

Proposal Writing Blog Series, Day 2: Executive Summary

This is part of a five-day blog series on how to write a winning proposal. It will go discuss actually writing the proposal. If you want to get more in-depth information, examples, and what to do before the proposal, check out my “How to Write a Winning Proposal” handbook.

Yesterday, we discussed how to write the cover letter of a proposal. The Executive Summary should be treated like a miniature version of the proposal. It summarizes the high-level points in the Management Approach and Technical Solution. As I stated when discussing the cover letter, you should write it after you have finished the other pieces being that it is a summary.

As with the cover letter, the Executive Summary is the only other section that could be read by anyone. By knowing this, you have to keep the technical jargon to a minimum. Sum up the main points, even of the Technical Solution section, in a way that anyone can understand.

It also is a good area to start building that rapport with the organization, and setting the tone to make them feel and understand that they are the main focus.

A great way to organize the Executive Summary is first stating the problem. The Executive Summary is also a way to show the organization that you fully understand their problem. By doing this, they know that you have tailored a solution that works for them.

The second paragraph should discuss your solution and promise to ensure that the work is always at its highest quality. Please remember to keep the jargon to a minimum. Anyone, regardless of their knowledge of the intended subject matter, should be able to pick up the Executive Summary and understand what you are trying to say.

The third paragraph should discuss your organization and its management approach. Even though it’s discussing your company and its strategy, you should tailor it so it still makes the client feels that it’s all about them.