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.

“ [A drawings] is a line around my thoughts” —Gustav Klimt

Imagine you’ve been assigned as the project manager for a new transportation link across a wide river. Everyone agrees on the goal: enable vehicles to cross the water efficiently, safely, and year‑round. In your mind, that obviously means a bridge, so you kick off conceptual design assuming a mid‑span suspension structure with generous clearance for ship traffic. About halfway through, as scope, cost, schedule, and risk numbers solidify, a key stakeholder casually mentions how excited they are about finally getting a tunnel under the river; another chimes in that they had always assumed you would buy a small fleet of roll‑on/roll‑off ferries; and a third says a bridge is what they thought, too, but they were picturing a straightforward truss bridge, not the grandiose signature suspension span your engineers are quietly optimizing. By this point, analyses have been run, procurement paths are being scoped, and expectations are diverging instead of converging...

…okay, this is an extreme example, but you should still get the point: confusion could have been surfaced and resolved early if, back at the beginning, you had forced yourself and your stakeholders to react to a simple reference design: a rough sketch that made it explicit whether “cross the river” meant a tunnel, a ferry system, a truss bridge, or a suspension bridge—and what that choice implied for scope, interfaces, and trade‑offs.

TL;DR

• What: A reference design is a simple, provisional system‑level sketch that shows what the major pieces of a project are, and how they fit together. Also known as a “strawman” design, a reference design is a core tool in Step 3 of the PM Blueprint: defining and documenting scope.

• Why: Building a strawman reference design early exposes gaps in scope and requirements, highlights key trade‑offs, and gives everyone—from engineers to stakeholders—a shared mental model of the system.

• How: Block off focused time with the right people, sketch an intentionally rough “cartoon” of the system, and then use that sketch to drive scope discussions, requirements gathering, interfaces, trade studies, onboarding, and stakeholder conversations.

What: Reference Designs in the PMB

A fundamental aspect of the Project Management Blueprint is defining and documenting the scope. For project managers, that ultimately means creating a work breakdown structure (WBS) and accompanying dictionary. It means making clear what is in and out of the project, what major deliverables you handle, and where your boundaries and interfaces lie. But often overlooked during this process is the creation of a so-called “reference design.” That’s bad news, as a reference design is one of the more effective tools you can use to define scope. Instead of only writing scope in prose, you also draw it.

A reference design (also often called a “strawman” design), is a deliberately simple, system‑level representation of your project’s deliverables. Think of it as “cartoon architecture”: a handful of key blocks, with arrows showing how they connect, sit in space, and pass things like information, forces, or, with telescope design, light. It is not a polished CAD model or a detailed P&ID. It is a high‑level sketch that is “real enough” to ask tough questions of. In the blueprint, this sketch (or sketches) becomes the visual anchor that holds together everything from your scope statement, your requirements, and your work breakdown structure, to the management of stakeholder expectations.

Equally important is what a reference design is not. It is not the final design. It is not even a conceptual design. It is not a commitment to specific components, vendors, or details. It is not a straitjacket that forbids alternatives. Instead, it is a working hypothesis, a best current guess at how the system might hang together. Its job is to bootstrap the project, provoke better questions, expose hidden assumptions, and give the team something concrete to push against while you are still early enough to change your mind cheaply.

Why: Why Reference Designs Matter for Scope and Requirements

Work breakdown structures are a type of documented, shared understanding. A reference design makes that understanding visible. When you draw the system, block by block, you are forced to decide what belongs on the page and what does not. That immediately clarifies what is inside your project’s responsibility and what lives elsewhere. Missing blocks or “mystery arrows” often reveal scope gaps that would never show up in a generic scope statement.

Reference designs also improve requirements. When you look at each block and interface on the sketch, you can ask structured questions: “What does this need to do? How well does it need to do it? What can go wrong here? Who owns this interface?” Those questions eventually turn into functional, performance, interface, and environmental requirements. Because the diagram is simple and shared, subject matter experts (SMEs) from different disciplines can react to it quickly. They are no longer staring at a blank page; they are responding to a concrete proposal.

The sketch also highlights trade‑offs, required analyses, and risks. A reference design makes “forks in the road” very obvious: spots where there is design space to explore, areas where design choices have already been made, and how functional needs will be distributed. Those forks are where real trade studies belong. By making them visible early, you can plan analyses, simulations, and prototyping instead of drifting into an implicit decision by default. The diagram becomes the picture everyone points at in meetings, including scientists, engineers, managers, and sponsors. That kind of clarity is hard to get from text alone.

How: Building and Using a Reference Design on Any Project

You do not need a telescope project or a giant budget to benefit from a reference design. You can build one on almost any project if you approach it intentionally.

The first step is to create focused time and get the right people in the room. Pick a small group that understands the system end‑to‑end, even if only at a high level. Block off a few hours to a full day. Treat it like a working session, not a side conversation squeezed between emails. If you can, close the laptops, silence the phones, and clarify that the goal is to walk out with a credible strawman design—not a perfect one, just something everyone can see and critique.

The second step is to start ugly and stay system‑level. Begin by drawing the major functional or physical blocks and the main flows between them. For a software system, that might be blocks representing users, front‑end, services, databases, and external APIs. For a facility, it might include buildings, processing elements, structures, utilities, and outputs. Do not worry about alignments, fonts, or whether a block is “to scale.” Once you have a first sketch, deliberately draw one or two variants. For each variant, list the pros and cons on the board. The differences between the versions are where requirements and trade‑offs live.

The third step is to use the strawman to drive scope and requirements discussions. Go block by block and interface by interface. Ask what must be true, what is definitely not your responsibility, and where you are uncertain. Capture clear requirements, open questions, and potential trade studies. Label the diagram as “Reference Design v0.1” or similar to make its provisional nature explicit. Expect it to evolve as you learn more. Finally, put the reference design to work. Include it in onboarding materials; use it to define where new employees will work and be responsible. Walk stakeholders through it when you explain the scope. Open it back up at key milestones as a living artifact, not a one‑off sketch that disappears into a notebook.

How: A Day with ngGONG’s Opto‑Mechanical Reference Design

On ngGONG, we recently did exactly this for the opto‑mechanical layout. I invited a senior, very experienced engineer to join me for a focused working day. The goal was simple: walk out with a first‑cut reference design for the overall opto‑mechanical structure of the ngGONG system. A secondary goal was to create layouts of our high-level software and data management system pipelines. We booked a conference room, closed the door, and agreed up front: no email, no diversions, no “quick calls” unless the building was on fire. For that day, the reference design was the job.

We started with a really rough one-line diagram that was created back when we were developing the proposal. We coupled that with a big blank whiteboard in the conference room. The first sketch was as simple as possible: where the light comes from and enters the facility (we literally drew a cartoon of the sun with rays flowing out of it), how it travels through major optical elements, how the telescope structure holds and moves those elements, where instruments sit, and where data leaves the system. It was not pretty. Boxes were lopsided, arrows were crooked, and labels were abbreviations. That was fine. The point was to get a complete path on the board from “Sun” to “data product” with enough structure to argue and poke holes in.

From there, we iterated. We drew one variant where certain assemblies were co‑located, then another where they were separated. We argued about gravity vectors, structural envelopes, maintenance access, thermal effects, and alignment tolerances. For each option, we listed pros and cons on the board: performance, complexity, & risk. Several times we erased large sections and started again, because a constraint we had parked in the back of our minds suddenly mattered. By mid‑afternoon, we had gone through enough cycles that a particular layout felt “cleaner” than the others: fewer awkward interfaces, better consistency with the science goals, and fewer hidden traps in the mechanics. Along the way, we took periodic photos of the whiteboard to document different versions before they were erased.

By the end of the day, we had a basic opto‑mechanical reference design. It was still a cartoon, but it was a coherent cartoon that we cleaned up into a PowerPoint sketch. Both of us believed it was realistic enough to distribute to a wider audience. That sketch now does several jobs for ngGONG. It is a starting point for deriving specific requirements on things like stiffness, pointing, alignment, and environmental control. It highlights where we need trade studies—for example, which structural configurations should be compared formally, or where different optical layouts might be worth analyzing. It gives new engineers a fast, visual orientation to the system. And it provides a single picture we can use with advisory boards and sponsors when we explain where we’re headed.

On a personal level, that day was a reminder of how powerful it is to step away from the email inbox and project management reports, and just think with a dry-erase marker in your hand. The quality of the reference design had as much to do with the uninterrupted time and honest debate as it did with any particular insight. By the time we left the room, tired and with the whiteboard covered in half‑erased ghosts of earlier ideas, we had moved the project forward tangibly.

Bottom Line:

Creating a reference design is one of the most effective things you can do in Step 3 of the PM Blueprint. A simple, provisional sketch of the system forces clarity about what is in scope, what is out, and where the critical interfaces and trade‑offs lie. It keeps you from waking up halfway through “designing a bridge” only to discover that you should have been working on a tunnel. Early “cartoon architecture” can solve this issue, plus it forms a concrete basis for writing better requirements, planning trade studies between options, onboarding new team members with the project plans, and communicating with stakeholders in a shared visual language. Whether we’re sketching ngGONG’s opto‑mechanical layout, or the high‑level concept for getting vehicles across a river, the reference design is how we draw a line around our thoughts early enough that the whole team can see it, challenge it, and commit to building the same thing.

“It’s not bragging if you can back it up.” —Muhammad Ali

TL;DR

• What: A stoplight or “BRAG” status table is a one-page, color-coded view of recent project progress, current status, and upcoming work, organized around key deliverables, activities, and milestones.

• Why: It gives stakeholders an at-a-glance executive summary, forces the PM to regularly step back from the weeds, and is often a formal requirement from sponsors and oversight bodies.

• How: Define the format and time resolution, agree on clear color definitions, and regularly update a standard table that can be reused in reports and briefings, as we’re doing for ngGONG with a BRAG-based Google Sheet.

What is Stoplight / BRAG Reporting:

In traditional project management, “stoplight reporting” means using a simple, color-coded table to summarize status across a handful of major deliverables, activities, and milestones. The classic version is called a RAG chart (Red, Amber, Green), where the colors indicate varying degrees of status. (The slightly more complete version is BRAG (Blue, Red, Amber, Green)). The goal of a stoplight chart is to compress an overview of the project into a single image that a stakeholder can scan in 10–20 seconds and immediately understand how well the work is proceeding.​

