Qwilr’s Momentum Management.
A Note On Terminology: I don’t much like the connotation of “project” management. It seems to imply piece-meal and tangential work. I prefer the idea of “momentum” management, since all the projects we are all undertaking each contribute to the singular momentum and direction of our organisation.
This document aims to describe Qwilr’s momentum management system.
Ideally I would like Qwilr to have one way of managing momentum across our disciplines and functions so that everyone can participate and move fluidly between conversations, armed with the relevant vocabulary.
This document is agnostic to the actual software we use to track and document our work to be done - whether that is spreadsheets, Trello, Asana or [Insert Future Super-Dooper Project Management System Here]
Stories > Projects > Work-To-Be-Done
A high level view of how we generate and structure What Gets Done at Qwilr is as follows:
- Stories contain the simple messages that we want to tell the world about on a given date. “We’ve just invented so-and-so and it is available right now!” These stories may take months or even quarters to be able to tell. They contain big and broad messages that your grandmother would understand (caveat: depending on grand-parental savviness :)).
- To be able to tell such stories to the world, the team needs to execute many specific projects across the various disciplines and functions (i.e. “Redesign app interface” or “Launch marketing campaign”).
- Within each of these projects, there is a series of actionable items. They are the units of work-to-be-done. They are unitary because each action is clearly defined (“Email firstname.lastname@example.org for release date”) and would not be practically useful to subdivide into smaller tasks. So: an action item like: “Work out marketing plan” is actually a project, and should be subdivided into tasks. Whereas “Create calendar event for agreed delivery deadline with engineering team for X” is a clearly defined, actionable task.
Story Planning (aka “Mummy, where do projects come from?”)
- The first step in working out what projects need to be completed for a story is to throw out everything you can possibly think of that will be required to tell the story effectively. See for a brain-storming example in a product context. These will be totally messy ideation sessions. Mess is fine here. During the session, you’ll probably notice how various items coalesce and form a theme of work-to-be-done (i.e. “Well I guess all of these ones are about updating our sales processes for the new release”). These little galaxy clusters of work are your projects.
- Once you have an idea of your projects, you can start fleshing out the associated action lists for that project, and making clear and explicit descriptions for those actions you just jotted down.
- I think it’s important to ask yourself and your group before concluding the session: is there anything else we can think of that we need to do? Don’t worry if things being thrown out seem trivial, or it’s an edge-case etc. It’s much, much easier to front-load organisational juggling prior embarking on a journey, than it is midway through the voyage.
Continuously Capturing Work To Be Done.
Although a project is planned at the outset, it does not cease to be a living thing. We should be always and forever capturing new work to be done into our momentum management system. As you start working on projects you’ll probably realise a whole plethora of other tasks that will need to be completed for the project. Some thoughts on this:
- Externalise ALL of it. Capture everything, on the fly, as soon as possible. As soon as something worth doing appears in a conversation, or on the commute home, or eating lunch, make sure it is recorded. Don’t keep things you or your team needs to do just in your mind. Remembering takes mental energy. Remembering to remember takes mental energy. Spend that energy getting stuff done, rather than remembering stuff you need to get done.
- Capture the work to be done in an “inbox” or “in tray” (see below). These can just be rough notes, they don’t have to be precisely formulated. All you need is enough to remember the point.
- Worth noting: I found this was an easy thing to do for a week but actually quite a hard discipline to stick to. That being said, once the capturing becomes habitual, it’s fairly easy to maintain.
A List of Lists
There a few different types of lists we’ll end up with (stored in whatever software we want to use). These are:
- Projects - the list of projects needed to tell a story
- Project action lists - a list of actions for a project
- Inbox/In Tray - the unsorted work-to-be-done the team has captured over the course of the week.
- Review Next Week - action items to be reviewed the following week. These are important items with some level of time sensitivity, but not urgent enough to be done right now, or this week.
- Review Next Story - action items to be reviewed before commencing the next story. These are important items, with less time sensitivity, that can on balance be pushed to the next story cycle.
- Review Next Quarter - action items to be reviewed at the beginning of the next calendar quarter. These are your important-to-do but not really very pressing.
- Personal Todo - hooray, a list of the actual work you personally need to do.
“Waiting For” tag.
One very useful piece of metadata to attach to action items is “Waiting For” - i.e. when an action item’s completion is being block by an external factor (i.e. waiting on an email from someone). Reviewing this list gives an overview of all the people you need to bump/ping/poke for movement on a project.
Why The Hierarchy Is Nice
Working in a start-up has a few common images associated: whirlwind, rollercoaster, storm. At the coalface of getting things done it can often feel a bit disorientating. I can certainly attest to that.
One of the nice aspects of having this Russian doll style of momentum management (i.e. Story > Project > Actions) is that you can “zoom out” as needed from the level of action to project or up to the story, and take a higher level look at what you’re doing, why you’re doing it, and what the real priorities are.
It’ll still be a whirlwind-rollercoaster-storm but there’s also some solace and occasional calm of perspective in this approach.
Reviewing Work To Be Done
Each week the team (product, marketing, sales, customer success etc) has a review session. The review session is structured as follows: