Three Don’ts When Taking Part in a Peer Review

I have participated in many peer reviews, be it for gap analysis, requirements, or proposals.  I have seen a few them go awry for numerous reasons.  Here are a few tips that I picked up while attending these peer reviews:

1. Leave the egos at home – There was one gap analysis that was four of us in one room for three months hashing out the best and worst of three complex financial management systems.  It was already a tedious and stressful job trying to figure out which features to place in the new system.  The process became ten times as hard because of two individuals who though his system was the best, and that he was the only expert.  Honestly, leave the egos at home.  When you are thinking about how great you are or the system you represent, you are not being open enough to take in other people’s suggestions, which can be detrimental to designing a new system.

2. Don’t continuously interrupt - Sometimes allowing people to ask questions during someone introducing a topic is the worst thing to do.  You usually get sidetracked with other conversations that you really don’t address the discussed topic.  I found it best to allow someone to say his/her part, and then ask any questions you have afterwards.  It gives them time to touch on everything that he/she wants to talk about, and you are able to have useful questions at the end.

3.  Don’t belittle others’ ideas or questions - I’ve been around some people who will smirk or say some sarcastic comment if a person says something that they deem “stupid.” Peer reviews are usually times to brainstorm ideas.  Therefore, this is one of the only times that I will agree that no question (or idea) is stupid.

Research Before Starting Any Project

Before starting any project or document, there is something that you must do. RESEARCH! I can’t stress that enough. There have been all kinds of projects that I have been on, and the one mistake that they usually make is not taking the time to research. It’s something that time should be allocated for during the project planning process. Reading the client’s documentation, interviewing them, and analyzing external resources, you will have a better understanding of the issues that your team and you are trying to solve.

1. Research the Client’s Documentation - When a client hires me to write a proposal, the first thing I do is reading the RFP or proposal guidelines carefully, and I create a requirements matrix. Tip: Placing a proposal requirements matrix at the front of your proposal showing that you have covered all the points that they had already creates a good first impression. After doing that, I begin trying to understand the client’s problem. There have been so many times where companies only rely only on their past performance and their name. Yes, past performance is important, but you have to also consider that every problem is unique. Even if something you have done in the past covers the majority of what they want, it usually won’t satisfy the problem 100%.  Research their reports, system documentation, and anything you can get your hands on.

2. Interview Your Clients – Interviewing is also very important. You can do this for gathering requirements. Understanding what clients do every day, and what they want is key to developing a product or service that will better help them. It’s a great way to also build a rapport with them. Whenever you take the time to speak to clients, you are showing them that you are fully invested in helping them do their jobs better.

The best way to do this is create open-ended interview questions that you can further build from. A child learns by asking why after why questions. You have to do the same. Don’t be afraid to ask anything you need to know, even if you feel that it’s a dumb question. This is the only time that I will say that there is no such thing as a stupid question.

3. Look at External Resources - I’ve written many responses to government RFPs, so I usually read what reports the Government Accountability Office (GAO) and the agency’s Inspector General has written. These are reports created after months of analysis, so they are extremely useful. There are also reports that non-profit organizations looking for grants can view that are similar to these. Maybe think-tanks, research organizations, and many others have probably done some type of research.

My internship as a Research Assistant at a think tank when I got out of college taught me that. In order to create full-depth analysis reports, we had to research for months. It’s one of the reasons that think tanks are considered experts in their field. Definitely learn to do the same.

Photo Detail: Problem and Solution – Magnifying Glass, originally uploaded by iQoncept. 7JEQ7FG8JA22

Read Books to Become a Good Writer

The only way to become a good Writer is to be a great Reader. Reading a book doesn’t just take you away from your surroundings, but it also helps you learn new techniques from the authors that wrote the stories. I am currently reading two books: The Lovely Bones and The Sugar Queen. I am quickly re-learning the art of dialogue and how to describe a scene so that readers feel like they are right there with you.

This isn’t just for creative fiction and non-fiction, you can also use it for technical writing and blogging. Reading allows you to find ways to describe things in a way that anyone can understand, and it helps in understanding the level of detail that you have to have in your pieces of work.

It’s true what they say.  Reading is Fundamental.

Photo Detail: she likes to read, originally uploaded by dinerdog.

How to Mix the Old With the New When Writing a Proposal

I have read many technical documents that are collages of past documentation. The worst is when it’s a proposal. Why? Proposals are vehicles for companies to get more business. If the proposal looks like a bad cut+paste job of past proposals, it could cost you the contract. I have seen proposals where writers even forgot to omit the last organization’s name, and the paragraphs had dissimilar phrases. Many businesses commit these mistakes, even Fortune 500 companies.

Here are three easy steps that can help you avoid such errors:

1. After carefully reading the proposal instructions, make sure to have a brainstorming session to discuss what the RFP is asking - One of the last companies that I worked for needed my assistance in writing the biggest proposal of their company’s history. I remember the first “brainstorming” session I had with them. Instead of focusing on the agency’s needs and the Request for Proposal (RFP) requirements, they were more focused on how they could use past proposals and technical documentation. That meant a lot of “cut and pasting”-a recipe for disaster! As I quietly took notes, I asked, “The proposal said they wanted innovative ideas they had not heard before. What are you doing to address this subject?” A pause. I asked a few more questions, and then it dawned on me. They overlooked many of the key components that the agency emphasized in the RFP. Pretend you are an outsider (if you are unable to do this, have someone from another department assist you). Read the entire RFP, or a similar document, in detail. While you’re reading it, write down the requirements of the RFP. Then come up with questions that you would want answered if you were the organization.

2. Do research on the organization - Identify past issues and criticisms on the contract they need assistance with. Another company needed my assistance in writing a proposal in response to a RFP. I read the government agency’s RFP and did research on the type of technology they needed built. I found reports from the Inspector General and even the General Accountability Office (GAO). When I spoke to the Proposal Manager, I asked him if he read those reports that could assist us in tailoring the proposal to fit their needs. He looked perplexed. “GAO has a report on the agency?” Do plenty of research. Check newspapers, government agencies’ sites, and the organization’s site. I guarantee that many times they have been saying for awhile that they need assistance with this.

3. Edit at least TWICE if you will be using old documentation in the proposal - After the proposal is complete, thoroughly edit the document at least twice to ensure that you do not have any past organizations’ names, the flow is superfluous, and you have satisfied all of the RFP’s requirements. Many people skip on this part, yet it is probably the most important in guaranteeing that a proposal won’t be kicked back or thrown away. If you can afford it, have someone outside the company edit the document for you. It is always better to have a fresh pair of eyes edit a document to eliminate bias. If you remember these three easy steps, you will avoid those issues when mixing past documentation into a new proposal. You can apply these three principles to any document (i.e. design document, white paper, grant). Laziness is frowned upon-just be sneaky and use these tips.

Photo description: generations., originally uploaded by LittleFear.