A stoplight report usually looks like a grid: reportable items down the left, time across the top, with each cell filled with a color that reflects status for that item over that period. The items might be high-level WBS elements, major deliverables, primary activities, or Level‑1 milestones that you’ve already defined for external reporting. The time axis can be months, quarters, or years, depending on the scale and phase of the project. The graphic itself is usually included in a larger report, but is also standalone and can be extracted and dropped directly into someone else’s briefing.​

For a BRAG report, the color Blue indicates work that is completed and effectively off the table; green means on track; amber (or orange) signals lagging or potential concern; red indicates significant trouble, such as major delays or technical issues. Additionally, many projects also add gray for future work and white for not applicable. In a single glance, you can see when a WBS area moved from gray to green to blue, or when something went amber or red. Done consistently, this becomes a powerful communication tools in your reporting toolkit.​

Why Stoplight Reporting Matters:

In many projects, stoplight reporting is not optional. Sponsors and oversight agencies often mandate a simple, visual status summary like this as part of their reporting requirements. Per our project award terms and conditions, the NSF requires a stoplight-style table provided to them on a quarterly reporting cadence. This table reduces the cognitive load for reviewers who are scanning multiple projects and need to understand where attention is required.​

Beyond stakeholder compliance, a BRAG table is just good project management practice. It forces you, as the PM, to step out of the day-to-day details and look at the project as a whole. Instead of getting lost in hundreds of schedule activities or Jira tickets, you ask a more fundamental question: “Across our major deliverables and Level‑1 milestones, what’s actually on track, what’s slipping, and where should my attention be focused?” That perspective is hard to maintain without a simple, recurring tool like this.​

There is also a portfolio effect. Stoplight reports allow senior leadership to compare multiple projects or subsystems on a common scale. If every project uses the same timeline and set of colors with the same definitions, it becomes much easier to identify systemic issues, spot chronic problem areas, and allocate support. Even at the individual project level, a consistent BRAG chart becomes a historical record. You can see when a particular area was struggling, when interventions were made, and how long it took to recover.​

How to Build a BRAG Chart:

The first step is to decide what you are going to show on the axes. On the left-side vertical axis, list the elements that matter most to you and your stakeholders: e.g., high-level WBS areas, major deliverables, and key reportable milestones. These should map cleanly to the story you tell elsewhere in your reports and to the Level‑1 (or equivalent) milestones you’ve already defined. Avoid the temptation to list every detailed activity; instead, pick a few dozen items that truly represent the “forest,” not the individual trees.​

On the horizontal axis across the top of the chart, choose a time resolution that matches both the project’s duration and your reporting cadence. For many engineering projects, quarterly time buckets work well for the near term, with annual buckets for long-range planning. If your project is short, then months (or even weeks) might make more sense. The key is to strike a balance: too coarse makes the chart vague and uninformative; too fine and it becomes a sea of tiny colored boxes that nobody can interpret. Whatever you choose, keep it consistent over time so stakeholders can compare one report to the next.​

Next, define your colors explicitly, in writing, and share those definitions with your team and stakeholders. For example: Blue = complete; Green = on or ahead of plan; Amber = behind plan but recoverable without major re-baselining; Red = significant issue requiring intervention and/or re-plan; Gray = not yet started (future period); White = not applicable. The definitions can be quantitative (e.g., “>10% slip is red”) or qualitative, but they must be consistent. Once the structure and color key are in place, build the table in a tool that’s easy to update—Excel, Google Sheets, or whatever your organization already uses—and reserve a full size image in your regular report for the “Project BRAG” so that it can be easily reused in other decks.​

How ngGONG Is Using BRAG Charts:

For ngGONG, the BRAG table lives in a standing Google Sheet that can quickly be updated and then exported as a static graphic for inclusion in our monthly report to the NSF and internal leadership. This keeps the working version live and editable, but ensures that each month’s report captures a snapshot in time that won’t change later. It also makes it easy for others—program management, NSO leadership, or communications teams—to grab the same figure for their own use.​

On the left-hand side of the ngGONG BRAG chart, the rows are organized around the ten primary WBS areas, with two to four key elements under each one. Those elements include both primary activities (such as completion of a primary design activity or document), and/or Level‑1 milestones that are reportable to NSF. This structure aligns the BRAG chart directly with the rest of the project’s planning artifacts: the WBS, the integrated schedule, and the milestone list all point to the same set of elements.

Across the top, the ngGONG BRAG chart uses a rolling-wave approach. The current and near-term periods are broken into fiscal-year quarters, where the detail matters and where stakeholders expect to see more granular progress. Farther out, the columns transition to fiscal years instead of quarters, which keeps the chart readable and avoids false precision about work that is still several years away. The color scheme we use is full BRAG, plus gray for planned future work and white for not applicable, so that every cell has a clear and intentional meaning. Over time, the chart will fill in from gray to green to blue, and occasional patches of amber or red help focus attention where it’s needed.​

The Bottom Line:

A BRAG-style stoplight report is a simple but powerful way to “brag” about your project’s progress while also being transparent about where things are lagging. It compresses complex schedules and deliverables into a one-page, color-coded story that stakeholders can understand at a glance, and it forces the project team to step back regularly and look at the forest instead of the trees. For ngGONG, this kind of reporting is both a requirement and a best practice, and it fits naturally into a broader, systematic approach like the Project Management Blueprint. Done consistently, your BRAG chart becomes a type of honest “selfie” of the project, one that you can stand behind even when a few pixels are red. Remember, it’s not bragging if you can back it up—with a stoplight chart, that is!

“The first draft of anything is s**t.” — Ernest Hemingway

Papa Hemingway’s words may be crude, but they hold the secret to creating anything complex, whether it’s a novel, a house, or a project management plan. When professional writers sit down to work, they don’t produce a polished manuscript in a single sitting. They typically start with a rough outline, move to a messy first draft, and then iterate through successive rounds of editing and polishing. Architects work the same way; they sketch the “flow” of a home and the general shapes and sizes of the rooms long before they ever think about specifying the bathroom fixtures or floor coverings. They understand you must establish the broad strokes before you can effectively fill in the details.

In the world of project management, we call this concept progressive elaboration. At its core, this is the practice of developing a plan in steps and continuing to increment it with better information as it becomes available. It is the acknowledgement that we cannot (nor should) know everything at the start of a project. Instead of trying to force a perfect, 100% complete plan on day one—which is a recipe for frustration and failure—we deliberately choose to define our plans broadly at first, and then refine them in a series of incremental loops. We define, then we refine, and only then do we finalize. This allows us to lock in the “big picture” direction before getting bogged down in the minutiae that might change anyway.

Why Progressive Elaboration Matters:

The primary value of progressive elaboration is that it prevents us from wasting time, money, and mental energy on “dead ends.” Imagine if an architect spent weeks detailing the tile work for a bathroom, only to realize later that the client hates the location of the master suite and wants the entire floor plan stretched and flipped. All that detailed work would be wasted. In project management, if we dive too deep into the specifics of a schedule or budget before we have even agreed on the high-level scope and deliverables with our stakeholders, we risk having to tear it all up and start over when they inevitably disagree with our fundamental assumptions.

Progressive elaboration is a critical tool for risk management and stakeholder alignment. By presenting a “rough draft” of our plans to stakeholders, we invite them into the process early when changes are cheap and easy to make. It is far easier to adjust a bullet point on a slide deck than it is to re-engineer a subsystem that has already been designed. This iterative approach allows us to course-correct early, ensuring that when we finally do commit resources to the detailed work, we are doing so with the confidence that we are heading in the right direction. It keeps the team focused on the right level of detail at the right time, preventing the paralysis that comes from trying to solve every problem at once. And perhaps most important of all, this approach all but guarantees buy-in and support from our primary stakeholders, as they feel like the designs and plans are as much theirs as ours.

How We Are Using This On ngGONG:

On the ngGONG project, we are applying progressive elaboration essentially everywhere, from the macro level of developing our management plans, to the micro level of establishing technical designs and specifications. For our management approach, we didn’t write a perfect Design Execution Plan (DEP) overnight. Instead, we started by addressing the ten steps of the Project Management Blueprint in broad brushstrokes. We asked: Who are the key players? What are the primary deliverables? What is the general timeline? What is the approximate order-of-magnitude cost? We documented these high-level answers, vetted them with our leadership, and only then began the deeper work of fleshing out the specific WBS dictionary entries and detailed bottom-up cost estimates. This aligns perfectly with the guidance in the recent NSF Research Infrastructure Guide (RIG), which explicitly calls for “tailoring, scaling, and progressively elaborating plans” to fit the maturity of the project.

Technically, we are using the same “Define—Refine—Finalize” loop for our engineering designs. An example is our work on the telescope’s light-feed system. Rather than immediately trying to engineer the final optical prescription, we first established a rough concept: an alt-alt mount on a tower. We present this concept, gather feedback, and then move to the next level of detail, such as determining the f-number of the beam and how to distribute light to the instruments. We just completed a similar loop for the creation of our Science Requirements Document (SRD). We started with a table of contents and outline, moved to a rough draft, and are now going to present that draft to our Science Working Group for input. We don’t waste time on the specifics until the big picture is approved.

How You Should Apply This:

You can apply the same logic to your own projects by resisting the urge to be a perfectionist in the early stages. When you are applying the ten steps of the PMB, do not generate final, detailed answers for all ten steps on your first pass. Instead, treat your first pass as a rough “sketch.” Identify your most important stakeholders, draft a rough scope, take a stab at the major risks, and put together a high-level timeline. Then, stop. Take this outline to your key stakeholders and get their buy-in on the general approach. Ask them: “Is this roughly what you had in mind?”

Once you have that high-level agreement, you can start your second loop. Go back through the steps and add the next layer of detail. Turn your high-level scope into a Level 2 or Level 3 Work Breakdown Structure. Turn your rough timeline into a high-level flowchart with major milestones. Then, loop back to your stakeholders again. Repeat this process until you have an execution plan that is robust enough to actually carry out—with confidence. By working in these concentric circles of detail—defining, then refining, then finalizing—you ensure that your project is built on a solid foundation of agreement, rather than a house of cards constructed in isolation.

The Bottom Line:

Hemingway was right: the first draft is far, far from perfect. In fact, it is often plain wrong, but this is okay. Progressive elaboration allows us to navigate the uncertainty of a new project by starting with what we know and systematically filling in the blanks. It saves us from costly rework, aligns us with our stakeholders, and ensures we are always building on firm ground. So, don’t write the final manuscript on day one; you can’t. Sketch the outline, get feedback, and then—and only then—start filling in the details.

“If you want to be creative, go write a novel. If you want to be useful, write the same clear, boring status report every month.” —P. Gretchen

What this is and what it does:

This post is about something deeply unsexy: using the same “boring” status report template over and over. It is about predictable formats, recycled sections, and bullet lists instead of prose. It is also about why that is exactly what your stakeholders need from you.

On complex, high‑risk projects, boring is not a bug; it is a feature. A fixed, repeatable template lets stakeholders jump straight to what they care about—status, risks, issues, performance—without having to decode your latest creative layout. It turns your report into a tool, not a literary performance.

Why this matters in project management:

Stakeholders value one thing when they open a monthly report: information. They do not sit down with a status report the way someone might with a magazine article at the dentist’s office. They want to focus on specific information. They want to quickly glean the same things, over and over: “Are we on track? What’s changed? What do you need from me?” Clever prose and shifting structures work directly against that need.

A fixed template also reduces cognitive load. When the sections and order never change, sponsors can reflex‑scan: “Decisions Needed, then Risks, then Schedule Variance, then Budget.” They spend their attention on content, not on learning how you organized it this month. On big projects, that difference is the line between a sponsor who actually reads the report and one who quietly gives up.

How we do this on ngGONG:

On ngGONG, we intentionally made our monthly reports boring. Well, not “boring” per se, but we made them predictable. The core template will rarely change. The sections map directly to what NSF and other key stakeholders have asked to see: programmatic status (budget, schedule, risk, & contingency), salient technical status/progress data (organized by WBS areas), and images & photographs. Heck, even our title page is plain and prescribed.

We started with externally imposed formats—the NSF reporting requirements—and treated them as the baseline. Then we extended them just enough for our project context: explicit contingency burn-down vs risk exposure, etc. Those extra sections give sponsors exactly what they need to act quickly, without hunting through narrative text.

How you should handle this on your project:

At the start of a project, talk to your key stakeholders, converging on an agreed‑upon report format. Walk through a draft table of contents: scope, schedule, budget, risks, decisions, actions, maybe a one‑page dashboard. Make the structure part of your stakeholder engagement plan and, ideally, your charter and/or communications plan. You are not just agreeing on what you will report, but how and where they will find it every time.

Once you have that skeleton, lock it down. Use bullets for the technical updates—accomplishments, variances, issues, next steps. Standardize sections for scope changes, milestone status, critical path movements, and risk updates. Treat the template as a checklist to reduce the chance you forget something important. When you improve it, do so slowly and transparently: explain the change, keep the overall layout intact, and avoid “surprising” your readers with a new look—or even minor changes. The goal is “boring” and predictable (and therefore useful).

Bottom Line:

Your stakeholders do not need (nor want) creative structure; they need (and want) reliable information, fast. Creativity and unpredictability are anathema to professional project management. Pick one simple, fixed monthly template that covers scope, schedule, budget, risks, decisions, and actions. Agree on it with your stakeholders, then use it for at least six cycles. Measure how long reviews take, how many questions you get, and how often you hear “no surprises.” That is where you will see the genuine beauty in boring—and why, on real projects, useful beats creative every time.

“Diversity: the art of thinking independently together.” – Malcolm Forbes

What is a composition matrix?

The ngGONG objective is to design a next‑generation global network of solar observatories that will replace the existing GONG system and serve research, space‑weather, and operational communities such as NOAA and the Department of Defense. The stakes are high, because these observatories will feed data into everything from basic helioseismology research to real‑time space‑weather forecasting and defense operations. That level of impact demands oversight, and one of the outside groups we need to have is a Science Working Group, or SWG. And that group needs to be both scientifically deep and broadly representative.​ Enter: composition matrices.

A composition matrix is a simple tool (i.e., a spreadsheet) that can be used to assemble a strong and diverse group of people. For example, it forces rigor about who sits on an oversight body like our SWG. Down one axis are candidate names; across the other are the attributes that matter for the board: institutional affiliation, domain expertise (helioseismology, solar dynamo, instrumentation, space‑weather modeling, etc.), skills, and sometimes geography or sector (NOAA, DoD, NASA, university, industry). Each cell lets you mark whether a candidate brings that attribute. When you step back, the matrix shows visually any gaps and over‑concentrations far more clearly than a mental list or an email thread ever could.​​

Why this matters in project management:

From a Project Management Blueprint perspective, advisory boards live at the intersection of Step 1 (Identify Project Stakeholders) and Step 2 (Establish Project Goals & Expectations). They represent key communities that care about the project’s outcome and have both influence and expertise to shape it. For ngGONG, that includes research scientists, operational space‑weather users, funding agencies, and international partners who will rely on decades of observations. Getting the mix of oversight people wrong means the project can drift away from what “success” actually looks like to its most important users.​​

A composition matrix converts the vague desire for “diverse representation” into something verifiable. It lets you check, for example, that you are not overloaded with photosphere experts while ignoring the coronagraph or space‑weather forecasting communities, or that you have representation from both research observatories and operational centers like NOAA’s Space Weather Prediction Center. It also helps satisfy formal sponsor requirements: the National Science Foundation expects documented stakeholder engagement and advisory structures that cover the full performance‑measurement baseline of scope, quality, schedule, and risk.​​

How we’re doing this on ngGONG:

For ngGONG, the National Solar Observatory has the responsibility for defining the science objectives that will drive technical design decisions. But this science team does not want, nor is it allowed by NSF policy, to do this in isolation; the project is required to show broad community input and engagement. The answer is a Science Working Group, which is an advisory committee of roughly 10–12 experienced, external scientists and researchers who will meet a few times per year to “look over our shoulders,” review requirements documents, and advise on instrument and telescope design choices and plans.​​

The challenge is that there are many excellent people who could serve on such a board. To bring discipline to selection, we built a composition matrix in Google Sheets and started by populating it with dozens of potential candidates drawn from our internal knowledge—capturing their affiliations, domains (solar interior, flares, synoptic modeling, instrumentation, machine learning, etc.), and sector (NOAA, DoD, NASA, universities, industry). We then held a working session with a partner institution, asking them to add names, refine expertise tags, flag conflicts, and suggest people to rule out for practical reasons (availability, overlapping roles, or organizational balance). The result is not the final SWG group, but a curated pool from which a future SWG chair can help down‑select to a balanced 10–12‑person committee.​​

How you can apply this to your project:

On your project—whether you are building a software platform, a research facility, or a regional infrastructure program—the same approach scales well. Start by defining what your advisory body is supposed to do; for example: provide stakeholders’ voices, review key documents, validate requirements, or act as a sounding board for trade studies. Then list the perspectives and skills that must be present to provide these things, such as functional areas, customer types, partner organizations, regulatory bodies, and any critical cross‑cutting skills like systems engineering or operations. These become the columns of your matrix.​​

Next, brainstorm a list of candidate members and add each to a separate row. Do a first pass yourself, then bring in a small, trusted group of internal and external stakeholders to mark up the sheet: add names, correct expertise tags, suggest removals, and highlight potential chairs. Once you can see the gaps, you can deliberately target invitations, for example, adding someone from a neglected geographic region or a missing user segment. Finally, as on ngGONG, consider separating two decisions: first assemble a strong candidate pool; then appoint a chair who can partner with you to select the final board and keep it effective over time.​

Bottom line:

A good advisory board should indeed be “independent together.” A composition matrix gives you a concrete way to build that independence and togetherness into your project from the start. It will not produce a perfect oversight committee—nothing will—but it reliably yields a stronger, more balanced board than picking names from memory or politics alone. For ngGONG, that means a Science Working Group that can credibly represent the broad solar and space‑weather communities, help NSO navigate tough design decisions, and keep a multi‑decade observatory network aligned with what the community actually needs. For your project, a composition matrix is an easy to use, but powerful, tool that can dramatically improve stakeholder coverage, governance quality, and, ultimately, your odds of long‑term success.

“If it is not written down, it does not exist.” — Philippe Kruchten, Academic and Software Engineer

What is a Meeting Agenda?

At its simplest level, a meeting agenda is a roadmap for a conversation. It acts as a structured plan that outlines exactly what will happen during a specific block of time. It provides the “who, what, when, and where” of the gathering, listing the invited attendees, the time and duration, and the specific topics to be discussed. However, a truly effective agenda goes beyond just a laundry list of talking points. It serves as a governing document that sets the boundaries for the discussion, ensuring that the time spent together is focused, relevant, and productive rather than a meandering chat.

I view the agenda as a living document that transitions into the formal record of the project. Instead of having a separate document for minutes, I prefer to keep meeting notes directly within the agenda document itself. This means the file starts as a plan of action and ends as a historical record of what was discussed, what decisions were made, and who was assigned specific action items. This consolidation reduces administrative overhead and ensures that the original intent of the meeting is permanently linked to its outcomes.

Why Agendas are Important

I was taught very early in my career a simple but absolute rule: never hold a meeting without an agenda. If a meeting isn’t important enough to warrant a few minutes of planning, it isn’t important enough to attend. Agendas are critical because they manage people’s expectations. When you send an agenda in advance, you are explicitly telling stakeholders who is coming, how long you need their attention, and exactly what you intend to discuss and/or achieve. This respects their time and sets a professional tone before the meeting even begins.

Agendas serve as a shield against scope creep within the meeting itself. Without a defined list of topics, discussions often veer off into “interesting” but irrelevant territory, wasting valuable time. A formal agenda gives the meeting lead the authority to steer the conversation back to the matter at hand. It also ensures that critical topics aren’t forgotten in the heat of the moment. In serving as the foundation for the meeting notes, the agenda also provides official and technical traceability, proving that specific decisions were made and agreed upon by the relevant parties at a specific point in time.

How We’re Addressing Agendas on ngGONG

Last week, we held our first formal meeting with the National Science Foundation (NSF). This was our official Kick-off Meeting (KOM). Standard procedure dictates that a KOM happens shortly after the start of a project, but our timeline was unusual. Because most NSF personnel were furloughed due to the recent government shutdown (literally on the same day our project started), we had operated independently for the first 45 days. While the delay wasn’t ideal, the good news is that our NSF Integrated Project Team (IPT)—which includes a Program Officer, a Grants and Agreements Officer, and a Research Infrastructure Office liaison—proved to be professional, knowledgeable, and pragmatic once they were back online. Said more simply, we all just rolled with the reality of the situation the best we could.

