Recently a ROWE discussion hit the blogosphere. Especially those, like myself, that are interested in any productivity related topics. ROWE, which seems to originate from a concept that Best Buy has adopted, is essentially about working whenever and from where ever a employee likes. Combined with a strong view on meetings (”Ditch them!”), it seeks to revolutionaries traditional work environments.
So here we go: After using GTD heavily for now nearly 24 months, I just realised that I have misused the term project since the beginning. Not that I read the definition of it again, no, I just got frustrated with some of my projects hanging in there literally forever. So how come?
Essentially I found some of my project mirroring what in standard terms you would indeed call a project. A project in my GTD system equaled a delivery project to a client, another one an larger internal project dealing with a new service delivery model/methodology that I’ am involved in, a third one a large deal which I’ am managing.
So what’s wrong you’d ask. Everything. All of the three examples I’ve given, and I’ am sure you have similar projects yourself, take a very, very long time to close. Anywhere between 3 and 12 months. And whilst other, smaller projects disappear rather quickly from my GTD lists, these guys keep staying.
Not only do they deliver a lot frustation to me by doing so, they also tend to just pile up actions that loose order and more importantly relevance over time. Just as described in a post at tools for thought in an article about ‘Getting unstuck: How to jump start a listless action list‘ you will only find legacy issues in these projects. No only have they lost relevance, they also don’t come in any logical order any more.
Yep. Just go and delete them. Don’t bother on all those actions in there. They’d be lost and you could not care less. Most of them were legacy, meaningless and irrelevant to the projects success. Those immediate actions related to a particular aspect of that project will come back as soon as you setup a new project for exactly that aspect of the project.
So what is tiny and what is little? Depends on the context. A project such as a client delivery project, an entire marketing campaign, a product development effort are fare too hugh. So tiny means aspects of these projects. Things you are currently doing, not those that might need to be done in 3 months from now.
Even single phases of a typical project life-cycle might be to big for a GTD project. Planning, Analysing, Designing, Implementing, Testing, Rolling-Out could be come impressively large animals each. Hence focus on smaller junks and eat the elephant in pieces:
Many of these small projects can run in parallel. Some might be on hold for some time, some might get dropped as they loose relevance as the ‘large project’ progresses and e.g. changes scope slightly. But still, you will get your motivation from setting more and more of these small projects to completed.
But do not create all the small GTD projects you think are required throughout the course of the large project. Just those in your line of sight. No artificial ones, e.g. ‘We need to think of this!’
I’ve just delete five or six of my real-business-life/large projects from my GTD project list and created small ones focussing on the next important events or activities of these projects. Each of them does not contain more than 10-15 actions, all well sorted and ordered and I’ am looking forward to check each of those small projects off in like one, two or latest three weeks time. What a relief!
Some of you may have already heard or read about the book “Back of the Napkin” by Dan Roam. We all know, that even without any particular skill or talent, we can visualise our thinking with pen and paper, or napkin for the sake of it. Still, Dan applies some nice and interesting concept about this type of visualisation, e.g. how you can use visualisation to actually generate an idea rather than painting up the concept of an idea you already had.
The below video featuring Dan Roam talking about some concepts of his book is actually quite nice since he uses rather simplistic examples to help you understand his concept. Well spend 5 minutes!
I do like visual thinking since it automatically forces you to reduce complexity and focus on the essential parts. However, looking at the “coffee chain strategy”-napkin example that Dan uses, I need to admit that I would not even use a napkin to illustrate something so simple. I assume that it was the early structure for the company’s strategy, but not the strategy itself. Not that I’d suggest that a strategy needs to be more complex - no, it needs to be more unique.
