“The entire and total purpose of a project is to develop, build, and deliver a predefined thing. How will one do this? What is the plan to acquire that thing?” — T.M. Rahauhn, PE, PMP

We know who wants the project and why, what they want us to create, and how good it has to be. Now, we have to establish how we’re actually going to create those deliverables, along with determining what resources it’ll take to do it. Welcome to Step 5: Establish Scope Acquisition Approach.

Every project is about creating or providing some kind of deliverable, or scope, whether that’s a product, a service, or a result. Knowing what we’re supposed to create is critical, but so is knowing how we’re going to create it. This step comes after scope definition (Step 3) and quality requirements (Step 4), but before schedule and budget (Steps 7 and 8). You can’t settle on how to build something until you know what it is and how good it has to be. And you can’t build a schedule to create it or estimate its costs until you know the acquisition approach: in-house build, off-the-shelf purchase, or bespoke contract. Schedule and budget are downstream of acquisition plans.

Step 5 is where we decide, element by element: build it, buy it, or contract it out. It’s also where we establish QA methods, aimed at minimizing the chances a deliverable falls short in the first place, and separately, QC plans, which spell out how we’ll actually test and accept what comes back against the criteria we established in Step 4. Step 5 is also where we figure out what resources (labor, equipment, and materials) the chosen approaches will take. Here’s why the step is so critical:

1. Scope and quality criteria won’t build themselves. The make vs. buy question is the first time we propose an actual method to acquiring the deliverables. Step 5 is where we decide, per WBS element, whether the scope is to be built in-house, purchased off the shelf, or contracted out, and each path carries a different set of resources, a different series of tasks and activities (and durations), a different cost structure, and a separate set of risks. It also sets us up for Step 6, where we establish how we’re going to perform, measure, change, and status the work.

2. Step 5 defines your team requirements. Resource planning establishes who and what will be needed, along with who’s accountable for what; this is the backbone for everything we create in Steps 6 through 8. Oh, and if we’re going to need specialized tooling, facilities, or other equipment, this step helps us identify those things, too.

3. Acceptance plans can be addressed. QA plans go to work minimizing the chances that a deliverable ever falls short of the criteria we established in Step 4, and QC plans spell out how we’ll actually test and verify it against that bar before we can accept it. Both are part of establishing an acquisitions strategy.

4. Choosing an acquisitions approach allows us to build the schedule and the budget. A contracted item and an in-house build have completely different activity sequences (tasks, logic, lead times, resource needs, durations, approval gates, and so on) and completely different cost structures: labor rates versus contract pricing versus procurement overhead. We can’t establish and sequence Step 7 activities or estimate Step 8 costs credibly until we know which path each deliverable will take.

5. It helps identify significant risks. Supply chains, vendor reliability, and resource availability become visible risks only once we’ve asked, “How are we creating and providing this?” They won’t get identified if the question never gets asked.

You can know exactly what you’re building and exactly how good it has to be, and still have no project, because nobody’s decided who’s going to build it. Step 5 is at the heart of that decision.

“Every element of scope should have acceptance criteria. And these requirements should derive from somewhere higher up the project food chain — ultimately, to the stakeholders’ objectives and mission.” — Sr. Project Manager, NASA

We’ve established why the project exists (Step 1), who cares about it (Step 2), and we’ve named what we’re creating as deliverables on the project (Step 3). Now we have to agree on how good those deliverables have to be. Welcome to Step 4 of the Project Management Blueprint planning process.

You can hand over every single item listed in an agreed-upon WBS, but still get told that you failed. The scope is not acceptable as delivered. Step 3 establishes what gets built, but doesn’t say how good it has to be when you’re done. That’s what Step 4 addresses: you can’t claim a deliverable meet its acceptance requirements until you’ve written what those requirements are.

Step 4 is about establishing specific and measurable acceptance criteria for every element of scope, from the bottom-layer of a WBS, to the high-level system deliverables. The outputs of this step are the criteria and specs themselves, and on more formal projects, we also create a quality management plan. Good requirements meet a standard we call SMARTTT: Specific, Measurable, Achievable, Relevant, Traceable, Tiered, and Total. In plain terms, every element of scope in your WBS should have at least one acceptance requirement that you can actually test and prove that you’ve met. Here’s why this is so important:

1. Scope only tells you “what,” not “how good,” and that applies at every level of the WBS, not just the bottom. Take the backyard shed: the deliverable “shed” in your WBS doesn’t tell the contractor whether it needs to pass county inspection, securely lock, or match the house’s paint color. The same gap exists whether you’re talking about one stud in one wall (e.g., it needs to be 2x4 construction) or the entire structure (size, shape, color, etc…). Every element of the work breakdown structure needs its own pre-approved-by-the-stakeholders, acceptance criteria.

2. Requirements have to trace back to the mission, not arrive willy-nilly. Criteria that don’t derive somehow from Steps 1 and 2 are arbitrary; they’re somebody’s preference dressed up as a requirement.

3. It’s the basis for acquisition strategy and test planning (Step 5). You can’t write a statement of work, decide on build vs. buy, or plan QC testing without knowing the bar each deliverable has to clear.

4. It grounds cost and schedule estimates (Steps 7 and 8). “How good” has a price. over-spec and you risk necessarily gold-plating, which drives the budget and schedule. Under-specifying means you risk unhappy stakeholders.

5. Ambiguous or unachievable criteria are a risk source in their own right (Step 9). A requirement nobody can actually meet doesn’t surface until someone tries to build it, and by then you’ve burned schedule and budget discovering the spec itself was the problem. A positional accuracy requirement set tighter than the hardware can deliver, for instance, isn’t a technical risk so much as a planning failure: it belongs in the risk register the moment it’s written down, not the moment it fails a test.

6. It’s what closeout (Step 10) actually tests against. A WBS compliance matrix is the proof you created something, a specification compliance matrix means your met the expectations of the stakeholders. In other words, no criteria = no objective basis for sign-off.

Without acceptance criteria, you can’t actually know when you’re done creating a deliverable. Nor will your stakeholders. Further, missing, vague, and/or untestable requirements are worthless. “Software shall be robust” isn’t a requirement; nobody can test it, so nobody can ever be proven wrong. It’s like playing a game of football without a definition of what constitutes a touchdown.

Step 4 is the only thing standing between “I think it’s done” and “I can prove it’s done.”

“The first thing I’ll ask a struggling project manager is to show me their Work Breakdown Structure.”
— Bill McVeigh, Dash360.com

We’ve covered the Who and the Why in steps 1 and 2, respectively. Now it’s time for the project’s What.

Step 3 is when we name every product, service, and result the project has to create or provide. There’s nothing fancy about the output, which we call a Work Breakdown Structure. A WBS is just a list of the deliverables in a hierarchical order. An accompanying document called the WBS Dictionary describes what each one of these deliverables actually means. Together, they answer “what are we building?” in a way nobody should be able to argue with later. Here’s why that has to happen now, in Step 3, and not sooner nor later:

1. It turns a purpose into a thing. “Improve solar imaging” isn’t buildable. “A 4-meter telescope with X instruments” is. The WBS is where abstract goals and intent become a concrete list of deliverables.

2. It draws the boundary of what’s in, and just as importantly, what’s out. Without a defined boundary, everyone assumes their own version of “included.” This is the first real defense against scope creep, before there’s even a schedule or budget to protect.

3. It creates a shared vocabulary. The WBS Dictionary defines what each element actually means, so “the enclosure” or “the control system” means the same thing to the engineer, the contracts officer, and the stakeholder.

4. Everything downstream is organized around the WBS. Schedule activities, budget line items, risk register entries, acceptance criteria, and acquisition strategy are all typically structured by WBS elements. You can’t decide how good something has to be (Step 4), how to acquire it (Step 5), what it’ll cost (Step 8), or what could go wrong with it (Step 9) until it has a name and a place in the breakdown.

5. It builds on stakeholder engagement. The mission statement and charter initiate stakeholder engagement. The WBS is the next genuine opportunity to keep the stakeholders leaning in as active participants: it’s concrete enough that people say “wait, that’s missing” or “we don’t need that.” This is both progressive elaboration and active stakeholder engagement in action.

6. It’s what gets checked off at closeout. Final delivery is measured against the WBS. If it isn’t on the list, it isn’t a deliverable; the WBS is literally the scorecard.

Bill’s right in the quote above. Show me your WBS, and I’ll tell you how your project’s going.

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

Okay, before we begin today’s post, I need to make a confession: I am not entirely sure Step 1 of the PM Blueprint is actually Step 1. I’ve wrestled with this for a long time. Sure, in the last post (here) I argued that establishing project goals and expectations is the very first thing every project manager needs to do. And I stand by that. But I can also argue, just as convincingly, that identifying key project stakeholders should come first.

Why do I struggle with this? Well, you can’t ask “why” the project is needed without talking to the people who’d provide the answers. The first two steps aren’t sequential at all. They kind of happen at the same time.

There is no easy way to show this in a simple diagram without looping arrows and confusion, so I’m inventing an easy way out: let’s leave Step 1 where it is, and put this second step of identifying stakeholders as number two—but recognize that these two things actually take place in parallel.

Okay, that said, I want to talk about why identifying stakeholders is so important early in a project. Here are six primary reasons you need to take this step seriously:

1. Every project has a “who.” Someone wants it, needs it, and/or is paying for it. These are your key stakeholders. Like Ken Hamer alluded to in the quote above, you must identify the “who’s” if you want to plan and execute a project that meets their needs.

2. Step 1 requires people to be interviewed. You can’t capture goals and expectations without knowing who to ask; this is why the two steps really form one initiation step. You must also separate key stakeholders (i.e., high interest, high influence, & pro-project entities) from everyone else, because it tells you whose definition of success governs when conflict occurs.

3. Buy-in starts with stakeholders. Identifying key stakeholders is where buy-in starts. It’s the first step to forming a win-win partnership. People called out and consulted early feel ownership, and the stakeholder register becomes your list of who helps guide the project and reviews & approves each progressive-elaboration pass.

4. Requirements live in people’s heads; your job is to extract those thoughts. Establishing scope and acceptance criteria (PMB Steps 3 and 4) come from the mission statement and from your stakeholders. The stakeholder register also drives the org chart, RACI, and communications plan. Miss an important stakeholder, and you risk missing both requirements and roles.

5. Success is measured both objectively and subjectively. At the end of the day, project success is objectively determined by whether you delivered all the scope on time, on budget, and it met all of its quality acceptance criteria. But there is another, equally important measure of success: stakeholder satisfaction. Subjectively-speaking, are your stakeholders pleased with how the project was carried out and communicated to them? Are they happy with how involved they felt? You can hit every traditional performance measurement baseline metric and still have an unhappy stakeholder, who considers the project a failure because they weren’t engaged with. Establishing who matters from day one is key to satisfying them.

6. Surprise stakeholders are expensive. Changes are cheap on paper and costly in hardware. Decisions are also cheap early and expensive later. Build something and then discover a key stakeholder? That’s a real problem. Some surprises can also be worse than just expensive: regulators, permitting offices, and community groups can hold outright veto power.

7. The people who accept the deliverable are the ones you identified. Closeout sign-off (PMB Step 10) can only happen if you know who has the authority to give it.

Look, whether we put Identify Stakeholders before or after the Establish Goals and Expectations step, you can’t deny its importance. Get the “who” wrong, and everything else, from the requirements, to the schedule, to the sign-off at the end, will be built on a guesses and hopes. Bottom line: you cannot write a love letter unless you know who it’s going to.

Which brings us to Step 1: establishing the project goals and expectations in writing. This means defining the project’s high-level Purpose, Objectives, and Key Results (POKRs), which become the foundation of the project’s Mission Statement.

So why does this Step 1 come first in the Blueprint? There are at least eight good reasons to consider:

1. It gets stakeholders to sign off on the same project. Day one is the cheapest moment to discover your stakeholders don’t agree. Don’t waste time on any further planning or hiring staff or performing work without first getting the key stakeholders in alignment on “why” the project is needed.

2. Everything downstream derives from the POKRs. Scope, requirements, acquisition approaches, schedule, budget, and even risk identification all trace back to the over-arching goals and expectations established now, so an error here propagates through every later step. This is why it’s step 1.

3. The Mission Statement defines ultimate success. A project can hit every baseline number and still fail if the purpose goes unmet. Just because you delivered on time, on budget, and delivered all the agreed-upon scope, doesn’t mean the stakeholder’s original/ultimate needs were met.

4. A guiding beacon. Everyone has the same answer to “What are we here to do?” This serves as a motivator. We all know and can see what we’re trying to accomplish—and why this is worthwhile.

5. It opens up options. Having a strong underlying definition of the problem lets us open up different solutions. A customer might ultimately want a means of crossing a river. Starting with this problem in mind means their original idea of a construction of a bridge could be replaced with purchasing a fleet of ferries or digging a tunnel under the river. The problem should drive the solution, not the other way ‘round.

6. It gives the team a filter for everyday calls. People who know and refer to the purpose can make good, defensible decisions without stopping to ask for clarification. An understanding of purpose is always one of the strongest empowerment tools.

7. It’s a tiebreaker. When things go wrong, it tells you where to spend contingency and what to protect or cut first. When change requests arrive, it tells you which to accept. It’s your best defense against scope creep and gold-plating, as well as project drift. Knowing your ultimate why helps when facing a fork in the road.

8. It’s what you test at closeout. Testing against the Mission Statement is the ultimate measure of whether the project succeeded. Because stakeholders agreed to the POKRs upfront (#1), sign-off at the end is a confirmation, not a negotiation. By performing Step 1 first, we guard against moving goalposts.

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 engineer, and her son’s in college.

I’m telling you all this because this isn’t a 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 heartfelt 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 experienced various versions of it before from 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 will not 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 stick 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 medical care facility. I watched two 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 my 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, review, 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.