The meeting was called relatively late, leaving us little time to prepare. Via a series of email exchanges, the Program Officer said that he wanted to cover introductions and discuss two specific documents we had already submitted: the Design Execution Plan (DEP) and our Contingency Justification Document. I took this input and created a formal agenda in Google Docs. I added a few additional topics I wanted to cover and then ran it by my internal team first for comment. I then shared the link to the document with the NSF ahead of time so they could review, prepare, and add their own additional topics as required. During the KOM itself, I led the discussion using this document, while my head of administration recorded notes in real-time. We walked through every agenda point, noted decisions, and wrapped up with an “Any Other Business” (AOB) session and a hearty thank you to the team.

How You Should Address Agendas

You should establish a standard, reusable template for your agendas and use it for every single meeting you call. On previous projects, I used Evernote for these types of things, but now prefer Google Docs because it is both shareable and collaborative, allowing attendees to see updates in real-time. That said, the tool doesn’t matter as much as the action of creating the agenda itself; you can use whatever tool fits your workflow as long as you just do it. I also recommend that your template should be simple: include a list of invited attendees, a one-line statement of the meeting’s purpose, and a numbered list of agenda topics starting with “Introductions” and ending with “AOB.” Draft this early, share it with your team for a sanity check, and then send it to your client or stakeholders well before the meeting.

Once the meeting concludes, your work isn’t done. Take the notes recorded during the session—ideally captured by someone else so you can focus on leading the discussion—and clean them up immediately while everything is fresh in your mind. Edit them for clarity and accuracy, ensuring that every decision and action item is clearly captured. Then, send the link or the document itself back to all attendees, specifying that the notes serve as the formal record of the meeting. Invite them to comment with corrections or additions. This collaborative follow-up is vital; it ensures that everyone agrees on what happened and prevents “selective memory” problems months down the road. Remember, if it’s not captured in writing, it’s like it never existed.

Bottom Line

Never host a meeting without a written agenda. It manages expectations, keeps discussions focused, and serves as the permanent record of decisions and assignments. Use a simple template, share it early, and use it to drive the meeting from start to finish. Just do it!

For a design project like ngGONG, typical Level-1 milestones include events such as completing major trade studies, finalizing high-level science requirements, forming key working groups, hiring critical team members, or passing formal design reviews like the Conceptual Design Review (CoDR) or Preliminary Design Review (PDR). For a traditional construction project, L1 milestones might be site groundbreaking, foundations poured, completion of the building shell, or the beneficial occupancy date. Every project is different, but they all have key points where meaningful progress is recognized; i.e., tangible achievements that move the project closer to its goal, and, just as importantly, let the key stakeholders know that the project is hitting its marks.

The NSF requires projects like ours to establish L1 milestones and then to report on them monthly, tracking not only their planned completion dates but also their current status within the schedule. Have they slipped? If so, by how much? This ongoing tracking becomes part of the yardstick against which project performance is measured and reported.

Why Level-1 Milestones Matter

In any large, complex project, key stakeholders need visibility into progress without drowning in details. Level-1 milestones provide that high-level view. They answer the fundamental question every sponsor, oversight board, and funding agency wants to know: “How’s the project doing? Is it on track?”

These milestones also serve an important internal function. They help the project team maintain focus, prioritize work, and celebrate tangible achievements. When a milestone is met, it signals momentum and builds confidence. When a milestone is at risk of slipping, it signifies a type of early warning alarm that allows the team to mobilize resources, adjust plans, or escalate issues before they cascade into larger problems.

How We Select and Establish Milestones

The process of establishing Level-1 milestones begins with the project team identifying major deliverables, decision points, and key events throughout the project lifecycle. For ngGONG, we started by mapping our 10-step Project Management Blueprint process onto the NSF Research Infrastructure Guide requirements, identifying natural inflection points where significant work packages conclude or major reviews occur.

Once we drafted a preliminary list, we shared it with senior leadership and key stakeholders for feedback. This collaborative approach ensures that the milestones are meaningful not just to the project team, but also to those who will track progress and make decisions based on our reports. After internal discussion and refinement, we’ll submit the proposed milestones to the NSF for review and approval. There may be some back-and-forth negotiation. Perhaps the NSF wants additional milestones in certain areas, or finds some of ours too granular or not granular enough. Once approved, these milestones become part of our baseline and will be tracked and reported on in every monthly report going forward.

A best practice is to space milestones at an approximately equal cadence. In the old days, the NSF was content to see 1-2 L1 milestones per year of project; now they’d like to see 3-5 per year. You should also select milestones that fall on or near the project’s critical path—the sequence of activities that directly determines the overall project duration; if one of these is missed, the entire project timeline is likely to slip. By monitoring critical-path milestones closely, project managers gain early visibility into schedule risks and can take proactive corrective action.

Example from the ngGONG Project

For ngGONG, our proposed Level-1 milestones span the entire design phase and reflect the progressive development of our solar observatory network. Early milestones include the formal start of our Period of Performance, formation of the Science Working Group, and completion of the high-level Science Requirements Document (SRD) and Operational Concept Description (OCD) under revision control. Hiring milestones, such as hiring our first post-baccalaureate interns, are also included, recognizing that assembling the right team is foundational to success.

As the project progresses, milestones shift to design and technical accomplishments: drafting systems-level requirements, completing concept designs for major subsystems (telescope assembly, instruments, high-level software, data management systems, site-buildings-infrastructure), and completing major trade studies. Key design reviews (CoDR and PDR) serve as major gates where progress is formally assessed and designs are validated before moving forward. And so on.

Each of these milestones has a planned date and will be tracked in our monthly reports. A standing table will show the milestone name, its baseline completion date, its current forecasted date, and any variance. This transparency keeps everyone informed and accountable.

The Bottom Line

Level-1 reportable milestones are more than bureaucratic checkboxes—they’re strategic signposts that guide the project and inform stakeholders. By handpicking milestones that represent actual progress, align with the project’s critical path, and reflect stakeholder priorities, we create a powerful tool for tracking performance, managing risk, and building confidence.

As we complete our milestone list this week and submit it to the NSF (once the government shutdown ends, that is), we’re not just satisfying a reporting requirement; we’re laying down a roadmap that will help keep the ngGONG project on course for the next several years. Each milestone achieved will be a step closer to delivering the next generation of solar observing capability, and each one will be a story worth sharing in this ongoing diary.

Managing all these documents starts with establishing ownership. Every document needs an accountable person for drafting and delivery. From this first draft, the paper moves through rounds of review, edits, formal sign-off, and—finally—official submission. Sometimes this process involves a handful of simple steps, but serious documents can require dozens of sign-offs or approvals. And when you multiply all these approval steps by the number of documents created, you can quickly find yourself underwater.

An example of this is the ngGONG Design Execution Plan (DEP). The National Science Foundation (NSF) mandates that every project have a detailed execution plan, and the NSF Research Infrastructure Guide (RIG) sets specific expectations and formats. In the ngGONG proposal, the DEP was in reasonably robust shape, though we acknowledged a few sections needed updating upon award funding.

Well, funding has been awarded, and now the DEP must be updated. It also means that the document needs to be routed through an internal review process, and then submitted using the NSF’s prescribed workflow. There are a half-dozen or more internal participants in this review and approval loop.

Early in any scientific project, there will be several “important” documents like this circulating. As the project matures, the number of important documents grows quickly, creating a challenge for even the most organized teams.

To keep control over document states—who has to review what, who has signed off, when each step needs to occur, and so on—it’s vital to implement a systematic and controlled process. This can start simple: a Word checklist, a spreadsheet, or, for more complex processes, tools like Jira or dedicated workflow software. For ngGONG, until we bring on a dedicated systems engineer for document management, a Google Sheet is used to track every major document’s progress and approval status. The format is less important than using it with discipline, making sure every critical party reviews and signs off in the correct order.

Here’s how the best document sign-off workflows succeed:

• Assign clear ownership for drafting and shepherding the document. There has to be one and only one person who “owns” the document from start to finish. For our DEP, that would be moi.

• Define the review order and responsibilities upfront, including all essential stakeholders. Even a relatively simple document like our DEP will require several people to look at it, some more critical than others. It can be time consuming—not to mention disheartening—to edit a document, sign off, and pass it along… only to have someone downstream of you kick it back for major revisions. Give the document to the harshest editors first if you can so that you’re not wasting downstream reviewers’ time.

• Use structured checklists or trackers for each major document. As mentioned above, the tool is less important than the workflow. I took thirty minutes to put together a basic spreadsheet template, complete with drop-downs and places for document links, and then beta tested it with the DEP as our test particle. We’ll make any modifications based on how well the spreadsheet works and move on. Oh, and try to make the process as friction-free for the reviewers as you can; e.g., include clickable links to the documents, insert drop-down menus for statusing, and so on.

• Brief reviewers on the process, due dates, and other expectations to avoid confusion. It’s useful to let people know what the process is, what’s expected of them, and the need-by dates. I introduced the DEP process at our last progress meeting. And we’ll continue with this as the model for future documents as they’re added.

• Follow up regularly to avoid delays and bottlenecks. Contractually, we have 45 days to get our DEP updated, so there’s really no time to spare. Communication is therefore paramount to keep the document moving through the review process.

• Document lessons learned about how well your process is working. Even minor changes to the tool or process can pay dividends with upcoming documents. There’s a Japanese concept called Kaizen, or continuous improvement, that the best projects follow.

Investing a bit of time up front to get the process organized invariably pays off. With well-defined workflows, tools that match the project’s scale, and clear sign-off chains, you can ensure that every deliverable meets requirements and is ready for scrutiny—by internal teams, sponsors, and external reviewers alike.

Getting organized before the document tsunami hits is one of the key differences between struggling and successful projects.

With a few exceptions, we will do the bulk of this design work internally via a team of expert scientists and engineers. We will also have other personnel working on the project, including an administrative assistant, business support, a technical writer, and drafting help. The bulk of these people will need to be hired, which means job descriptions (JDs) have to be created.

Hiring the right people is the number one secret to project success. Don’t believe me? My long-running (now over one decade-long) survey of project managers bears this truth out. By far, the most commonly cited response to the question “what is the most important thing a project manager can do to ensure project success?” is “hire the right/best/most-competent/most-capable/most-enthusiastic people you can.” Yes, I’m paraphrasing a bit, but over 2500+ survey responses, and over 115 in-depth interviews with high-level project managers bears this truism out; hands down, project managers point to the quality of their team members as the single-most important key to success. (Click here if you’ve not yet taken the survey!)

Writing JDs is the first step in hiring the right people. And over the past few days, this task has risen to number one on my urgent-and-important list. So, how am I tackling this job? Answer: mind maps!

Those of you who know me will recognize that I’m a mind-map guy. Pretty much any big (and often small) job I’ve tackled begins with a mind map. For instance, I have to create two presentations for an upcoming review in November, and before firing up PowerPoint, I’ve begun with outlines created in a mind map. But I digress; let’s talk about how I’m creating job descriptions for ngGONG via mind maps.

The Process:

1. Open a New Mind Map. Before I work on a JD, I open a new mind map so I have an immediate place to capture all my thoughts and ideas. Sure, I could start with a text file or a word document or spreadsheet, but I know I’ll eventually end up in a mind map, so that’s where I start. I’m on a Mac, so I’m limited to mind-mapping applications that work on that platform. The good news is that one of the best applications is Apple-centric: MindNode. This software has a very clean interface and is simple to use. I’ve used the software for so long that it becomes an extension of my brain when in use. But there are many other similar applications out there that work equally well. Find one that works and then take a little time to learn how to use it.

2. Think Deliverables. For an engineering position, I like to start with deliverables. I think through the things I want this person to create and/or provide during the project. These all get listed in a giant, unorganized list in the mind map; i.e., my first goal is to simply brain dump and capture my thoughts. For example, I’m currently working on the JD for our Systems Engineer, so I write down things like turning Science Requirements into Subsystem Requirements, creating Optical Error Budgets, producing a Description of our System Architecture, and establishing a list of System Interfaces. For positions like our Admin Assistant, I think of things like managing Travel Plans, creating Meeting Agendas & Notes, and fully organizing and hosting Design Reviews.

3. Categorize & Organize. The next step is to drag related deliverables around in the mind map into logical categories and groups. Combine, delete, split into sub-elements, etc… This is one benefit of a mind map; you simply drag and drop—and then re-drag and drop until you’re satisfied. For my Systems Engineer JD, I started with over 100 individual thoughts about the position. After organizing the list, I ended up with five primary categories of functions and duties, each with 3-6 sub-elements (see image below).

4. Seek Input. Lone wolves fail in project management. Talk to your stakeholders and others in your organization and ask their opinions on what you’ve put together. I promise you that you’ve forgotten something important; I always do the first time through. I’ve also started relying more and more on AI to help; I create a snapshot of the mind-map and upload it to my AI of choice, asking it to review and comment on what I’ve produced, and to suggest any missing elements or possible re-organization of what I have. It’s surprising to me just how good these “assistants” have become. You can’t rely on them to just “write me a JD for a Systems Engineer,” but you can/should have them “review my JD and suggest improvements to it.”

5. Hand-off to HR. In my organization, we have a superb HR person who is fully onboard with my crazy mind mapping methods. She can/will take the file I produce and turn it into HR-approved job description, wrapping all the required legalese and sanitized language around my structured lists, and putting it all into the template that our organization requires. She also reviews/combines my requirements with similar JDs that she already has in her files, bolstering and improving the end product.

6. Review & Finalize. The last step in the process is to put the JD aside for a day or two, and then come back with fresh eyes to review it. Circle back to deliverables and duties. Imagine a day, a week, and a month in the work life of the person you hire on the project. Think through all the things you would expect them to perform, create, and provide, making tweaks to the JD as required.

Then we move on to finding, interviewing, and hiring the perfect person to match the JD. How hard can that possibly be? It’s only the single-most important ingredient to project success:-)

Besides the terms “Assumptions Log” and “Information Document,” this is also known in various industries as a Scope Statement, a Planning Document, or even just an “Info Holding” document. Back in my formative years in the aerospace industry in the eighties, the term we used for this kind of document was RAID (for Risks, Assumptions, Issues, and Dependencies) or sometimes BRAID (for Background, Risks, Assumptions, Interfaces, and Decisions).

What’s In An Assumptions Log?

Whatever you call it, an assumptions log serves as a place to capture—and argue over—what the project is and isn’t. It’s a temporary holding document for collecting all the initial thoughts, ideas, information, boundary conditions, interfaces, plans, issues, and decisions on a burgeoning project. When things get written for the first time in a project, they become real, which means people pay attention. An assumptions log serves to focus early attention and facilitate discussion and (hopefully) agreement on the details and direction of a project.

Remember, your thoughts and ideas for a project aren’t real unless they’re written down. And more importantly, they’re not actually part of the project plan unless your key stakeholders agree with what’s been written. At the start of a project, it’s very common for different people to have very different ideas about how the project is going to proceed, what it’s going to produce, when things will occur, how they’ll be performed, and by whom. That’s where an assumption log comes into play.

An assumptions log is weirdly both temporary and official/formal. But it’s vital for project success as it literally forces everyone to get on the same page. Which is why I created one for ngGONG.

The ngGONG assumptions log is something I’ve been working on for quite a while, but really focused on it over the past 2-3 months. We were given subtle hints and signals from the NSF in July that we *might* be funded with carryover money at the end of the fiscal year (FY), and I wanted to ensure that all my thoughts about the project were documented and made available to others if/when they came on board. We would then use the document to discuss/argue/debate/consider how the project would be organized and run.

What’s In ngGONG’s Assumption Log?

On previous projects, I’ve been an advocate of BRAID categories when setting up a new project. But ever since I’ve refined the Project Management Blueprint (PMB), I’ve begun using it as one of four primary parts of a template for the assumptions log:

1. High-Level Project Overview. First, I summarize the project in an introductory or overview section. What is the project about in broad strokes? For ngGONG, this part begins with a brief description of the name “ngGONG,” followed by sub-sections of:

   1. What is the ngGONG Design Project? This describes what we’re trying to do at a very high level; i.e., replace and upgrade the existing GONG network of telescopes.

   2. Stages and Phases of Work. This describes the NSF project lifecycle, and where the ngGONG design project fits within that framework.

   3. Project Execution Philosophy. This covers things like how we want to build on the success of GONG, the concept of “if it ain’t broke, don’t fix it… but if it is…” and even things about where the project will be headquartered (Boulder, CO).

   4. Award Details / Cooperative Agreement Details. This describes our award amount ($19.04M) broken into base amount ($16.5M) and contingency ($2.6M), and period of performance (10/1/25 through 9/30/28).

2. The PMB Components. Second is the basic planning elements, broken up into 10 components that correspond to the 10 steps of the PMB—and, not coincidently, the ten components of what the NSF now requires in a project execution plan, or PEP—albeit, slightly re-ordered and arranged. These elements address:

   1. Who are the key stakeholders? This includes both external and internal stakeholders that I know need to be involved in the project.

   2. What are the overarching goals and objectives of the project? This is basically the Mission Statement, and I use the POKR (Purpose, Objectives, & Key Results) method to formulate it.

   3. What are the high-level deliverables? This essentially is level 2 of the work breakdown structure (WBS), which has 10 elements on ngGONG: Project Management, Science Support, Systems Engineering, EPO/C, EH&S, Site-Buildings-Fitout, Telescope Assembly, Instruments, High-Level Software & Controls, and Data Management.

   4. What are the quality acceptance criteria (QAC) for those deliverables? As this is a design project, the acceptance criteria include things like drawing standards, building codes, and the like.

   5. How will the deliverables be created and provided? On ngGONG, we intend to hire a team and do most of the design work internally to the project, but there are also a few external contracts with outside contractors we expect to place. This section describes the major procurement approaches for each.

   6. How will the project be staffed and controlled during execution? This section describes resource management and plans for each of the four basic elements of project controls (Direction, Measurement, Change, & Reporting/Documenting).

   7. What is the schedule for the work? This section describes what we know about the schedule (which isn’t yet fully built), key reporting milestones, and other thoughts and plans about what the NSF calls an Integrated Master Schedule (IMS).

   8. What is the time-phased budget for the work? This section describes how we did cost estimates for the design project, what the current numbers are, and how we’ll estimate costs for design completion and construction.

   9. What are the primary risks the project faces? This section describes high-level risks, our plans for a risk register, how contingency was established, and how it will be controlled during the project.

   10. How will the project be closed out at its (hopefully successful) conclusion? This section describes initial plans and thoughts on project closeout, including the NSF’s three categories of Technical, Administrative, and Programmatic closeout.

3. Specific Scope Details, Plans, & Thoughts. Third is any specific detailed information, thoughts, studies, or other prior work tied to each of the major deliverables of the project (listed by WBS if you have one at this point in the process). For example, on ngGONG, I have 10 sub-sections here, ranging from Project Management through Data Management Systems. For instance, we will have a telescope light feed assembly. There have been several conversations and mini-workshops held on this part of the observatory, so all of that information and conceptual work gets captured as a starting point for planning and discussion. I’ve also included sub-deliverables I think will be part of this larger deliverable, thoughts on quality acceptance criteria for the design of this element (e.g., drawings standards to use), how the sub-team should be established and what other resources are required, a detailed “swim-lane” diagram showing the basic steps required to produce each sub-deliverables, a breakdown of the sub-budget for this area, specific risks associated with this area, and some initial doodles and sketches of a reference design, and so on…

4. PMO Tools and Methods. The fourth area describes the various project management office (PMO) nuts and bolts, ranging from how I foresee document creation/storage/backup, communications, how action items will be handled, what preferred project management control system tool we’ll use (i.e., Dash360), what schedule and budgeting tools we will use, and what types of engineering design tools we should expect to use.

How is ngGONG’s Assumption Log Created?

In a sense, this assumptions log is my brain dump about the project. Until now, it’s really just been a couple of us working on the project, but as we bring people onboard we want them to understand the overall thoughts and approach about the project—but we also want them to have a hand in shaping this approach. Said more plainly: the assumptions log is a so-called “living” document that should morph and adapt as team members and stakeholders weigh in. It will be made available to everyone on the team and to the stakeholders. And wherever possible, these people should help us write and update the thing, or at least relevant sections of it. One of the key functions of the document is to get everyone up to speed on the document, to hide nothing, and to ensure buy-in.

The ngGONG assumptions log was created in Google Documents using the “tab” feature that stitches together several “sub”-documents and displays them in an ersatz outline on the left side of the window. There are other ways to create this, ranging from just a big text file or a Word document, to detailed spreadsheets, to something like a series of web or Confluence pages. I have seen each of these approaches work well; the tool doesn’t matter nearly as much as the contents.

