Your Conference Talk Is a Project: Preparing a Major Presentation the Blueprint Way

In a few weeks I’ll be standing at a lectern in Copenhagen, in front of a room full of engineers, scientists, and project managers, giving a 20-minute talk on the lessons we learned during the startup phase of ngGONG—the next-generation Ground-Based Solar Observing Network, a proposed network of solar telescopes that the NSF awarded us nearly $20M to design in late 2025.

The venue is SPIE, the same conference where, more than a decade ago, a colleague and I gave a talk called “The Seven Habits of Highly Effective Project Managers” that—click-bait title and all—eventually snowballed into this entire body of work and the Project Management Blueprint itself. Said another way, I have a soft spot for SPIE, and I take its stage seriously.

One thing worth noting up front: the presentation is really the visible tip of a larger effort. The whole thing began months earlier with writing the conference paper that will be published in the SPIE proceedings. This is a 7,000-word paper I wrote with several co-authors, and the talk is built from that paper. So when I write below about “the project,” I mean the entire SPIE undertaking: the paper, the presentation, and even the travel that gets me to and from the podium.

As I sat down to build all of this, I caught myself doing something I always do: running it through the Blueprint. Because here’s the thing I keep coming back to, and which I’ll repeat until you’re sick of hearing it: pretty much everything is a project, including a conference talk. It has a “why,” a “what,” and a “how.” It has stakeholders, a scope, quality criteria, a schedule, a budget, and a pile of things that can go wrong. It even has a closeout phase.

So rather than give you a generic “ten tips for better presentations” listicle, let me walk you through how I’m preparing this ngGONG talk by mapping it directly onto the ten steps of the Project Management Blueprint. These are the same ten questions every project needs to ask; only the answers change between projects.

Let’s begin, as Stephen Covey would say, with the end in mind.

Step 1: Establish Your Talk’s Goals & Expectations

Every project begins by defining what success looks like. A talk is no different. Before I open PowerPoint, I pause to answer one question: if the audience forgets everything else, what is the single thing I want them to walk out remembering? Said another way: WAITTA, or What Am I Trying To Accomplish?

This this step results your talk’s mission statement, and it’s the most important thing of all. For my ngGONG talk, the one takeaway is this: the startup phase of a project is where success or failure is quietly decided—long before anyone buys parts or writes code. Everything in the talk has to serve that thesis. If a slide doesn’t advance it, the slide is gone.

There’s a second goal layered on top of that one, and it’s specific to a conference talk built from a paper: the presentation isn’t meant to replace the paper, it’s meant to sell it. My job in 20 minutes is to distill a detailed written paper down to a few key points, deliver them well, and get enough of the room interested that they go look up the full paper and read it in detail. The talk is the trailer; the paper is the movie. Keeping that goal explicit changes how you build the deck; you’re not trying to cram in everything, you’re trying to leave people wanting more.

Albert Einstein supposedly said, “If I were given one hour to save the planet, I’d spend 59 minutes defining the problem.” A talk works the same way. The time you spend deciding what your talk is actually about will save you from the far more common failure mode: a presentation that wanders through forty slides and lands nowhere. Define your objective first. Write it down. Let it govern everything.

Step 2: Identify Your Audience

In the Blueprint, Step 2 is about identifying your stakeholders. These are the people with interest in and influence over your project’s outcome, and especially important are key stakeholders whose needs you must satisfy. For a talk, your audience is your stakeholder pool, and they are not a monolith.

My SPIE room will hold at least three distinct groups. The engineers want the technical “how” (what we built, what broke, how we fixed it). The scientists want the “why it matters” (what ngGONG will let them learn about the Sun that they can’t learn today). And the project managers want the transferable lessons: the things they can apply to their own program regardless of whether it involves a telescope.

There’s an old AT&T research manager, Ken Hamer, whose line I quote in my course: starting a project “without the audience in mind is like writing a love letter and addressing it to ‘whom it may concern.’” The same is brutally true of a talk. A presentation aimed at everyone lands on no one.

So I do a little stakeholder analysis. I can’t serve all three groups equally in 20 minutes, so I decide up front that my key stakeholders are the project managers and the early-career engineers who’ll someday run their own programs. This is because that’s who the lessons-learned framing serves best. The scientists and senior engineers get enough technical and scientific texture to stay engaged, but I’m not pretending to give a science talk or a systems-engineering deep-dive. Knowing who you’re really speaking to is what lets you cut and edit with confidence.

Step 3: Establish Your Scope of Deliverables

