The 5-Point Request #
I originally wrote this as part of the npm, Inc. handbook, a set of documents defining how we ran the company. I often want to refer to it, but it apparently exists nowhere else online, so I'm publishing it here.
The 5-Point Request #
There are 5 elements to a project or request. Without these 5 elements, the chance of successfully meeting the request is much lower.
1. Criteria (Positive Definition of Success) #
The first point of the request is to define, in positive terms if possible, how we'll know if the request has been met.
Driving towards "how will we know?" can uncover discrepancies in our understanding of the goal, and clarify the intent for those doing the work.
2. Owner #
The owner may not be the one doing every part of making the request happen, but they are the one who takes responsibility for making sure it happens.
An owner is not multiple people. An owner is a single human being. This prevents bystander-effect paralysis.
3. Timeline #
When should we expect to see some progress toward the meeting of this request?
This timeline should be something realistic, that the owner believes is attainable and where the requisite resources are available. There is no sense in setting unrealistic timelines. As stakeholders, it's our job to accept reality for what it is. If a satisfactory timeline can't be found, then we have to make other plans, and the sooner we can get on that, the better.
4. Budget #
What amount of which limited resource are we putting towards this request?
This could be time, money, space, or some other resource. But we need to clarify that the resource is limited, so allocating it here may mean de-allocating it somewhere else.
If something can't be done in the budget we have available, and it's not important enough to de-scope something else, then it's not something we're going to do. Put it back on the "someday maybe" wishlist.
5. Verb (Next Action) #
What is the next observable, physical action that has to happen in order for this project to move forward? This should be a very specific verb that a human being does in the real world, the more concrete the better.
"Come up with a plan for foo" is not great. "Schedule a meeting with foo team to discuss foo" or "write down list of requirements for foo" are physical and observable. You can see them being done, see that they have been done, using your human eyeballs.
Note that item #5 can spiral out fractally into another, smaller request, with its own 5 points! Repeat until triviality.
If you need to spend an hour thinking about something and then make a decision, then you've now identified a positive definition of success (write down the decision), an owner (the person deciding), the timeline (when does this hour of thinking-time happen), the budget (1 hour of time blocked out on the calendar), and the next action (spend an hour thinking).
Using the 5-point request #
This is excessive structure for most simple requests, and when things get low-level enough, the action eventually becomes so trivial as to not require this. However, for big projects involving many different individuals and teams, it's useful to make sure all 5 points are met.
The moderator of a meeting should always be on the lookout for a request being made. If it seems like a course of action is the plan of record, then the moderator should write down the points that have been established, ask for clarity on the ones that are not, and verify that all parties are in agreement before moving on.
Especially, they should make sure that the owner is comfortable putting this on their plate.
Any upcoming check-ins or scheduled actions should be added to the approprate calendars before moving on, and the 5 points should be recorded.