A key feature (and problem) with this document is that it serves as a launch pad for other, more permanent and formal documents like the WBS and Schedule. As those things take on lives of their own, we have to continually come back and update the assumptions log to keep pace with these documents. We do this until the bulk of the staff is hired and brought up to speed. Eventually, the assumptions log gets mothballed… but for now, it’s a guidebook for the project that gets everyone onto the (literal) same page.

The Bottom Line:

When planning a new project, your thoughts and ideas about the project are just that: *your* thoughts and ideas. Until these things are written—and then discussed and agreed upon—they’re not official plans. Write all your thoughts and assumptions down. Get others to do the same. Discuss, debate, and document… and then turn all these assumptions into actual plans.

For instance, if hiring an assistant would allow you to offload half your workload, then that might rise to the most important task today. Or maybe you should focus on creating a report template that can be used repeatedly; sure, it’s going to take a little extra time now, but having this tool is going to pay time dividends in the future. These kinds of tasks are “important.”

But the important is always at war with the “urgent.” If your boss asks you to drop everything and work on X, you often have to do so. But you also have to learn if/when/how to push back on this. The same is true for your email inbox, which I think of as someone else’s to-do list. Finding the balance is key to getting meaningful work done whilst maintaining one’s sanity.

Case in point: I once had a boss who would come in every day, having had some spurious thought in the shower, and declare we drop everything and do whatever he’d thought up that morning. Rarely were these tasks actually important, but they were “urgent,” as in the boss wanted them done. (The secret we all learned was to simply wait him out, as he’d (a) invariably forget what he’d asked; and (b) come up with something new the following day. Sigh.)

So what’s this have to do with the ngGONG project? Answer: I have dozens of action items and things I could focus on to standup the project. Some of these are important, some urgent, and some fall into both categories. Worse, until now I’ve been capturing these things in various locations. We have a formal project to-do list that we’ve created in Jira, but I’m reserving that for significant action items that the team must focus on. We’ve also held three weekly progress/status meetings thus far, and there are action items buried in those notes. Additionally, I keep a lot of my own notes and reminders in Apple Notes, and invariably there are action items I recognize when jotting down those things. Plus, there are countless emails, texts, and Slack messages, some of which contain to-do items. And so on.

To be honest, this was getting a little out of hand, so a few days ago I spent a few hours scouring all these different locations and made a main list of things that we had to do. I’ve teased out all the ones that need to be assigned to team members, and those will end up going into Jira. For myself, however, many of the things I have to accomplish don’t really rise to the level of formal tracking in that project list. Ergo, I am keeping my own “secondary” list of actions in a productivity app (i.e., Todoist, which is my favorite of many I’ve tried).

I started by simply writing everything down in a single, un-sorted list. Then I used the Todoist’s “priority” labels to sort the important from the not. And then within each of those categories, I determined whether the action was urgent, and dragged the most important to the top of those individual sub-lists. Finally, I took a brief pause and came back and viewed everything through the One Thing lens; i.e., is there something on the list that, if I did it now, would make future work easier or unnecessary?

For action items that I’ve done everything I can do, and I’m waiting for others to act, I keep them at the top of the list so that I don’t lose track of them. At the end of every day, I review my list, add/subtract new/retired actions that have arisen and/or shown up in my inbox, and re-prioritize using urgent-vs-important and the concept of The One Thing as my twin guiding beacons.

The power of thinking this way is that the next day I know immediately what needs to get done, and in what order. At any moment in the project, there is One Thing I should focus on, period. And after it, there is the Next One Thing. And so on.

As you can see from the partial list above in the image, my One Thing task is to get the Project Management Controls software we’re going to use under contract and under way. But I’ve done everything I can do on that, and I’m now waiting for our procurement department to place the order. The next thing on my list is to ensure the NSF is okay with our proposed monthly report template, as I’ll have to write that document soon, and I need to ensure we’re creating what the NSF needs; I’ve sent this off, but because of the current government shut-down, I’m in a holding pattern waiting for feedback. The next thing on the list for me to work on then is the hiring process. Said another way: I know what I have to work on today. If I progress that work to a natural stopping point, I’ll simply move down the list to the next item.

I encourage you to get your own project action items organized this way. It’s very easy to drop an important ball if you’re not organized in this manner. I prefer Todoist (it has a free version, but I pay the $50 a year for additional features) but there are dozens of similar apps available. You can also resort to a single list in a notes app, a spreadsheet, or whatever works for you. The key is to write everything down, sort by true prioritization, focus on the task at the top of the list, and then move on to the next item.

The good news? Recently, my organization received a formal award notice (along with $19M in funding) from the National Science Foundation (NSF) for a design project. Specifically, the design of the ngGONG solar observatory network of telescopes. The stated objectives of the project are to create preliminary-level designs and specifications for the observatory and all of its subsystems, and create the components of a proposal for constructing the observatory (e.g., schedule, cost estimates, procurement plans, risk identification, etc...) It’s an exciting occasion for us, and one that we’ve been working toward for years.

But here’s the bad (or better stated, “sobering”) news: now we actually have to do the work. What was yesterday an exciting possibility on a blank sheet of paper is today a very real responsibility—and correspondingly huge set of action items. Expectations are high, and our detailed roadmap to project success is not yet fully developed. Said more simply: we now have to organize and “stand up” the project, complete the detailed plans, hire and onboard an entire project team, and then execute on time, on budget, and create all project deliverables.

With an immovable three-year deadline and fixed budget, we don’t have any free time to waste. Therefore, one of my first acts as project manager was to create an “assumptions log” (a/k/a “information document”). This is a big, living document that serves as a temporary repository for everything we know (and don’t yet know) about the project. As we progress deeper into the planning of the project, this document will serve as source material for more formal project items, such as the WBS, schedule, and budget.

I organized this document around the Project Management Blueprint (PMB) 10-step process, expanding it with design thoughts and next-action logistics. The document acts as a “launch” device that bootstraps the project, brings new hires up to speed, and helps—from day one—to manage the expectations of both internal and external stakeholders alike. The document defines what is what (and what is not) at the start of the project.

I created the document in Google Documents (using its new “tabbed” feature, which allows one to stitch together a bunch of separate documents into a cohesive whole). I then shared the document with key stakeholders and team members, and then held a kick-off meeting with them to bring everyone up to speed, update the document with real-time feedback, and set the project in motion. (In an upcoming post, I want to dig a little more deeply into this “information” document, as I believe it’s an under-utilized, but very powerful, tool that can give you and your project an immediate leg up on the workload.)

Besides creating that document, I’ve also been working with our IT department to set up a structured project Google Drive, which will serve as a single-source-of-truth repository for all project files. I’ve created an action-item “to-do” list (using Atlassian Jira) to assign and formally track actions. Plus, I’ve created draft templates for a variety of requirements documents, organized standard meeting note formats, drafted our WBS, created a template for our monthly report to the NSF, worked with our business group to set up charge accounts and timesheet codes, scheduled a series of weekly progress meetings with the team, etcetera, etcetera, ETCETERA! The list of things needed to “stand up” a project like ours is huge, but we’re chipping away at it piece by piece. This is how elephants like ngGONG get eaten: one bite at a time.

Throughout all this initial work, discipline and standardized processes/templates are my guiding beacons. The Project Management Blueprint method that I teach is being put into practice, and it has to be more than just a list of boxes to check; it’s how I’m (hopefully) going to ensure our project foundation isn’t just solid, but adaptable enough to withstand the inevitable curveballs we know are coming our way. The process begins with getting the project organized and formally documenting project stakeholders, and then progresses through clarifying high-level goals and objectives, capturing the full scope of deliverables in a WBS, defining acceptance criteria for that scope, planning procurements of the scope, establishing resource and project controls methods, building a comprehensive integrated master schedule and a credible time-phased budget, creating a complete risk register, and even planning for closeout.

This is the first blog entry in what I intend to be a public diary of the ngGONG project. I hope to make this journey transparent—with all its ups and downs—for other project managers, team members, and anyone curious about what it really takes to launch something of this scale. The hardest part of any project is getting it off the ground the right way, and that’s exactly where this story begins.

So hang on for what I’m sure will be a host of upcoming good-news/bad-news posts! Wish us luck as we stand up this important new project!

This is how projects can derail: stakeholders are initially consulted, but then left out of the conversation and ignored until it is too late. Stakeholder amnesia shows up whenever teams mistake official project approval for genuine consensus, and when “close enough” replaces the hard work of clarifying (and continuously confirming) all user needs, environmental requirements, regulatory hurdles, and operational constraints throughout the life the project. And this nearly always leads to rework and disgruntlement. Said more plainly: unhappy stakeholders.

Getting it right demands more than a kickoff meeting and a handshake. Successful project management calls for identifying all relevant stakeholders, building a living stakeholder register, uncovering their wants and needs, mapping requirements to specifications, and coming back to these stakeholders each time the design or plan evolves—even a little. It requires asking not just “Who’s paying?” but “Who installs, touches, uses, services, and is affected by this machine?” Only then can teams uncover and act on critical needs, and avoid expensive, embarrassing surprises when the hardware shows up.

When stakeholders are engaged both upfront and continuously throughout the project, things move more like clockwork than chaos. The widget fits without last-minute rewiring. Operators see familiar controls, including a custom shield that meets their safety needs. That’s not luck. That’s the discipline of never forgetting who the project is really for.

"[Starting a Project] without clearly defining what needs to be delivered is like embarking on a journey without a map—you might reach a destination, but it's unlikely to be the one you intended." — Anonymous

In the last couple of posts, I gave some examples of identifying stakeholders and establishing the project's mission. In today’s piece, I want to continue with some examples of establishing and documenting the deliverables, or scope, of a project. This step answers the question: "What exactly is the project supposed to create and/or provide?"

Defining—and, yes, documenting—the "what’s" of a project in a work breakdown structure is essential for its success. Project success literally begins with defining what success actually looks like. Without an approved WBS, no one can be certain what we’re building. A WBS provides clarity for the team, manages stakeholder expectations, and helps prevent future scope creep. Let's revisit our examples to illustrate how defining the "what’s" shapes an entire project:

Example A: Let's Bake a Cake

For a cake baking project, the "what" may go beyond just producing an edible dessert. It involves establishing what will and won’t accompany the cake. For instance, let’s imagine we’re baking a birthday cake for a child’s party at a local park. Do we also have to supply candles for the cake? What about paper plates and plastic forks? Napkins? Any other utensils we must provide, such as a knife to cut the cake and/or a serving spatula? Will we deliver the cake in a box or a plastic cake container? Will the cake go on a cake stand at the party? Do we have to supply any other decorations? And so on…