Step 3 of the Blueprint is about defining the scope of deliverables, and, just as importantly, what’s out of scope. For this SPIE undertaking, the scope is bigger than just the slides. There are really three deliverables: a publishable paper for the proceedings; the live presentation I’ll give from the podium; and (secondarily but unavoidably) all the travel and logistics of getting myself to and from Copenhagen and back. Miss any one of those and the project fails, even if the talk itself is brilliant. A perfect presentation is worthless if the paper was never submitted, or if I’m stuck at a airline gate in Frankfurt during my time slot.

Within the presentation deliverable, the discipline is the same one that kills most talks: deciding what to leave out. This is where talks go to die. We have so much to say that we try to say all of it, and the result is the conference-talk equivalent of scope creep.

My process here is pure progressive elaboration. (As is often the case) I start with a mind-map and dump everything about the ngGONG startup into it without judgment. This includes thoughts about the proposal process, the award, the team we assembled, meetings we held, the partnerships, the false starts, the war stories. Get it all out first. Then I build what is essentially a work breakdown structure for the talk: grouping the dump into a handful of logical themes, and then ruthlessly pruning.

A 20-minute talk should present maybe three or four real lessons, told well, which is far better than ten lessons told as a blur. Bill McVeigh, a project management guru I quote often, says the first thing he asks a struggling PM is to show him their work breakdown structure. The first thing I’d ask a struggling speaker is to show me what they decided not to talk about. If the answer is “nothing,” that’s the problem.

Step 4: Establish Your Quality Criteria—What “Good Enough” Looks Like

In the Blueprint, Step 4 sets the acceptance criteria—the measurable standards every deliverable must meet to be accepted. For a conference talk, some of those criteria are handed to you by the conference itself, and they are absolutely non-negotiable. The presentation must ultimately be in PowerPoint format. It has to fit inside a 20-minute slot, with 10 minutes of Q&A. It needs to be the correct aspect ratio (16:9). And it has to be uploaded to the conference system by their deadline. These are the pass/fail specs on the presentation deliverable, and the rest of your design has to live inside them. Get the format wrong or miss the upload, and it doesn’t matter how good the content is because the deliverable will be rejected.

Then there are the quality criteria you set for yourself. These are the specs every slide in my deck has to pass. For instance, I’m a big believer in one idea per slide. If a slide is making two points, it’s two slides, or one of the points isn’t important enough to keep. Images, photographs, and simple diagrams are preferred over walls of text. A single telling photo of the ngGONG team at a workshop does more work than a paragraph describing it. Things have to be readable from the back row, which in practice means large type and very few words. And the cardinal rule: no death by PowerPoint. Nobody has ever left a conference saying, “what really moved me was that slide with the eleven bullet points.”

There’s a delivery spec, too, and it’s the one most speakers violate: do not read your slides. The slide is the backdrop; you are the talk. The instant you start reading text aloud, your audience reads ahead, finishes before you do, and tunes you out. Worse, you’ve made yourself redundant; if the slide says everything, why are you up there? In a sense, your slides should be unintelligible without you narrating them. That’s a feature, not a bug.

This connects to the single most important delivery principle I know: tell stories, don’t recite points. Human beings are wired for narrative, not for bulleted lists. When I cover an ngGONG lesson, I don’t put “Lesson 3: Align partners early” on a slide and read it. I tell the story of a moment where partner alignment was tested, including the tension, what we did, and how it resolved, and let the audience extract the lesson themselves. A lesson they derive sticks; a lesson they’re told evaporates.

Step 5: Establish How You’ll Build It—Your Acquisitions Approach

Step 5 is about how you’ll acquire the scope, i.e., the make-versus-buy decisions, the sequence of work, and the resources you’ll need to produce each deliverable. For this project, the “how” spans both the paper and the presentation, and the order matters: the paper comes first, and the talk is built from it.

The paper itself started exactly the way the talk later did: with a mind-map. I dumped the candidate content, organized it into a logical structure, and then wrote the paper through progressive elaboration: a rough first draft, then refining passes that added detail and tightened the argument. Because I had co-authors, the acquisitions approach had to build in their input and sign-off along the way. You don’t write a multi-author paper in a vacuum and surprise everyone at the end; you circulate drafts, gather feedback, and get explicit buy-in at each major pass. This is exactly the same way you’d get stakeholders to approve a baseline before moving on. That iterative sign-off is what keeps you from a painful rewrite the week before the submission deadline.

Only after the paper was in good shape did I turn to building the talk, and again, it began with its own mind-map, distilling the paper down to the handful of points the presentation would carry. From there it’s progressive elaboration once more: rough deck, rehearse, tweak, rehearse again, refine. One practical note on tooling: I build the talk in Google Slides because it’s fast to iterate in and easy to share, but since the conference requires PowerPoint, the very last step is exporting the finished deck to PowerPoint format and then checking that nothing broke in translation. (Fonts and animations are the usual casualties; more on that under risk.)

There are also the ordinary make-versus-buy questions for slide assets. Some of my photos and diagrams already exist from proposal materials and prior reviews; that’s “buy” (reuse). Some, like a clean diagram of the startup timeline, I’ll have to “make” from scratch. And do I build everything myself, or pull in a teammate to supply the latest instrument graphics? Deciding this consciously, early, keeps you from discovering at midnight before the upload deadline that you don’t have a usable figure of your own telescope.

Step 6: Establish Your Controls & Oversight Approach

In the Blueprint, Step 6 is about how you’ll oversee the work as it gets done, i.e., your project controls. The acronym I use for this is PMCS, which in the PM world normally stands for Project Management Control Systems, but, serendipitously, the letters also spell out the four things you actually do to oversee execution: Perform the work, Measure progress, Change the plan as required, and Status your stakeholders. That’s a tidy way to think about steering any effort, including this one.

Perform. This is prioritizing, assigning and doing the actual work: drafting the paper sections, building the slides, booking the travel. On a solo-ish project like a talk, “assigning” mostly means assigning tasks to yourself on a calendar, but with co-authors on the paper, it genuinely meant divvying up sections and owning the integration.
Measure. You can’t steer what you don’t track. I check progress against the plan: Is the paper draft where it needs to be for the next co-author review? Is the deck timing landing inside 20 minutes when I rehearse it? Measuring against the schedule and the time budget is what turns “I feel behind” into “I am two days behind on the deck and need to act.”
Change. When measurement shows you’re off course, you adjust: deliberately, not in a panic. Maybe a section of the paper gets cut, maybe two slides get dropped to hit time, maybe a rehearsal reveals a story that isn’t working and needs reordering. The point is to make changes as a controlled response to what the measurements are telling you.
Status. Finally, you keep the relevant people informed. For the paper, that’s keeping co-authors current on drafts and the submission status. For the talk, it’s confirming logistics with the session chair and conference organizers so there are no surprises on the day. Good statusing is how you avoid the “wait, the upload was due when?“ moment.

Run those four loops continuously—perform, measure, change, status—and the work stays under control instead of controlling you.

Step 7: Establish Your Timeline—and Rehearse to It

Step 7 builds the schedule. For this project there are really two schedules nested inside each other: the overall timeline that gets the whole effort done, and the 20-minute clock of the talk itself.

The overall schedule is the one that’s easy to neglect until it bites you. It has to account for planning and writing the paper, the firm paper-submission deadline, the planning and building of the talk, the separate deadline to upload the presentation, and finally the fixed day and time slot when I actually stand up and give it. Layered on top of all of that is the travel schedule, including booking flights to and from Copenhagen, hotels, ground transport, and building in enough buffer that a delayed connection doesn’t cost me my session. These dates aren’t suggestions; the submission and upload deadlines and the talk slot are immovable milestones, and everything else has to be back-planned from them. As Stephen Covey put it, “the key is not to prioritize what’s on your schedule, but to schedule your priorities.”

The second schedule is the talk’s internal clock, and twenty minutes is far less time than it sounds. A useful rule of thumb is roughly 1-2 minutes per slide, which means a 20-minute talk is somewhere around 10-20 slides—and probably fewer, once you account for the slides you’ll linger on. If your deck has forty slides, you don’t have a timing problem, you have a scope problem (see Step 3).

Then you rehearse. Do this out loud, standing up, with a clicker in your hand, against a timer. Not in your head. Speaking aloud always takes longer than you think, and it surfaces the transitions that don’t flow and the tangents you didn’t know you’d take. I rehearse a talk like this five or six times minimum, cutting ruthlessly each pass until I’m landing comfortably under time. Which brings us to the budget.

Step 8: Establish Your Budget

In the Blueprint, Step 8 is about the money: estimating all the costs and laying out a time-phased budget. A conference talk feels like it should be free, but it isn’t, and pretending otherwise is how you get an unpleasant surprise on an expense report. Fred Withers, an engineer I quote in the course, puts it bluntly: “Time is money. People cost money. Risk costs money. It always comes back to money.”

So even for something as modest as an SPIE talk, it pays to actually tally the costs. There’s the conference registration fee, which for a major SPIE meeting is not trivial. There are sometimes page charges or publication fees for the proceedings paper. And then there’s travel: airfare to and from Copenhagen, several nights in a hotel at conference-block rates, ground transportation, meals, and incidentals. Denmark is not a cheap place to spend a week. Add it up and a single conference trip can easily run into the thousands of dollars.

