Create a Conference Proposal the Conference Wants and Accepts, Part 3: Write the Abstract -

You decided who your session is for: the people with the problems. You've got the outcomes. Now, it's time to write the abstract.

Conference proposals always have a short abstract. Some conferences, such as the Agile 20xx conferences, also have “Information for the Program Team.” You might think of that as the outline or more information about what you're proposing. I'll address that later.

This part is about the abstract.

Start Your Abstract

When you go to conferences, what makes you consider a session?

The speaker: You've heard this speaker before, or the speaker is famous in some way.
The title: Something about the title grabbed you, connected with you.
The abstract/short description: The first paragraph that explains your problems, and offers you some possibilities.

That abstract might make the difference between people who select your session and people who reject it.

Write for the Program Committee

You might think the people going to the conference are your audience. They are, and they are the second audience. Your first audience is the program committee. Your conference might have track chairs, reviewers, etc. I'm calling all of these gatekeepers the program committee.

Here are my assumptions about the program committee:

They want the conference to be a big success.
They care that people will learn something new or learn how to make an “old” idea work better.
They might or might not care about you. They care about the success of the conference.

That means your abstract has to influence the program committee so they will choose you.

Write a Succinct Abstract

I've been a reviewer for many conferences. Too often, I read rambling “abstracts”—four, five, or six paragraphs of confusing-to-me language. Not only does the language confuse me, but I also can't tell what I'm going to learn from the abstract.

I use two primary approaches:

Kent Beck's One Startling Sentence
Hey! You! See? So…

If you read my blog posts, you see that I use One Startling Sentence a lot. OSS helps me set the context for the reader. That means I also use OSS for articles, short book descriptions, and almost anything else I write in longer form.

Consider One Startling Sentence

I no longer remember how or when I discovered Kent Beck's One Startling Sentence, but I am thrilled I did.

This is the order of a four-sentence paragraph:

First sentence: What's the problem?
Second sentence: Why is this problem a problem?
Third sentence: Startling answer.
Fourth sentence: Implication of the startling sentence.

Here's the first-draft example for my multitasking talk:

You're working on so many projects, you can't tell what to do first.
Multitasking is the fastest way to stop a project in its tracks. Even worse, people feel hopeless about their work.
You can say no or when, especially when you visualize your work and discuss your options with the powers-that-be.
You'll finish more projects, have more pride in your work, and everyone's throughput will increase.

As a first draft, that's not bad. Yes, I have two sentences for the second sentence. That's because there are problems pervade the organization, the project, and the person. I don't yet know how to make this one sentence. I hope that people identify with either the project problems or the personal problems. If I'm lucky, they'll connect with both sets of problems.

You might wonder—can't I use the abstract from the last time I gave this talk? I could. I choose not to until I get to the point where I think I can't improve on the abstract.

When I looked back at the previous times I gave this talk, the abstract changed every time. While the slides might not change much, I often rework the abstract to make the abstract more inviting. (Yes, I iterate on my abstracts for the next time even after I deliver a session.)

And, sometimes, especially if I'm an invited speaker, conferences want just a title. I get lazy and don't write or update the abstract.

Sometimes, One Startling Sentence isn't quite right. That's when I use Hey! You! See? So…

Consider Hey! You! See? So…

I also don't remember when I learned this approach to an opening. A colleague whose writing I enjoyed explained it to me. He had learned it earlier—possibly from Gerald M. Weinberg.

Hey! grabs the reader's attention. It can be a sentence, or an idea, but the readers need to see it within the first couple of sentences, so the reader will continue reading.

You! means how does this idea affect the reader? What about this writing makes it relevant to the reader?

See? is the example piece, the part where the author helps the reader see what the author is talking about.

So… is what you want the reader to do about this once he or she is done reading the work.

Remember back in Frame the Proposal, you made a list of the people you want to attract and the problems they have? That's what the Hey and You parts are.

Here's an example for the multitasking proposal:

Are you a project manager, Scrum Master, or agile coach, attempting to support multiple projects or teams?
Do you feel pulled in so many directions you feel as if you can't make any progress?
If so, you can learn to manage your personal project portfolio.
You'll see how to show your boss(es) all the work you're supposed to do, and how to have the tough “No” conversation.

This is another four-sentence paragraph. It works as an abstract.

Keep the Abstract to One Paragraph

You might use a different approach to writing abstracts. Regardless of your approach, consider keeping the abstract to one paragraph.

Remember these points:

Connect with your reader. Your first reader is the program committee.
Lead with problems. Offer specifics so the program committee can see you have substance behind your proposal.
Make the end of the paragraph as upbeat as you can make it. (That's what people will learn.)

What if you have more to say in a description? You can add supporting paragraphs.

Support the Abstract with More Information

Sometimes, I add more paragraphs to my abstract to support the first paragraph. Some conferences, such as the Agile 20xx, or the PMI conferences, like to read more in an abstract. They want more information because they receive so many proposals.

I have noticed something important. The audience for these additional words is rarely the conference audience. The audience is almost always the program committee.

I could be cynical and say they are looking for reasons to exclude your proposal. I don't actually think they're looking to exclude. However, the program committee looks for the most valuable content. This is your chance to show how valuable your content can be.

You might want to add more detail, so you can show your authority and knowledge of the topic.

When I add more paragraphs, I start with the problems and add more information. Here is a way I might add supporting material, after that first paragraph:

Multitasking pervades every organization. Unless you measure the costs of multitasking, including cycle time, you might not realize how much trying to do “everything” costs a person, a team, and the organization.

You can measure those costs in several ways: creating a value stream map, calculating Cost of Delay, and measuring a team's cycle time.

Even better, if you create a board—and I'll show examples of simple boards—you can create transparency for the problem. Since not everyone believes the cost calculations, you might have better luck with boards.

Armed with data, you can have discussions about what to continue, what to stop for now, and what to do never. You don't need a career-limiting-conversation. You can have a conversation and create win-win outcomes for you, the project, and the organization.

Here's what I did in these paragraphs:

Allude to more outcomes, such as the costs of multitasking, how to measure those costs, and examples of boards and conversations.
Clarified the problems.
Clarified what I will say.

I help the program committee believe I will do a great job with this additional information.

Now, I can assess my outcomes and see if I want to change them. I often do.

Update Your Outcomes

My previous outcomes were:

See the problems of multitasking, including the costs to a person, team, and the organization.
Experiment with ways to expose all the work.
Analyze your situation.
Practice saying No.

I'll add these outcomes:

Show at least three ways of calculating the costs of multitasking for a person, a team, and the organization.
Explain how to create a board that reflects multitasking.
Prepare for the conversation so you and your boss can agree on what to finish now, what to work on later, and what to never do.

I iterate over the outcomes as much as I iterate over the abstract.

Separate the Writing from the Editing

When I teach writing, I teach people to separate the writing from the editing. That means:

Write your abstract as one paragraph of four sentences. (Five, if you must.) I actually write the four sentences separately, as I showed you above.
After you have all the sentences, check them with the grammar checker of your choice. Check for readability and passive voice.
Excise passive voice. I don't care how many words it takes you, no passive voice in an abstract.
Check your readability and Grade levels. The higher the readability score, the better. A readability score of 65 or higher is good. A grade level of less than Grade 8 is good.

I try hard to keep my readability over 65 and my grade level close to 6. Yes, I realize everyone reading conference submissions is smart and has worked for a while. I work on readability to make sure I invite them into my writing. Why make the program committee work hard at reading what I wrote?

Iterate on your abstract until you have four sentences with no passive voice, a readability score over 60 and a grade level of about Grade 6.

When I checked the readability of my abstract, Word gave it a readability score of 70 and a Grade level of 6.7. Grammarly gave it a readability score of 75 and a Grade level of 7. That's good enough, at least for now.

Now Try This:

Write this down:

Write your abstract. I recommend One Startling Sentence, but you might choose an alternative. Regardless of how you organize, start the abstract with the problems you see that your session will address.
How long is that paragraph? If the abstract is more than five sentences, what can you do to shorten the paragraph to four or five sentences? You might need supporting paragraphs.
Check the readability of your abstract. Can you make it more readable? A lower grade level? You can't always simplify, but it's worth trying.

The entire series:

(Update: I wrote a book, Write a Conference Proposal the Conference Wants and Accepts that incorporates this and all the other conference proposal posts.)

Create a Conference Proposal the Conference Wants and Accepts, Part 3: Write the Abstract