The Amateur's Guide to Event Management

Part II: Brainstorming and Event Proposals

The bigger the event, the more people you'll need to run the show. And, quite frankly, the larger the event, the more ideas you'll need to make it work. In addition, the larger the event, the more likely it is that you'll need to codify the event plan into a formal written proposal. This part of the guide will provide you with some structure to your bright ideas.

Brainstorming
There are several ways you can brainstorm or generate event ideas, and they can run the gamut from the speakers you want to invite to what "theme" you want to what sort of table decorations you want on the dining room tables. The best format I've seen for brainstorming is a time-limited session with 6-10 participants, a facilitator, and a dry erase board or easel.

Why no more than 10 people? To keep the group orderly and within the control of a single facilitator.

Why time-limited? Because after 10-15 minutes, people get drained, even in "spontaneous mode."

Now the facilitator can just be a scribe, but it helps if s/he provides a little structure as well. For instance, the facilitator can make certain that the participants cover all the basics of the event (say, in the case of ISDC): location, speakers, registration policies, program book contents, entertainment, meal selections, special events-within-events, etc.

The ground rules for a brainstorming session, for those of you who haven't enjoyed the channeled creativity that fills corporate America, are pretty straightforward, but worth remembering:

• One person speaks at a time
• No idea is dismissed as "stupid" during the 10-15 minute storm session
• Don't take the time to question the realism of anyone's ideas during the storm session
• Participants should try to come up with as many ideas as they can
• The facilitator will write down every idea
• There isn't a price tag or "reality check" on ideas
• Once the storming session is over, THEN reality can set in--but the point of the brainstorming session is to have fun with the process

Brainstorming provides an early opportunity for your team members to "buy in" (another corporate-speak phrase that means "get their own ideas in") to the event. You won't use ALL the ideas, but you can use enough that your teammates can recognize and fight for their part of the show.

After the initial "storm," you can start applying your reality check. You go back over the hastily scribbled ideas and consider what's realistic and what's not (and if not, why not). Your event is born from this wild exchange of ideas.

Proposal Writing
The National Space Society requires bidding groups (usually NSS chapters in specific cities) to submit a written proposal. They do not provide a format. That leaves the content up to you--or does it? However, if you're serious about winning, it helps to do some research on what most business proposals include. My career before living in Huntsville was in writing proposals for government contractors, so I at least had a model. It might not always be the easiest form to follow, but it at least had the virtue (for me) of being familiar. So what goes into a proposal? Here's a broad outline:

• Technical Section (where you describe what you plan to do, where, with what facilities, events, bells, and whistles)
• Management Section (where you describe who is going to do the work/run the show, and what experience they have running or working on events like this)
• Past Performance (where you describe comparable events that your group or team members have run, how much they costs, what were their results, etc.)
• Budget (where you lay out, in the most realistic fashion you can, how much you think your event will cost and where you think the money will come from to pay for or exceed expenses)

Technical Section
This is where you lay out the what and where of your event. It should be the longest part of your proposal. Your customer/funding agency already knows who is attending. Your job is convincing them that they will want to do what you want where you want. In the case of ISDC, you can start with a description of the city in question: why come to Huntsville, Alabama? What has your city got to offer attendees besides your fearless team? You also might want to start talking early about the content of your program--what special events do you plan to include? What speakers or attractions in your area will make your event stand out? What's in it for your audience?

From there you need to talk about the specific venue of your proposed event. How many locations are large enough to host the event you plan to hold? What are your top two or three choices? (NSS, like the government, likes a couple of choices.) Why? What features does your favorite have? You need to paint your readers a picture of what their experience will be like. Make it a good one--and yes, include pictures in your proposals!

Management Section
"Why should I hire you?" You've heard that question in interviews, and that's often what makes the difference between being hired and being bewildered. This is where you need to think not just about your resume or previous job descriptions, but your results. Okay, so you've run the local charity ball--was it a success? Did it make money? Did people have a good time? Did the media say nice things? And what about your team? Have they had similar successes? Do they have experience in, or passion for, the jobs they've agreed to do?