This WBS approach may seem like over-kill for such a simple project, but imagine showing up at the park without plates, forks, and napkins—and no one else brought those things either. Even on a simple project like this, a written list of what you will—and won’t—provide is essential for managing expectations—and therefore ensuring a successful birthday celebration.

Example B: Let's Write a Book

Like the cake example above, defining the "what’s" of a book project can extend far beyond just writing its text. What else are we responsible for? For example, as the author, are we also tasked with getting the book copy-edited before submission? What about cover art? Illustrations? Publishing formats? Front and back matter? Author bio’s, marketing information, book signing events & tours, and so on…

As most published authors will tell you (this one included!), writing the text is often only just half the battle. Before signing a book contract with a publisher, you need to ensure you and they are on the same page (pun intended) re: who is doing what.

Example C: Let's Design a House

The "what" of a house design project often, but not always, involves drawing and specifying all the elements and systems that will make up the completed structure. Your job as project manager is to ensure you’ve captured all elements that the project is required to provide. This may or may not include such things as A&E drawings, structural designs, electrical schematics, plumbing layouts, interior plans and specs, etc.

Further, each of these might include sub-deliverables. For instance, "Architectural plans" might break down into deliverables like site analysis, conceptual design, detailed design, and construction-ready documents. Are we supposed to provide some or all of these as part of the house design? The project may also be tasked with providing all the required documentation for obtaining building permits—and maybe even submitting and chasing those permits. Further, so-called “as-built” drawings and specs that are created and updated after construction may be your responsibility. Without a clear, documented, and agreed-upon WBS, we and our stakeholders are left assuming we each know what the other is thinking and expects.

Example D: Let's Go Nuclear!

The "what" of constructing a nuclear power plant is incredibly complex, involving many systems, structures, and components. I won’t attempt to create a complete WBS for this kind of project, but at a very high-level, it may look something like this:

Now, of course, each of these would be extensively subdivided and detailed. For example, "Reactor systems" might break down at the next level into components like the reactor vessel, fuel assemblies, control rods, primary coolant system, and so on. And each of those would likely be composed of even more sub-deliverables. A nuclear power plant isn’t a birthday cake, but they both need some kind of WBS to ensure a mutual understanding of what success looks like.

Bonus Example: Inertial Simulator

Reflecting on my botched inertial simulator project, a well-defined WBS could have prevented many of the missteps. Instead of just jumping in and making a hash of the project, taking the time to create a WBS would have helped me focus on the right things and in the right order.

If I had created a WBS back then, it probably would have included mechanical systems, electrical controls, safety systems, lifting and handling, documentation, and so on:

At a minimum, a detailed breakdown would have helped me understand the need to consult with various stakeholders, gather complete requirements, consider lab space and transportation constraints, and address safety concerns from the outset, rather than waste all the time I did.

The Bottom Line:

Establishing a clear and comprehensive WBS for your project is crucial for success. Whether you're designing a house or building an inertial simulator, starting with a well-defined and documented listing of the "what’s" sets the foundation for project success. It provides a roadmap for what needs to be delivered, helps in acquisitions planning, resource allocation, stakeholder interactions, and ensures that nothing important is overlooked. Without this critical document, you may eventually get to the project’s end only to discover the destination is one that nobody actually wanted.

(PS: And don’t forget a written WBS Dictionary to accompany the work breakdown structure; without this document, the WBS is just a list of things without proper context.)

"[Starting a Project] without a clear purpose is like setting sail without a destination—you might enjoy the journey, but you'll never know if you've arrived." — Anonymous

In our previous post, we gave some examples of identifying stakeholders when initiating a project. Now, let's continue looking at those same examples via the next crucial step: establishing the project's mission statement, which will answer the question of "Why are we doing this project?"

Understanding the "why" behind a project is fundamental to its success. It provides direction, motivation, and a benchmark against which all decisions can be measured. Let's revisit our examples to illustrate the importance of defining the "why,” including how this can shape the entire project:

Example A: Let's Bake a Cake

When baking a cake, the "why" goes beyond simply creating a dessert. Is it to celebrate a special occasion? To showcase your baking skills? To experiment with new flavors? Each purpose will lead to different decisions in the cake-making process.

For instance, if the cake is for a child's birthday party, the "why" (a/k/a the “mission”) might be "to create a fun, colorful, and delicious centerpiece that will delight the birthday child and impress the guests." This mission statement would clearly guide decisions about the cake's design, flavors, and decorations.

In contrast, if the cake is for a chic, high-end wedding celebration, the cake requirements will be quite different. The same is true if the cake is for someone retiring from their job, but they have severe food allergies that must be accounted for. And so forth. Regardless, all of these types of decisions will be driven by the “why” behind the cake project.

Example B: Let's Write a Book

The "why" behind writing a book can also vary. Is it to inform, educate, entertain, inspire, or perhaps something else? Maybe it's to establish yourself as an expert in your field; i.e., serve as a type of “business card on steroids” that you can point to. Or maybe it’s simply to fulfill a lifelong dream to say you’re an author. If you're writing a self-help book, your mission statement might be "to provide readers with practical, actionable advice that can significantly improve their lives."

Truly understanding the "why" behind a book can and should influence your writing style, the examples you choose, and even the book's structure and outline. Who is the book for—and why do they need it?

Example C: Let's Design a House

The mission of a house design project typically extends beyond simply creating a shelter. Are you designing for comfort, sustainability, luxury, or practicality? Is the goal to create a forever home for a growing family, or a minimalist retreat for a single retiree? For a sustainable home project, the mission statement might be "to design an energy-efficient, environmentally friendly house that minimizes carbon footprint while maximizing comfort and functionality."

Knowing who the house is for—and then why they want it—will drive the majority of decisions, ranging from location, to materials, to energy systems, and, of course, the overall size and layout of the house.

Example D: Let's Go Nuclear!

The "why" behind constructing a nuclear power plant is complex and multifaceted. Is it to meet the growing energy demands of a specific region of the country? To reduce the nation’s reliance on fossil fuels? To boost the local economy? Maybe all of these things. Perhaps it’s a research reactor, where medical isotopes will be created for experimental treatments.

A simplified power plant mission statement could be "to provide a reliable, long-term source of clean energy that will meet the region's growing power needs while contributing to national energy independence and environmental goals." This purpose would obviously guide decisions about the plant's capacity, location, and technology choices.

Bonus Example: Inertial Simulator

In my last post, I brought up a real world project management example in which I had no clue in what I was doing. And as I alluded to, I think this was deliberate by my boss; i.e., he wanted me to fail so that I could learn—and the first lesson I absorbed was the importance of identifying my stakeholders—which I initially ignored. The second hard lesson was this one: the importance of establishing a clear mission for the project.

In hindsight, I can clearly see how a definitive "why" could have prevented many of my initial missteps and wasted time. A mission statement might have been something like "to create a versatile, accurate testing platform that enables control systems engineers to safely validate satellite control algorithms across a range of simulated satellite sizes and behaviors." This clear purpose would have immediately highlighted the need to consult with the aforementioned control systems engineers, consider all design parameters, and address safety concerns from the outset. My failure to do this up front cost me weeks of wasted work—and more than a little embarrassment. Sigh.

The Bottom Line:

Establishing a clear and compelling "why" for your project is as crucial as identifying its key stakeholders. The mission provides a north star to guide key project decisions, helps align team efforts, and, most importantly, ensures that the final deliverable meets its intended purpose. Whether you're baking a cake or building a nuclear power plant, starting with a well-defined mission statement sets the foundation for project success. Keeping the "why" at the forefront ensures that your project remains relevant, valuable, and on track to deliver meaningful results.

“[Starting a Project] without the audience in mind is like writing a love letter and addressing it to ‘to whom it may concern.’” — Ken Hamer, AT&T

Over the past couple of months, we’ve looked at the various Initiation/Planning steps of a project. To help clarify and put a bow on all of this, I now want to look at a few examples that illustrate the steps, ranging from the absurdly simple to the highly complex: a) baking a cake; b) writing a book; c) designing a house; and d) constructing a new nuclear power plant.

As we saw, the first step of any project is establishing Who are the stakeholders, especially the so-called “key” stakeholders. Who wants and/or needs this project? Who will use it? Who is paying for it? Who is the customer? Said another way, who has a strong, positive interest in the project, and of these people, which have powerful influence or power of the project? That is to say: Who are we ultimately trying to serve and satisfy with the project?

Example A: Let’s Bake a Cake

Imagine we’ve been asked by a friend to bake them a cake. Before we run out and buy ingredients and start warming up the oven, we need to establish some basic information. First of these is uncovering who the cake is for. Who will eat the cake? Who is paying for the cake? Who wants or needs our cake? If this is an event like a birthday party, who is the host/organizer? What guests will be there?

Taking the time to understand this will help immensely with all the other Initiation/Planning step questions, such as how important this cake is, what type of cake it should be, how we should make it, when it’s needed, and so on. Is this cake for someone’s birthday, a wedding, or a retirement party? Or does our friend just want to eat a cake for no other reason than they’re craving one?

At the heart of these questions is understanding who wants the cake. Is the cake for a child with severe food allergies, a bride and groom with strong “buy local” beliefs, or an elderly relative who loves all things chocolate? And who else will eat the cake at each of those events? We cannot plan the creation of a cake without starting with the fundamental question of who will eat it.

Example B: Let’s Write a Book

If we’re writing a book, we should always start with who we’re writing it for. Who will read and consume the information? A fiction romance novel written for a feel-good seeking homebody will differ greatly from a non-fiction technical how-to book. The same applies to a memoir written for public consumption, or a private collection of diary entries that is intended just for ourselves or close family members.

We can’t write a useful book unless we fully understand who wants/needs it. And we also need to identify other key stakeholders, such as agents, publishers, editors, et al. Who will proofread the book? Are there marketers that have to be consulted with? Booksellers that need to be considered? Will we have a co-author? And so on.

Like the cake example above, to make our book writing project successful, we must start with the book’s stakeholders.

Example C: Let’s Design a House

Like the previous examples, a house design project should always begin with identifying and documenting the key stakeholders. Who is the house for? Is the project to deliver generic tract-housing for a subdivision, or is it a bespoke project for a specific family? We won’t be able to establish even basic things like the size or style of the house until we take this step.

