A directory of resources inthe field of technical communication.

Polastre, Shevonne

14 found.

About this Site | Advanced Search | Localization | Site Maps
 

 

1.
#38450

Five Industry Best Practices to Improve Your Proposals and Technical Documents

Industry best practices are business processes that assist companies, government agencies, and non-profit organizations in maintaining the highest level of quality in the products or services that they are offering. A lot of it might seem like common sense, but if you saw some of the things that I have seen in the different projects I’ve been on, you’d realize that sometimes you can just rely on that. Here are five industry best practices that you should adopt, regardless of the type of organization that you are running.

Polastre, Shevonne. Chicwriter (2011). Articles>Documentation>Proposals>Standards

2.
#38448

Getting to Know Your Clients is Always a Plus

As a Consultant, you have to be flexible to deal with change and the different personalities that come with the job. Some clients let you take control and only check in once in awhile, and others have to be part of every step of the way. It’s something that you can’t take personally because you never know what the reasons are for the clients reason to behave in the way that they do. The only way you are going to find success is by smiling and going with the flow.

Polastre, Shevonne. Chicwriter (2009). Careers>Consulting>Collaboration

3.
#38449

How I Became a Technical Writer

I have gotten a lot of questions wondering how I became a Technical Writer. I decided to create this blog post to answer everyone all-at-once. Also, for future people who are trying to get into technical writing and want to know how.

Polastre, Shevonne. Chicwriter (2011). Careers>Writing>Technical Writing>Case Studies

4.
#38451

Organization is Key When Freelancing

Organization is one of the most important parts of being a freelancer. If you do not have some sort of system, then you will never be able to be successful in your line of work. Unlike a company, you do not have different people handling different tidbits that makes the entire company run smoothly. You are the CEO, Marketing Director, Technical Guru, and Financial Officer. Therefore, you need to be on top of things to ensure that everything goes according to how you envisioned.

Polastre, Shevonne. Chicwriter (2009). Careers>Consulting>Freelance>Advice

5.
#38438

Proposal Writing Blog Series, Day 1: Writing the Cover Letter

The first thing the organization will see is the Cover Letter, or Letter of Transmittal. As with the Executive Summary, which I will go into more detail when we reach that section, I recommend working on the cover letter after you have finished the body of the proposal. The reason being that the Executive Summary summarizes the main points of each section, and the cover letter is a mini-Executive Summary. It should only be one page, and written so you instantly grab the reader’s attention. Imagine how many proposal he/she reads during the RFP process.

Polastre, Shevonne. Chicwriter (2010). Articles>Grants>Proposals

6.
#38439

Proposal Writing Blog Series, Day 2: Executive 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.

Polastre, Shevonne. Chicwriter (2010). Articles>Grants>Proposals

7.
#38440

Proposal Writing Blog Series, Day 3: 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.

Polastre, Shevonne. Chicwriter (2010). Articles>Grants>Proposals

8.
#38441

Proposal Writing Blog Series, Day 4: Technical Solution

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.

Polastre, Shevonne. Chicwriter (2010). Articles>Grants>Proposals

9.
#38442

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

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. Like resumes, having a Past Performance template will help in having uniformity in the proposal, and make it easier to add the information.

Polastre, Shevonne. Chicwriter (2010). Articles>Grants>Proposals

10.
#38444

Requirements Gathering and Analysis: Assumptions, Dependencies, and Constraints

In the world of requirements, even if you do a great job gathering and analyzing requirements, there will still be a couple of gray areas. There may be a couple of reasons for this. The main reason is that this is a new system that you are developing to replace an old one (or a system of workflows), therefore, there will be some unknowns. When writing requirement documentation, you want to ensure that you capture those and present them to your client. These are known as assumptions, dependencies, and constraints.

Polastre, Shevonne. Chicwriter (2010). Articles>Documentation>Requirements>Technical Writing

11.
#38445

Requirements Gathering and Analysis: Functional Requirements

Functional requirements detail the behavior of the intended system. This is from the workflow to the end-user interface. You want to ensure that each functional requirement that you capture is just that.

Polastre, Shevonne. Chicwriter (2010). Articles>Documentation>Requirements>Functional Specifications

12.
#38446

Requirements Gathering and Analysis: Non-Functional Requirements

Non-functional requirements are the requirements that stakeholders and users haven’t thought of, but you have to because without them, the system will fail. If you don’t collect non-functional requirements, then you will not be creating a system that behaves in the way the users need it to.

Polastre, Shevonne. Chicwriter (2010). Articles>Documentation>Requirements>Functional Specifications

13.
#38447

Requirements Gathering and Analysis: Use Cases

When you are capturing functional requirements, you usually create use cases. There are two parts to a use case: 1. Use case diagram and 2. Writing part. Use cases are used to identify and illustrate the different parts of a process.

Polastre, Shevonne. Chicwriter (2010). Articles>Documentation>Requirements>User Centered Design

14.
#38443

Requirements Gathering and Analysis: User Requirements

The easiest way to explain user requirements is to say that the these are the requirements that detail how the end-user expects the system to behave. Even though this sounds easy, it is probably the hardest requirements to collect. The reason is that you are relying on users to explain their wants and needs. As you probably already know, a person telling another what they want is not the easiest thing to do.

Polastre, Shevonne. Chicwriter (2010). Articles>Writing>Requirements>Technical Writing

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon