Let me explain.

Meet Obi-Wan:

She and I worked together on several projects over the years, and I always considered her one of the more tech-savvy people I knew. Whenever I had a computer problem I couldn’t solve, I went to her first. My nickname for her at the time was “Obi-Wan,” as she’d do what felt like actual magic on whatever tech mess I’d gotten myself into.

She’s been retired for several years now, but she’s still active in professional organizations, volunteering, the whole bit. She’s also married to a software programmer, and her son’s in college.

I’m telling you all this because this isn’t some person who’s afraid of technology, or who’s been left behind by it, or who doesn’t understand it. Which is exactly what made what came next so interesting.

The Declaration:

Somewhere between drink refills, my friend announced — with real conviction — that she’s anti-AI. Extremely anti-AI. She refuses to use any form of it. Full stop.

When I mentioned I use AI pretty much every day (like essentially every working person I know does, in one form or another) she actually shuddered. She told me she’s never going to use it. She’s dying on this hill.

Okay. That’s her right.

But I’ve Heard This Before:

Here’s the thing. This conversation felt familiar. Throughout my life, I’ve heard versions of it before from other otherwise-smart people:

• 80s: “Writing on a word processor isn’t real writing.”

• Early 90’s: A draftsperson refusing to even try CAD software, because it’s not “real” design.

• Late 90s: “I’ll never use email. It’s soulless spam and not real dialog. I’ll always use the phone instead.”

• Early 2000s: “I don’t need a search engine. I have a library card.”

• Mid-2000’s: “I would never use Grammarly. It’s going to miss things. And it creates words and sentences that aren’t me or in my voice.”

• 2010: “Slack will never replace a well-crafted email. I’m not going to use some ‘asynchronous’ message board!”

Look, you can take a “principled” stand on just about anything you want. That’s fine. But at some point, reality stops caring about your principles. You have to ask yourself whether willful ignorance or the refutation of reality is in your best interests or not.

Fine, AI Has Problems:

Let me steelman my friend’s position on Artificial Intelligence for a second, because she’s not wrong about everything.

Are there real dangers with AI? Sure. Is it an unregulated space that can be used for genuinely malicious purposes? Of course. Is it infallible? Not even close. Will it eliminate jobs? Sure, but new jobs will take their place. Will it stop genuine human thought and creativity? It can if you let it. Will it produce confident-sounding misinformation? Absolutely, and that’s a real problem we have to guard against.

But (and this is the part that always gets left out) you could have said every one of those same things about email and CAD and Google and spell checkers when they first showed up. New technology is both scary and messy at first. Sometimes for a long time. That’s not, by itself, a reason to refuse it.

Here’s the Actual Point:

AI is here. It’s not a fad, it’s not a phase, and it’s not going anywhere. Technology changes, evolves, and gets replaced.

This ain’t new.

Rewind back to the late 1800s, when buggy whip manufacturers looked at the horseless carriage and refused to acknowledge it was even a thing. Not “we’ll adapt later.” Refused to acknowledge it.

You can put your head in the sand. You can actively rail against something. Neither of those changes the fact that it’s already here, it’s already now, and it’s already everywhere.

I saw exactly how “everywhere” it is a few days ago when visiting my daughter at her long-term medical care facility. I watched a couple of the nurses’ aides there (i.e., GED-level, minimum-wage staff) putting together genuinely funny, professional-looking videos using an AI app on their phones. Nobody trained them to do this. Nobody had to.

If it’s there, it’s everywhere.

So What Do You Actually Do With It:

Here’s the part that matters more than the rant: the answer isn’t blind adoption, nor is it blind refusal. It’s using AI the way you’d use any other new tool. Hammer. Spell-checker. ChatGPT.

Don’t let it think for you. Don’t trust everything it tells you without checking. Stay in the loop; you’re still the one accountable for the outcome. Don’t get lazy and hand your thinking over to a machine.

Those are the exact same rules that applied to email, to Google, and to spell-checkers when they first came out. There’s nothing new here except the tool itself.

Okay, So How Does This Relate to Project Management and the Blueprint?

Fair question.

AI isn’t a replacement for us Project Managers, nor for thoughtful execution of the Blueprint’s 10 steps. But it is a tool that can help PMs, speeding up our work within frameworks like the Blueprint.