The point isn’t that the number is large; relative to a telescope project, it’s a rounding error. The point is that the money has to come from somewhere, and that source has to be sorted out in advance. Is this coming out of the ngGONG project’s travel budget? A separate professional-development or institutional account? Out of my own pocket as a business expense for the consulting side of my life? Each answer has different approval paths and documentation requirements, and the worst time to figure that out is after you’ve booked nonrefundable flights. Just as with a big project, you establish the budget, confirm the funding source, and get the buy-in before you start spending, so that the financial side of the trip is a settled matter and not a lingering worry while you’re trying to focus on the talk itself.

There’s also the cost of your own labor, even if no one writes you a check for it. The hours spent writing the paper, building the deck, and rehearsing are real costs. This is time you’re not spending on “real” project work. Recognizing that up front helps you decide how much effort a given talk actually warrants, which is its own form of budgeting.

Step 9: Identify Risks & Build Contingency

Vince Lombardi said “hope is not a strategy,” and nowhere is that truer than on a conference stage, where Murphy’s Law has a reserved seat in the front row. Step 9 of the Blueprint is risk management and contingency, so I build a little risk register for the talk. For this talk it includes such things as:

The PowerPoint export from Google Slides drops a font or scrambles my formatting, or the venue PC renders it differently than my machine. Mitigation: embed all fonts, check every slide after exporting, and bring a PDF fallback of the deck.
My embedded video won’t play. Mitigation: test it on-site early, and have a static backup slide that makes the point without the video.
I run long. Mitigation: rehearse under time and pre-identify the two slides I can drop live if the clock is against me—my schedule contingency.
The room goes silent in Q&A. Mitigation: seed a question or two with a colleague, or have a “the question I’m often asked is…” ready to prime the pump.
Someone asks something I can’t answer. Mitigation: a graceful, credibility-preserving “I don’t know, but I’d be glad to follow up—come find me after.”

And the master contingency: upload early, carry the deck on a USB stick and in the cloud, and arrive early enough to test the lectern, the clicker, and the screen before the room fills. These are the talk equivalent of building schedule and budget reserves.

Step 10: Establish Your Closeout Plans

Finally, Step 10: land the plane. In the Blueprint, closeout is about completing the work, satisfying stakeholders, and—coming full circle—confirming you met the goals you set in Step 1. A talk closes out the same way.

Restate your one takeaway, deliberately and clearly, so it’s the last thing in the room’s ears. Handle Q&A as part of the deliverable, not an afterthought; this is often where credibility is genuinely won or lost.

But a strong closeout actually starts before you ever take the stage, with rehearsal. The single biggest factor in whether the live performance lands is how many times you’ve run it out loud beforehand. Rehearsal is what turns a deck you wrote into a talk you can deliver, smoothing the transitions, locking in the timing, and freeing you to make eye contact and tell the stories instead of staring at your notes. A well-rehearsed talk looks effortless precisely because of all the effort behind it.

Then comes the part almost everyone skips. Make it easy for people to follow up. Include a final slide with your contact details and a pointer to the paper, and then actually do the following up: if someone asks a question you promised to look into, or you said “come find me after,” close that loop in the days afterward. It’s a small thing that builds an outsized amount of goodwill and credibility.

And finally, capture your own lessons learned while they’re fresh. What landed? What dragged? Which slide drew the blank stares? Which question came up that you wish you’d had a slide for? That’s the raw material for the next talk, and the next one after that, and, fittingly, “lessons learned” is exactly what this whole ngGONG talk is about in the first place.

As Tim Ferriss wryly noted, “you’re 90% done. Congratulations! You only have 50% of the actual work left.” The talk isn’t finished when you stop speaking. It’s finished when you’ve delivered the takeaway, satisfied the room, and pocketed the lessons for next time.

Same Ten Questions, Different Answers

The whole point of the Blueprint, and it’s why I keep running everything—telescopes, proposals, and yes, conference talks—is that these same ten steps always apply. Dr. Steve Ellis at the NSF says it best: “The questions are always the same. It’s the answers that will vary greatly.”

A $20M telescope design project and a 20-minute conference talk could not look more different on the surface. But underneath, they ask the identical questions. Who is this for, and why? What am I going to deliver, and how good does it need to be? How will I build it, oversee it, schedule it, and pay for it? What could go wrong, and how do I close it out cleanly?

Answer those ten questions for your next talk, and I promise you’ll be standing at that lectern more prepared than most of the room. I’ll see you in Copenhagen.

The Project Management Blueprint

Presentations as Projects