Proposal: MPP (minimal project pitch) and adjustments to project proposal/prio process

[pooja]

As discussed within the w3dt, how we operate in practice has evolved over the last few months (a significant change being the move to significant programs of work, as opposed to the individual-projects-first approach), motivating the desire to adjust our project proposal and prioritization process to match changes elsewhere in our operations.

Process Changes

This diagram describes, at a high level, an iteration on "how we operate" that takes into consideration our current processes, and how we might desire for them to change going forward:

Some key changes to note:

1. This process introduces the idea of a program scope document, which synthesizes needs and information from various different sources to encapsulate a cohesive area of work, i.e. a "program." The program scope document lays out the motivation, goals, OKRs, KPIs, approach, and the set of projects that are being undertaken to achieve the program goals. This document would live within this GitHub repo.
2. This process introduces the idea of a minimal project pitch (MPP). The MPP is a version of the project proposal that is lighter weight since it inherits many of the proposal template information from the program that it supports. Below, we propose a revised set of fields to include in the MPP. It's also important to note that we recommend project teams write these MPPs after initial team alignment, brainstorming, and some initial program product reviews have happened. However, this is not required. It is very possible to propose a project for a program without having had detailed conversations about the project beforehand.
3. This process separates detailed technical design and project milestones/plan from the initial project pitch (MPP) so that we can agree that something is generally a good idea to undertake and supports important goals before we invest heavily in designing how we will undertake that project.
4. This process creates room for projects that are not tied directly to programs as well.

Note also that w3dt teammates can always continue to use the original template if desired to provide more information about the project.

Minimal Project Pitch (MPP) Template

Estimated to take <30minutes and be a couple of paragraphs long. Will be linked into the program scope document once accepted

• Name of the project
• Program: Does this project support a program? If so, which one?
• Impact: What program goals/OKRs are being addressed -- why is this important? Or if this project is not proposed to be part of a program, why is this project important? What will we gain by picking up this project?
• The idea: Describe the proposed project solution. Diagrams and interface descriptions go a long way!
• Success/acceptance criteria: How do we know that we're done?
• Dependencies: Does this project depend on any other project landing? Or anything else in the broader ecosystem? What are your known/projected dependencies?
• Estimated scope: Can you estimate how many people will be needed for how long? Which teams would be a best fit?
• Detailed plans: Link to project plan and technical design doc (once they exist). Optionally can be added in the MPP if desired.

The Ask

Please review these proposed changes and help improve them!

[atopal]

I'd suggest adding Acceptance Criteria, or "How do we know we are done?" to the minimal Project Pitch Template. Thinking about acceptance criteria even briefly can surface things that are easily overlooked, but have large impact on scope.

[jessicaschilling]

Good idea to move some of the heavy scope/planning lifting later in the process. For projects that involve building websites/apps, we have the Web Lifecycle Guide that should help systematize your later "technical design doc & project plan" phase somewhat — we'd even talked about eventually including the "MJP" (minimum justifiable product) sections of that lifecycle guide in a PR template for future project proposals.

Suggest that as this MPP evolves, it borrows some of questions from the earlier phases of the Web Lifecycle Guide's MJP questions for consistency and to avoid duplicating work later down the line. (Example: "What is the primary user story or Job to Be Done, and how does it explicitly contribute to a currently prioritized high-level outcome?") Even though the lifecycle guide is intended to be specific to web development projects, the first two phases (needs assessment, goals/specs) really apply to any PL project being proposed.

[pooja]

Great feedback, thanks! Agree that some version of acceptance criteria will be really important, so added that one to the MPP. And also agree @jessicaschilling -- the Web Lifecycle Guide is awesome and has great prompts for us to include in the MPP too. I think the example question about JTBD and outcome is wrapped in the program/impact prompts in the MPP though, and is a little less specific than that question b/c many program-specific projects might inherit these answers from the program scope and also some projects might not be directly (i.e. one-hop) solving w3dt top-level goals and might be more indirect but still important. Do you think the broader prompt is sufficient for web projects too?

[mikeal]

Love it. Would want to do “programs in programs” for projects as large and long as nft.storage.

[jessicaschilling]