Another important thing: organization. The 20th century might've created quite a few management ideas, but division of labor isn't an entirely bad thing, nor is a chain of command or specific depiction of your decision-making process. These things keep events and people focused on specific tasks, and you can clarify exactly who is doing what. Events like conventions all have specific things that must be done, regardless of the content (rocket science, cheerleading, what have you):

• Operations (e.g., hotel, meals)
• Recruiting, scheduling, assigning, and supervising conference volunteers
• Audio/visual
• Information technology support
• Entertainment
• Exhibits

Ideally, you've got people willing to take the lead (one on each). And you needn't recruit professionals. In fact, odds are good that if you're reading this blog, you don't have access to pros. However, you want to show that your team members--a paragraph per "officer" should be fine--can do the job you say they'll do.

A Note on Proposal Writing: In my case, I was a professional proposal writer, so I led the proposal as well. However, you might be more of a verbal person rather than a writer. Take the time to find the strongest writer you can find. You want to put your best foot forward.

Past Performance

This is where you or your team itemizes its success stories--events you've run, what they were, when they happened, how much money they made, what results they produced. You can do this in table form, narrative form, whatever. Your team should be able to show that you can do the job you're signing up to do as a group.

Budget

I'll discuss this in more detail later, but your budget should have some basis in reality. That means reviewing the price structure at your preferred location(s), multiplying by the number of rooms, days, or people, and laying out the numbers. Don't forget to add taxes and service charges!

The other half of the budget--income--is trickier because you've got to take a few leaps of faith. How much sponsorship money do you think you can bring in? How many people do you think will attend? How high of a registration price will your attendees pay? What do other groups charge for similar events? If you want to be thorough, you also might try a "worst case," "most likely case," and "best case" attendance figure.

Events begin with ideas. Those ideas come from--and must be excuted by--you and your team. You start with a dream, or series of dreams, in the form a brainstorming session. Then you start doing the hard research and laying out the first fully articulated version of your vision in a proposal. The dreams are exhilarating, and your enthusiasm should carry over into your proposal. But the proposal does more than set down your event on paper: it lays down claims that your event can be successful and proofs that your team can achieve it.

Hang onto your hat; the hard part is just beginning.

Creating Documents Without Guidance

I've discovered over the years that vague assignments are either a joy or a pain for the professional technical writer. A typical scenario is something like this: your boss or customer comes to you and says, "We have X amount of information we want to get out, but we don't quite know what to do with it. Want to take a crack at it?"

To which I usually reply, "Heck, yeah!" and I dive in. Not everyone is so gleeful about such an open-ended assignment. The top two questions I've been trained to ask for any new document are:

1. Who's my audience?
2. What's the purpose of the document (i.e. how do I want them to react after reading it)?

Sometimes I might not get clear-cut answers to even that...the point is just to do information organization/design (More on that in a moment). In addition to the two questions above, there are usually two other questions that affect any document a technical communicator is called upon to produce:

• What form or format will my document take?
• What style will I need to use?

In general, the form and format will depend upon the amount of information that needs to be conveyed, while the style will depend on your audience.

But let's say, for the sake of this discussion, that you've received minimal guidance about your content except that the final product will be coming from your corporate president, senior project manager, or someone else near the top of the food chain. I actually enjoy this sort of assignment because it's challenging to think like the boss. You've got, maybe, 2-3 pages' worth (750 words, with or without pictures) of content, which might or might not be organized, and might or might not be on 2-3 pieces of paper...and you might or might not be familiar with the subject matter. Where do you start?

