GTD & Kanban: Managing The Relationship Between Someday/Maybe & Active Projects

Throw out the schedule

In my previous post, "GTD & Kanban: Similarities, Differences & Synergies Between The Two"in this series,I talked about using Kanban for managing the flow of work, rather than having any number of projects and someday/maybe items in separate lists which are reviewed every week to a month.  In this post I will describe how using flow to manage GTD projects and someday/maybe lists can be beneficial.  In a future post I'll describe how this also translates into flowing actions in a context, such as the work place, and limiting the work in progress (WIP) of these actions.Again, for the basics of GTD I recommend the material linked from Wikipedia.  The basics of Personal Kanban can be found on this very site.

What are "Someday/Maybe" lists and Projects?

Getting things Done (GTD) has a number of horizons above any given action: Projects, Goals, Focus, Vision & Purpose.  These are aimed at providing yourself goals to aim for and to test your choice of actions against, so that you aren't just "doing", but are actually moving toward a goal, and these goals join up to achieving larger objectives in life.In GTD, anything you wish to achieve that has more than one specific  action is considered a project.  For example, even arranging a meal out at a restraunt could be considered a project as you will have to go through actions similar to: who to invite, confirm who is available, when to go, where to go, book a table, confirm booking with invitees and go.  The reason why this definition works is, actions could be in any number of places in your personal productivity system, be it a calendar or a list, and when they are done there needs to be a reminder in your system that acts as a touchstone so that you can ensure a next action is available to move forward towards an envisaged successful outcome.Any objective that requires action, yet does not make sense to undertake as-at-now, yet you feel this is something you would like to do in the future is considered a candidate for the "someday/maybe" list.  Someday/maybe is reviewed at regular intervals to see if an item needs pulling into the current project list, or, if only one action is required, a contextual action list or placed on a calendar.  Why have a someday/maybe list?  Someday/maybe lists assist in clearing your head by placing all these wishes and thoughts into a trusted and regularly reviewed system.

Managing Someday/Maybe & Projects by using a Personal Kanban

Rather than have multiple flat lists, one for projects and one for someday/maybe with no interaction between them other than once a week if not longer, lets use a Kanban to represent both!  The example bellow includes prioritisation, a step for the initial brainstorm of what success looks like and what actions may be required, the doing part (working), and the done part.  All with WIP limits for focus.

Lets do a quick illustration:

1. You get a new project at work called "Project A" that is going to require several actions, so you place it on the backlog as you have plenty to do already.  The backlog acts as your someday/maybe list.

2. A space becomes available on your "Should" lane, which prompts you to look at your backlog for possible projects to start prioritising, you assess the items against your current Goals at work, and select Project A.

3. Over time, Project A moves from "Should" to "Ready", and before undertaking the work, to the elaboration lane for envisaging a successful outcome and working back to the next steps from where you are.

4. Once Project A moves to the "Working" lane, you place the next action discovered as part of elaborating into the appropriate context list or date on the calendar.

5. Actions get performed overtime, and eventually the successful outcome is achieved and Project A is placed in the "Project Goal Achieved!" lane.

Clearly, due to the variance in size of knowledge work or personal projects it's difficult to set a limit on "working", so I suggest you experiment with this number, and try to keep it as low as possible for focus.Going back to the purpose of someday/maybe, it is possible you have single discreet actions on your backlog now, so it is worth moving those items to an appropriate context list or calendar entry when the time comes that you wish to do something about them.  Personally, most of my Someday/Maybe items were and are projects, so I don't mind the backlog being closely associated to projects.

InfoPak 1 - Personal Kanban at the World Bank: A Case Study

Personal Kanban at the World Bank - Small Team Rapid Development View more documents from ourfounder.

This is the first in a series of Modus Cooperandi's InfoPaks. They are downloadable, and work like a narrative whitepaper. Think of them as graphic novels for business.In InfoPak 1: Personal Kanban at the World Bank, we discuss the experience we had leading a rapid development project at the World Bank, specifically, how visual controls work with small groups, and why they are preferable to traditional team management.This InfoPak is best read by clicking the “Full” button above.  It’s also designed to be downloaded to distribute to others.  We expect to post more Personal Kanban InfoPaks in the coming weeks. Please feel free to comment and let us know what you think.

Starting Is Easy, Finishing Is Hard

post-it

A wise man once told me, "starting is easy, finishing is hard."This has been my struggle my entire professional career, but I would argue it started as far back as grade school. I've always had projects and tasks to complete and deadlines to meet.  I've tried multitasking.  I've tried listing A, B, C tasks in a Franklin Covey Day Planner.  It has been a lifelong struggle to find a tool or process that provides clarity to my chaotic, goal-driven life.As the manager of software engineering and project management teams, I've used kanbans in the past.  In those applications, I referred to kanbans as "information radiators."  Large billboards were strategically placed around the office so anyone could passively see the status of the current project.  Anyone could see what the highest priority was, what was currently being completed, and what was being delayed.  I believe the key to our successes was the ability to visualize our work.  Everyone knew exactly what they needed to complete and everyone else knew if it was getting done.  People were not allowed to go on to ancillary activities until their assigned tasks were completed.  This constant feedback loop was very powerful.You would think if it worked so well for my teams, for business purposes, I would use it for myself for personal purposes.  It took some time but I finally started using a personal kanban and I kick myself for not doing it earlier.In order to communicate my kanban to collocated teammates, I use a product called Zen by Enkari, Ltd.  It is a web-based kanban and does an excellent job.  It's simple, clean, affordable, and very scalable.  Having a web-based tool like this also allows me to review my kanban at home and not upset my wife by having a large whiteboard covered with post-it notes in the sitting room.  The other step I've taken is having a physical kanban at work.  It looks exactly like my web-based kanban, right down to the color of the post-it notes.  Anyone can see what work I have on my backlog, what I'm currently working on, or what I have recently completed.Despite my best intentions, I've always made managing personal tasks WAY too complicated.  To the contrary, using a kanban is simple and it allows me to focus on what is important.  I no longer multitask and get nothing done.  I now limit my work in progress, focus on the task at hand, and finish.

The "Man, That Was Awful" Approach to Personal Kanban

Kanban is meant to be epiphany heavy, but process light. These approaches are meant to provide simple means to visualize how your work actually flows. Some tasks are going to be horrible. They are going to take longer than you expect, be harder to complete than anticipated, or even just really annoy you.In life, you want to do things that make you happy and not do things that don't. So why not start noticing what you don't like to do or what takes you away from doing the things you like?The MAN THAT WAS AWFUL approach is simple. When you finish a task and it was in anyway unpleasant - set it aside. Then, later, take a look at the tasks that were unpleasant and look for patterns. Were the people involved the same? Was it a resource issue? Do you just hate doing those kinds of things?After you see the patterns you can make choices like:

• when to delegate

• when to refuse work

• what processes you might want to recreate

• if you want a new career

• to cry

Again, the point here is to make what you are doing explicit. Hopefully bad things will initially fall into some patterns that you can consider and reshape. Awful tasks should become less and less common as you can spot them coming and learn ways to deflect them.Photo by _Boris