This article describes how to write an abstract for business, proposals, grant, conference and academic papers.
Why write an abstract?
It depends. If your business proposal will be read by executives or those in the decision making process, then you want to distill the salient points of your proposed solution into a short, one or two page, document.
They’re unlikely to read any more than this, except for the cost section.
Likewise, if you plan to write an academic or research document, then you need to create a document that will be searchable – and indexable – by search engines with introductory material that appears in the search results.
This means you could be writing for two different audiences: search engines, such as Google, and humans. While both of these require different approaches, there is some overlap. Let’s look at where to start.
One approach is to structure your abstract under the following headings:
- Problem statement
Remember, the person reading your proposal has a stack on her table. Or, as is the case these days, will have them as PDF attachments in her email. Why am I saying this?
While you may have spent weeks working on a bid, a research piece, or an academic study, the person reviewing your document has many, many others to assess. You’re one of many. With this in mind, you need to capture this person’s attention from the opening sentence.
Why is this contract award so important to you?
Is it only about money?
You need to demonstrate in the opening paragraph your enthusiasm for this project in ways that capture’s the reader’s attention. It doesn’t have to be anything outlandish but it does have to be compelling. When you write, imagine yourself in the other person’s shoes.
Does the opening paragraph spark their curiosity, make them want to read more, make them skip to other sections to learn in greater detail what’s involved. Remember they don’t have to read your proposal – they can stop any time. So, it better be interesting, right?
Q: why do you care about the problem and the results?
One way to approach this is to highlight one specific point in the bid, one of the most difficult areas you plan to tackle, and then discuss the impact your proposed solution will have if it’s successful.
This gives the reader an insight into your values but more important it shifts the focus from the abstract to something more tangible.
In the next section, ask yourself:
What problem am I trying to solve?
Again, be specific and think of the solution in human terms. For example, if you’re developing a CRM system, don’t talk about the specifications; instead focus on specific cost savings – something they can understand in real terms – and how this will help people on the floor.
Because the people you’re proposing to may be the same people who will use it.
What is the scope?
Avoid mentioning what’s outside of the scope. Focus on what you plan to deliver. Then be as specific as possible.
If your abstract relates to research, for example, academic research on a new technology, then discuss the results and give examples of different types of findings. Again, put them in context and highlight the findings likely to be of most interest to the readers.
If possible, compare your solution’s performance or ability against the competition in measureable terms. What does this mean? For example, demonstrate how it can process X number of transactions in a minute, for example, an improvement over the existing system by three hundred percent. You have to back this statement up, of course.
Your goal is to be specific and share something that the reader can take away and compare, and also share with other colleagues. Be specific, use numbers and percentages. Refer to later sections in the document.
The conclusion brings the abstract full circle. If you’ve written the other sections correctly, there should be no need to expand on any points here. Instead, see this as a bridge into the main document. If necessary, stress one of the main points but don’t over-do it. They should have a grasp of your offering by now. Use the conclusion to dovetail the main points and lead them into the first chapter.
Abstract Writing Tips
- An abstract must be self-contained. Write it as a standalone document. Imagine that if it was separated from the main document, would it still make sense? If so, you’re on the right track.
- Don’t make the reader to have to work to understand it. Don’t force them to search the rest of the document for the meaning of some obscure technical term you used.
- Keep it under two hundred and fifty words. If possible, keep it to one page. Two is fine, one better. Here’s an idea. Write four hundred words, reduce it to three hundred, then two hundred. See if you lose anything in the process?
- Ferret our filler words and phrases. Use direct language. Write in the present (and future) tense. Avoid using phrases that undermine your efforts, for example, weak words, such as could, maybe, likely, possible.
- Avoid jargon, TLAs (three letter acronyms), industry speak, and clichés. Do you like reading jargon? They’re the same.
This refers to the approach you took to solve the problem, or if you are proposing a solution, the technologies or systems you wish to recommend. The other point is how you propose to go about this. Will you be developing the solution by yourself, with a third party, in partnership with the agency? Have you done similar work before?
Look at this from the perspective of the agency awarding the contract. What do you need to offer to reduce their anxiety and give them the confidence that you’re solution is head and shoulders better than the competition?