1. Read: Not to be a smart@$$, but you read what you've been given in whatever order it's presented to you. It might not make the slightest bit of sense, but you have to start somewhere.
2. Research: This usually means looking up or asking whoever you think might know what unfamiliar terminology means. Ideally you do as much Googling or sniffing through Wikipedia or internal publications before you ask. (I got burned on this a few times before a manager asked me, point-blank, "Do you ever look things up before asking?" Shame-faced, I went back to my cube and did my homework before asking another durnfool question.
3. Brainstorm: So now that you have the general gist of things...you know what the topic is, what's being said about it, and you know how much stuff you have to work with. Now it's time to take that extra 10 minutes to brainstorm about the pile of data in front of you and in your head. Take a stab at asking:
   --Who do YOU think the audience should be?
   --How do you think they would want to be addressed?
   --What's the most effective way to convey the information and get the reaction you (or your executive) wants?
   --What's the best way to organize the information?
   --How should the information appear visually? (This is the point where my friend Dr. OZMG suggested, "Use pretty fonts and emoticons!" And in truth, depending on your content, this might not be such a bad idea. Sometimes a clever visual gimmick, outside the usual corporate or institutional practice, is exactly what is needed to get your audience's attention.)
   
   Anything longer than ten minutes, either by hand-writing or making out a list on your computer, is probably wasting your time. Work with a peer or two if this helps you.
4. Organize: Take your ideas from your brainstorming session and put them into the order and (rough) format that most makes sense to you. This is where the technical communicator, in my view, can add value to any document. The trick is understanding your content enough to know what order or layout most makes sense for the user. Do you have something with a lot of steps? Then your content should be arranged chronologically. Do you have something that needs to be understood geographically or by layout, like a map or a new form? Perhaps you need to work with your graphics person to develop an easy-to-use "mind map" for your content to guide the user visually. Of course you might actually BE the graphics person; but even if you aren't, you should have some idea of how you want your content to appear--electronically or on the written page. Your graphics person might come up with ideas you hadn't thought of because visual imagination is much different from literary imagination--one of the reasons I'm very grateful for the graphics people in my area.
5. Draft: Start taking a SWAG (engineering term for "scientific wild-@$$ guess") at what you want to say. You've got the content, you've got the layout, now you just need to start doing the brick-and-mortar work of putting words together. Get the basic thoughts down first.
6. Polish: Your first draft is almost guaranteed to look and read nothing like the final product. This was a hard lesson for an English major to learn coming out of college, where I liked to think that the fire of raw inspiration would carry the day. The serious work isn't getting it down in one fell swoop, but getting it right. This is the point where you start trying to capture the "voice" of your customer and the tone you want to set for your audience. If it's an Important Thing, like something to do with legal or regulatory compliance, your tone is direct, serious, and no-kidding-this-has-to-be-done-or-you-go-to-jail. If it's introducing a new product or service, the tone should be enthusiastic ("See what we're doing" or "See what we're doing for you?!"). If it's something warm and fuzzy, like the annual Independence Day party, perhaps a little levity is called for. It also helps to know the personality or preferred style of your executive. If their behaviors or preferences aren't well known, you might have to ask.
7. Peer Review: Have another writer or, if none is available, your customer, review your best-guess, polished draft. Expect other ideas and revisions. Depending on whether it's the customer or a peer, you might or might not have more say about changes. If your peer or customer questions why you organized the information a particular way, be prepared to explain your thought process. This can go on for one or multiple cycles. Again, don't take this as the mark of a bad product or a reflection on your work. Requirements change for communication products as much as engineering products.
8. Finalize: This is where you tweak the minor stuff...missing punctuation, grammatical and other typos, and then turn things over to your graphics person(s) to go to print or online.

I probably could have stopped at step 6, but I've learned a lot about product improvement even toward the end of a development cycle, so it's worth considering the entire "life" of a document as you're creating it.

In the end, you should have a product--web site, presentation, letter, white paper, brochure, or other document--that accomplishes what your customer wanted in the first place. And yes, I do get paid to do this.