@pooja The broader prompt could be sufficient for some web projects depending on an individual project's level of "inheritance" of a parent project's larger goal. The web lifecycle guide hasn't been formalized in any sort of proposal PR template, but if that turns out to happen, it's a good caveat to add the PR template something like "OK just to indicate that website X inherits its parent project's goals Y and Z."

The reason I brought up the web lifecycle guide is more out of a suggestion that we try to standardize the language and/or question prompts we use in different types of proposals, just to make proposals simpler to generate. Within the context of the diagram above, someone might be writing up proposals in the form of one or more of the following:

• A program scope document
• A minimal project pitch
• A technical design doc or project plan (including one for a website/web app)

I'm asking that we use similar language and/or question prompts in the guidance for generating each of these, so if one document reuses or inherits material from another, it's relatively friction-free to do so.

[raulk]

We need to make room for engineering-oriented projects that don't have an immediate product outcome/result, but directionally set us up to deliver with higher quality, speed, and confidence. I think the top arrow captures this, so LGTM.

[warpfork]

I really liked this introduction of Program vs Project. Doing heavy duty justification work in a Program and then having lighter, smaller cycles of re-connecting to those justifications during Project description seems like it'll save a lot of overhead. Also, those terms really auto-unpacked well and quickly (for me at least). 👍

Programs also seem to map nicely to {product strategy}, while Projects seem to map cleanly to {technical strategy}, which seems... Copacetic. These are both very valuable and complementary kinds of strategy, and we do need both, as others have also commented.

[warpfork]

I have some thoughts about about the acceptance criteria / doneness topics I think might be kind of a synthesis of what atopal and jessicashilling commented on...

The definition-of-done prompts are a very interesting part of the current proposal template. They're very thought-provoking. They're very valuable. They're also very hard to produce. Something I've noticed while trying to draft project proposals in the current template is that of all the places in the drafting process I'm likely to need to tag other people and ask for a time commitment from them to help flesh things out, it's by far the most likely to affect the definition-of-done headings.

I think maybe the solution to this is to embrace it. Definition-of-done is probably going to go through more cycles than most of the rest of the document.

• Early conversations can usually agree on directional statements, and outlines of systems that should be touched... and that's probably the limit of what can be decided well in, say, a 1 hour group meeting about the topic.
• In later conversations, we probably want to identify specific APIs -- calling out endpoints, CLI commands, or symbols in code -- that we definitely want to see included by the end of successful work. (This is especially true for the way Protocol Labs organizes our work, because the work may spread across many git repositories, and that's extremely difficult to inventory (and easy to lose track of) without being explicit about the list of targets.) This is, in and of itself, sometimes a significant amount of work.
• Sometimes, after the work has started, and proceeded for some time, the team working on it will have better knowledge of which parts of the work are especially expensive and which have turned out easy. Ideally, at this point, it would be possible to revisit the definition-of-done section and, if necessary, discuss which goals be adjusted to make the work better scoped. (We might even want to include a step for this in our default expectations about work cycles.)

So I am glad we have acceptance criteria on the list here -- but think we'll get a lot of value out of diligently reviewing the phrasing there. There should be some expectation management about how solid the text in that section is: how solid it is, how much technical review it's gotten (or if it needs more, and we haven't been able to get the time allocated to Do That yet), etc.

I suspect the flow chart for that acceptance criteria section might end up being somewhat different than the rest of the document, because for it to be accurate for technical work, it needs a lot of review and co-development with the executing team. This is a distinct effort in itself, and sometimes can only be performed once the work is relatively close to starting.

[pooja]

Thanks for the feedback @warpfork ! I adjusted to make acceptance criteria optional for the FIRST pass of this MPP, so that it doesn't block the production and publishing of the MPP. The idea is that the first pass of the MPP should be super lightweight, and take <30m to produce. If you already have solid acceptance criteria to include in the first draft, great! If not, it can be added afterwards when the detailed plans are also added to the same MPP. 👍

[proto-sid]

The MPP template includes dependencies but doesn't mention the risks related to the project. Some of those risks could be inherent and attributable to factors in control of PL, and others could be external/environmental factors.
I thought we should have a set of risks identified in the MPP pitch (& identify new ones or curate existing ones as we move forwards).

Also curious where the infrastructure requirements (people, capacity, etc.) should be captured - are these intended to be captured as part of "Dependencies"?