Further, we need to identify other important stakeholders, such as neighbors (e.g., is there a homeowners association with design rules we must abide by) and local government and permitting agencies (that will have their own specific code requirements we must meet). We cannot start the design of the house unless those stakeholders are identified and, later, interviewed and interrogated.

Example D: Let’s Go Nuclear!

Finally, let’s imagine we've been tasked with constructing a new nuclear power plant. While clearly more complex (and serious) than our cake, book, and house examples above, the same basic principles apply. Before we can begin the design of the power plant and build/buy reactor components, we need to establish some fundamental information. Foremost is identifying who the key stakeholders are. Who will benefit from this power plant? Who is funding the project? Who wants or needs this energy source? Which regulatory agencies are involved? What communities will be affected? And on and on and on.

Taking the time to identify the project’s stakeholders will help immensely with all other initiation and planning steps, such as determining the plant's capacity, choosing the reactor technology, deciding on the location, and establishing the project timeline. Is this power plant meant to replace an aging facility, meet growing energy demands, or transition to cleaner energy sources? Or is it a research reactor designed to advance nuclear technology? At the heart of these questions is understanding who wants and needs this power plant.

We cannot plan the construction of a nuclear power plant without starting with the fundamental question of who will be impacted. Is this plant for a rapidly developing region with increasing energy needs, a country aiming to reduce its carbon footprint, or a remote area lacking reliable power? And who else will be affected by the plant's construction and operation? From local communities and environmental groups to regulatory bodies and future plant operators, each stakeholder brings unique perspectives and requirements that must be carefully considered throughout the project lifecycle.

Bonus Example: Inertial Simulator

I’d like to close out this post with a real world example that I was directly involved with. This was the very first project that I was ever put in charge of. Or, I should say, it was a project I had no business being in charge of. See, I’d just graduated with a shiny degree in mechanical engineering and was starting my career as an aerospace design engineer at Lockheed. My boss (who, in hindsight, was an amazing mentor) basically set me up to fail—and learn. He threw me into the deep end of project management and watched me struggle and sink. Let me explain.

The project centered on designing and building an inertial simulator. Imagine an Olympic barbell and weight plates mounted to a vertical shaft that could spin on bearings. The shaft was driven by an electric motor, and rotational position measured by a digital encoder. The purpose of the device was to test satellite control systems. We could bolt on heavy plates to simulate a large satellite, and then see how well a control system could drive, position, stop, and reverse the spinning barbell. We’d then remove weights and test its ability on a smaller simulated satellite.

My boss explained all of this to me in his office (along with some basic engineering criteria)—and then sent me on my way. As a design engineer, I rushed back to my office and begin sketching up ideas—in total isolation. Then I booked a CAD station and went to work fleshing it out. I picked a motor, bearings, encoder, nuts and bolts and so on from a catalog. I designed and analyzed the bar and weight plates and support stand. I even ran a couple of simulations. A few weeks later, I proudly took my design drawings into the boss’ office and showed my work.

He immediately deflated this pumped-up engineer by asking a couple of simple questions: What did the controls engineers think of it? Uh, I didn’t talk to them. Did I consult with the lab manager to ensure the unit would fit in the available space? Uh… What did the safety group think of it? Well… What about the machine shop personnel? And so on.

I got carried away with the excitement of designing something new without first talking to the people that would build it, assemble it, and test it. They were my customers, and I had (stupidly, in hindsight) never really considered their needs. My boss had given me some design parameters, but now I recognize they were just part of the requirements. To really understand the needs of all these people… well, I first had to identify them. And then talk to them. And document their wants, needs, requirements, and constraints.

The Bottom Line:

Stakeholder identification is the first crucial step in initiating and planning any project, as it helps ensure all relevant parties are considered throughout the project lifecycle. Even a simple cake-baking project clearly has stakeholders that must be satisfied. And that means we must first identify those stakeholders. Failing to identify even one key stakeholder until late in the process can have major deleterious effects. You and your team will waste effort, time, and money. You’ll also harm project morale and potentially insult some key stakeholders. Trust me: this is not a good place to find oneself; i.e., with a with a design for a spinning barbell that no one is happy with.

So we’re done planning, right?

Uh, nope. In fact, our first pass through the Initiation/Planning steps is just that: the first of several times we loop through the questions. We call this looping or iterative process “progressive elaboration,” and it’s a powerful technique to plan or create most anything. If we’re designing a house, for instance, we don’t start by choosing the type of kitchen faucets on day one. Instead, we begin with getting clarity on the overall size and shape of the house, the number of rooms, the general layout, and such. We work with our stakeholders and agree on those elements before moving onto the next round of detail questions. And then we repeat the process, looping back and adding details to the project. We start with big picture questions, agree on those, and then add the next layer of granular detail.

Progressive elaboration ensures we’re not wasting time or having to go back and re-do/re-work project decisions. It lowers the overall risk of the project, helping us discover threats earlier in the process and allowing us to mitigate against them. It enhances flexibility of designs, as we can make big changes earlier without impacting many downstream design choices. And it helps with stakeholder engagement and buy-in; involving stakeholders early and often helps them become part of the solution, and not just naysayers we have to do battle with.

Whether you call it progressive elaboration, iterative refinement, continuous improvement, rolling wave planning, or just design looping, this is a highly useful technique to learn and employ. Performing design work, building schedules & budgets, identifying risks — essentially all aspects of project management can benefit from this approach. When constructing a work breakdown structure, for instance, we shouldn’t focus on small subcomponents until we first decide (and agree) upon the larger, overall deliverables and how they’re arranged. Then we can add in kitchen faucets when its appropriate.

Project success depends on us and our teams being both efficient and effective in our work. Progressive elaboration provides another powerful tool to help us get all the required work done in the most productive way we can. Said another way: learn to love the loop!

Budget contingency is exactly what it sounds like: extra money set aside to pay for problems as they arise. Similarly, schedule contingency is a reserve of time available to accommodate delays and schedule slips. Scope contingency is identified as deliverables that, in a worst-case scenario, may be foregone in favor of staying on schedule and budget. And quality contingency are some specific requirements (e.g., functional or performance specifications) that might be dropped in favor of one of the other forms of contingency.

Contingency is often described as the other side of the risk coin; the two are separate concepts, but are intrinsically linked. There is always risk on a project, and something invariably goes wrong. Without contingency, we won’t be able to keep our project on track to a successful conclusion. A weather delay causes us to push back a series of activities in the schedule, which then costs more money than we’ve budgeted. Contingency reserves are how we pay for these types of things as they occur.

So, how do we ensure we have sufficient contingency reserves? Let’s look at each of the four categories to see how it works:

• Budget Contingency. Typically, budget contingency is a function of total monetary risk exposure. If you recall from our discussion of risk, risk exposure is the product of a risk’s likelihood (probability) and its impact if realized. The summation of all the individual risk exposures listed in our risk register is one way to estimate the overall risk exposure of the project. Ensuring our budget contingency is larger than this number is usually a good place to start in estimating how much reserve money is required. Other methods include performing a Monte Carlo analysis of the risk register or the budget. We can also use various algorithmic methods, such as risk factor analyses.

• Schedule Contingency. We can estimate how many days or months of reserve we should carry by a variety of methods. The simplest of these are with standard rules of thumb. E.g., 1 day of contingency for every two weeks of project duration, or 1 month for every year of schedule. But there are also more sophisticated methods that can give more realistic estimates, such as running a Monte Carlo on the schedule, with inputs of best case, worst case, and most realistic durations for the schedule activities.

• Scope Contingency. Determining which elements of your WBS might be excluded is best performed in consultation with your key stakeholders. Nobody wants to forego deliverables, but sometimes it’s the best (or only) option. The key is to establish key mission priorities with your stakeholders, and then triage the scope from the most critical to the least. A “de-scope” list is then created, along with impacts, potential cost and time savings, and so on.

• Quality Contingency. Like scope, determining which requirements are less important than others is a task that requires significant input, feedback, and involvement from the customers, users, and other key stakeholders of the project. And again, the mission priorities of the project will be the key drivers of these discussions. Often, quality contingency is captured in the de-scope list.

Successful project management is about planning for the best, but also preparing for the worst. This contingency step is all about providing reserves to cover the “cost” of things when they go wrong on a project. We're not talking about padding our budgets or timelines unnecessarily; instead, we're strategically allocating extra resources—be it budget, time, scope, and quality—to allow flexibility to cover problems when (not if) they arise. It's about the balance between prepared and paranoid. By carefully establishing project contingencies, we're not just hoping for the best; we're actively preparing for success, come what may.

Ignoring risks—or even just not paying attention enough to them—is a common mistake of new project managers. Experienced PMs know better. Failing to perform risk management is essentially the same thing as embracing a “hope management” mentality: you put your head in the sand and simply “hope” things go well. Experienced project managers know this is a doomed approach.

The process of managing threats is straightforward if approached systematically. There are four basic steps we take when managing risk:

1. Identify. The first step is to identify all significant risks and capture them in a risk register, which becomes our central hub for tracking, analysis, and reporting. The key to this identification step is to involve your team and your stakeholders. Solicit individuals for their worries. Host brainstorming sessions. Ask stakeholders what’s keeping them up at night? Look at past/similar projects, assessing what went wrong and right on them.

2. Analyze. Next, assess and analyze each identified risk, considering its likelihood and potential impact on our project. If you have a lot of risks, it often helps to pre-sort the risks based on a cursory “qualitative” assessment before digging more deeply into “quantitatively” analyzing the most serious risks. The goal of this step is to determine which risks we need to pay the most attention to first, much like a doctor triages patients in an emergency room.

3. Respond. The third step is to develop specific responses to reduce the likelihood and/or impact of the identified and triaged threats. Some risks we can’t do anything about (i.e., we just have to accept them), while others aren’t worth applying time or money to lower the threat (i.e., the cost isn’t worth the reward). But often there are useful and cost-effective things we can do to reduce the overall risk exposure of the identified risks. Again, the key is to involve others in the process and not try to do this all by yourself.

4. Rinse & Repeat. Finally, we need to remember that risk management isn't a one-and-done process. To properly manage a project, we need to continuously monitor our project landscape, identifying new risks, retiring old ones, reporting on the current risk status to our team and stakeholders, and keeping our risk register up-to-date. And then do it again.

By proactively addressing risks, we're not leaving our project to fate. We're increasing our chances of success and avoiding the pitfall of simply "hoping" everything will work out. Identify risks, analyze them, respond to the ones requiring attention, and then do it all over again. Risk management is something all successful project managers do. They may hope for the best, but they proactively manage for the worst, too.