For instance, I’ve used AI to draft a rough first-cut mission statement from a pile of raw stakeholder interview notes (Step 1). I’ve also used it to stress-test a risk register by asking “what am I missing here?” against a list I’d already built (Step 9). In both cases, what I got back was the help and input from a second set of eyes, not a finished answer. It’s really the same idea behind the “strawman” reference design I’ve written about before (here); i.e., a deliberately rough first pass you build specifically so you can react to it and refine it, not something you hand over as final.

The most important part is this: you’re still the project manager. AI can draft, suggest, and accelerate. It doesn’t own the Charter, it doesn’t own the WBS, and it sure doesn’t own the results of the Project. It doesn’t talk to your stakeholders for you. It is not a project management replacement. It’s a tool that project managers can/should/will use.

The Bottom Line:

Like it or not, Artificial Intelligence is here.

Buggy whip manufacturing isn’t.

Draw your own conclusions.

Now, before we begin, a quick bit of context: most of my projects are funded by the National Science Foundation, which publishes something called the Research Infrastructure Guide, or RIG. This is essentially NSF’s playbook for how funded projects should be planned and executed. The RIG specifies 10 components required in a Project Execution Plan (PEP), and while there are minor differences, these RIG components align and overlap with the ten steps of the Blueprint.

That’s great, but the RIG also includes a section next to the PEP guidance that describes a trio of techniques called Tailoring, Scaling, and Progressive Elaboration.

In other words, even a relatively rigid federal funding agency explicitly tells its project managers to use a 10-step framework to plan a project, but don’t implement these steps the same way every time. Fit the plans to the specifics of the individual project. And the secret to doing this is Tailoring, Scaling, and Progressive Elaboration. Let’s look a little closer at each of these:

Tailoring:

Tailoring means choosing the right approach for a given planning step. It’s a conscious, defensible selection you make based on your particular situation. It sounds obvious to select an acquisition approach based on your project’s circumstances, but many new project managers will just jump in, choose the first approach that comes to mind, and not consider other options that might be more appropriate. For example, let’s look at options for answering Step 5: how we will acquire the deliverables:

• DIY Shed: For our shed project, we might immediately assume that we’ll do all the work ourselves. But after investigation, it turns out that having the local big-box hardware store do delivery and installation is relatively affordable. The benefit is they handle all the details, permits, and even assume liability. But they want an arm and a leg to do the foundations. So, we decide that we would dig and pour the foundation ourselves, then hire Home Depot to deliver and assemble the shed kit.

• Telescope: For a big, federally funded project like a new observatory, there will be a myriad of federal acquisition rules that must be followed, including things like the BABA Act (Build America, Buy America) and labor rate compliance. We also need to consider how we’re going to test and accept various components, plus how we’ll assemble them. This will dictate how we split up the work. For some elements, like software, we might decide to staff up and self-perform, but other things, like large optics, will be purchased via competitively bid processes and under fixed-price contracts, and overseen by engineering contract specialists we hire.

The key to tailoring is the pause-and-consider step. Think through the pros and cons of your idea. Then solicit feedback from others. Don’t just jump at the first solution; instead, take the time to consider if the answer to each Blueprint step question makes sense in both the micro and macro sense.

Scaling:

Scaling means choosing the right level of rigor and formality for whatever approach you picked. Get this wrong in either direction and it costs you; too little formality and you can miss problems, but too much and you’re burning budget generating reports nobody really needs. For example, how this might get applied to Step 3, which is establishing and documenting the scope of deliverables:

• DIY Shed: Even for a simple project like this, a work breakdown structure (WBS) is still required, but it can be “scaled” literally to just a hand-written sheet of paper. If we’re the sole key stakeholder, there is no need to go further than this. If, say, however, our significant other is part of the project, we might want to be a bit more formal to ensure there are no misunderstandings about what will and won’t be provided. And if a neighbor will contribute to the project and share space to store his tools, we may want to create a formal typed and signed-off document that formally establishes what will and won’t be built.

• Telescope: For our observatory project, our WBS will have to be much more formal. It will probably need to be documented in professional project management software, formally reviewed and approved by several key stakeholders, including our funding agency, and then formally baselined and placed under configuration control. Things like our schedule, acquisitions approach(es), budget, and even risk management approaches may be tied to the WBS.

The key to scaling is finding the Goldilocks approach to implementing each step of the Blueprint. Sometimes, your stakeholders will require certain approaches and levels of formality. It’s up to you to decide if you need more or less than that.

Progressive Elaboration:

