Project Diary: Describing (and Documenting) Everything
An assumptions log helps ensure everyone is on the same page(s) from the start
In my last post, I described an “assumptions log.” This is a powerful (but, alas, often overlooked) document that can help ensure a new project starts off on the right foot.
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:
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:
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.
Stages and Phases of Work. This describes the NSF project lifecycle, and where the ngGONG design project fits within that framework.
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).
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).
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:
Who are the key stakeholders? This includes both external and internal stakeholders that I know need to be involved in the project.
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.
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.
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.
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.
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).
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).
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.
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.
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.
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…
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.