Progressive Elaboration is a process in which we iterate on our plans, starting with big-picture decisions and then adding successive levels of detail. At each pass through the plans, we typically want to get our key stakeholders to agree. Depending on the project, this iteration could be just 1 to 2 passes over the course of a weekend, or it can include dozens or even hundreds of iterative passes and take years to complete. In a sense, progressive elaboration is getting more and more detailed with our plans in a systematic process that builds fidelity in an organized manner. Rather than trying to fully detail everything on day one, we take a rough first pass through all 10 steps, get stakeholder agreement, then loop back and add detail. We repeat this however many times our specific project requires:

• DIY Shed: A simple 1-2 sentence statement of our goals, followed by a hand-written list of deliverables, a rough sketch and plan, then a bit more detail once our spouse signs off, then final plans worked out with Home Depot. Simple, because anything more complex is a waste of time.

• Telescope: For a project of this sophistication and scale, we will probably progress through a series of formal gates, such as Conceptual, Preliminary, and Final Design. We will also likely enlist outside experts, form advisory boards, and hold mini-reviews and check-ins along the way. Each element of the plan will gain detail and sophistication as we progress through the process. By the time we’re ready to construct, we will have a complete set of thoroughly reviewed, formally approved, and baselined plans and documents, all under configuration control and locked down. Any changes to any of the plans or expectations will then be subject to formal approval through change management processes.

The power of progressive elaboration is building a strong and stable foundation before running ahead with finer details. Get buy in at each successive pass through the Blueprint, and surprises and costly rework will be minimized.

The Bottom Line:

The benefits of Tailoring, Scaling, and Progressive Elaboration aren’t just avoiding wasted work, though it does that. It also manages everyone’s expectations along the way, ensuring no one gets blindsided late in the project by a decision or approach they never agreed to. And because stakeholders are part of the process, they feel like they were part of the decision-making, not just recipients of it. That alone makes the closeout go smoother and with fewer surprises.

Tailor the approach. Scale the formality. Elaborate progressively, with buy-in at every pass. Do those three things appropriately, and the Blueprint will fit your project like a well-tailored (and scaled) suit!

Projects work the same way.

A weekend-long DIY project to build a backyard garden shed and an eleven-year, $360M solar telescope design-build effort look like they belong in different universes. Run both through the same planning questions, however, and they rest on an identical structure. That’s the core idea behind the Project Management Blueprint (PMB): every project, regardless of size, is built from the same 10 planning blocks. Only the level of detail, rigor, and formality change.

Shed vs. telescope, on the same 10 steps:

1. Goals & Expectations: Store garden tools by fall vs. resolve 0.03-arcsecond solar features.

2. Stakeholders: A spouse and the HOA vs. the solar physics community and NSF.

3. Scope of Deliverables: A shed and foundation vs. a 4-meter telescope and a suite of scientific instruments.

4. Quality Acceptance Criteria: Passes city inspection vs. sidereal tracking accuracy, code compliance.

5. Acquisitions Approach: Self-perform the slab, hire Home Depot vs. competitive industrial procurements.

6. Project Controls: A phone app and weekly check-ins vs. validated earned value management.

7. Schedule: A long weekend vs. thousands of sequenced activities across a decade.

8. Budget: A few thousand dollars vs. hundreds of millions, time-phased.

9. Risk & Contingency: An extra week and $500 vs. a full year and tens of millions.

10. Closeout: A punch-list walkthrough vs. formal NSF closeout procedures and as-built documentation.

Same ten questions. Wildly different answers.

That’s why “tailoring and scaling” matters so much in the Blueprint. Your job isn’t to invent new building blocks for every project — it’s recognizing that the blocks are fixed, then choosing the right tool and rigor for each. A hammer for a picture nail; a sledgehammer for demolition. Same principle, different job.

So the next time a new project feels intimidating, remember: it isn’t. Underneath the unfamiliar scope and stakeholders are the same ten questions you’ve answered before, wearing a different hat. Recognize the foundation, the framing, the roof — and build from there.

“(Real) risk comes from not knowing what you’re doing.” — Warren Buffett

What’s the Myth:

Almost every PM and Risk Management training program teaches the same thing: when you identify a threat, you have four responses available (a/k/a “treatments”) to consider applying: Avoid, Transfer, Mitigate, or Accept.

This four-response idea is repeated so often that nobody questions it anymore.

But it’s wrong. You don’t have four options. You actually only have two options: accept or mitigate.

Why It’s Wrong:

Every risk is quantifiable by two numbers: probability and impact. This is true for both negative risks (threats) and positive risks (opportunities). Probability is a measure of how likely the risk will materialize (i.e., be “realized”). Impact is a measure of how big an effect, good or bad, the realized risk will have on the project. If you multiply probability and impact, you get risk exposure.

For negative risks, we want to minimize exposure. For positive risks, we want to maximize exposure. In both cases, we evaluate each risk and, where appropriate, strive to change its probability and/or impact. For threats, taking action to reduce probability and/or impact is called mitigation. (For opportunities, taking action to increase probability and/or impact is called enhancement.)

Once you see risks this way, the “four responses” fall apart.

Mitigate means reducing probability and/or impact by some amount, not necessarily to zero. But if we can drive the probability to zero, we’ve actually avoided the threat. For example, our team made a design change that completely removed a technical threat. We’ve made the likelihood of the technical threat zero, so we’ve “avoided” the threat. But this really is just mitigation in the extreme.

Similarly, transferring a threat just means eliminating the impact from your project and putting somewhere else (e.g., onto an insurer, a subcontractor, a partner). The threat is still real, but if it materializes, it won’t impact you. I.e., you’ve driven the direct project impact to zero, therefore “transferring” the threat off your project. But again, this is just mitigation in the extreme.

Both avoidance and transference are just edge cases of mitigation, which by definition is the act of reducing probability and/or impact.

Said another way, Avoid and Transfer aren’t separate categories. Calling them their own responses is like calling a square and a rectangle two different geometrical shapes. A square is just a special type of rectangle (one whose side ratios have been pushed to the extreme). Avoid and Transfer work the same way: they’re no different from mitigation; they’re just mitigation where probability or impact has been pushed all the way to zero.

So, really, there are only two fundamental choices when facing a risk:

1. Accept the risk as-is.

2. Mitigate it (reduce probability, reduce impact, or both).

How to Actually Do This:

When you identify a threat, and after you’ve estimated its probability and impact, you should always ask these two questions in this order:

1. Can/should/must we accept it? If probability × impact is low enough already, it’s probably not worth spending time or money on to make it smaller; just accept it and move on. Sometimes the calculus is more forced: there’s genuinely nothing that will move probability or impact, or the cost of trying to mitigate exceeds the exposure itself. Either way, the answer is the same: accept it and make sure your contingency reserves cover the residual risk exposure.

2. If you can’t/shouldn’t/mustn’t accept the risk, how do we mitigate it? Can we cost-effectively reduce the probability? The impact? Both? Push each as far as you appropriately can. If you can push probability to zero, great, you’ve “avoided” the threat altogether. Similarly, if you can push the impact of the threat on your project to zero, great, you’ve “transferred” it. Either way, you were just mitigating; you simply mitigated hard enough to hit an edge case.

Example:

We’re adding an extension onto a house. A threat has been identified: “If heavy rain occurs on concrete foundation pour day, we would have to cancel the pour and would experience a schedule delay.”

Following the two-step process above, our first question when facing a new risk like this should always be whether we can/should/must accept this risk as-is or not? If the likelihood of rain is low and the impact is just a lost day or two, we can probably just accept the risk as-is. Or, if the cost of rescheduling is high and there’s nothing we can do to eliminate the threat of rain, we might have to accept the risk as-is.

But imagine it’s the rainy season, and contractors are very busy and backlogged. A schedule delay of even one day could lose our spot in the concrete contractor’s work queue, which could turn a one-day rain delay into weeks or months of actual schedule slippage. Here, we need to consider mitigating the threat. If there’s any chance of re-planning our schedule to move this aspect of the work into a dry period, driving the probability toward zero, we should consider it.

Similarly, we could reduce the impact of rain on the work by, say, spending money to build a temporary tarp structure to cover the work, which would allow us to work regardless of the rain. Here, we could drive the impact of rain to zero. We “avoid” the impact, but really we just mitigated it.

Bottom Line:

Okay, I’ll admit that this isn’t really a big deal, and I’m being a little finicky and precious with the terminology… but I believe in using words precisely. This is especially important in our profession of project management. If someone continues to use the conventional 4-responses-to-a-threat approach in their risk management processes, will it matter? Not directly, no, but too often we take things as fact without really understanding what we’re doing. When you say you’re going to avoid a risk, what you’re really doing is simply mitigating it by driving down its probability. As long as you understand that, you can use whatever terminology you want.

Bottom line: we either accept risks or we mitigate them. Everything else is just fancy words for the same thing: mitigation.

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.