Embracing outcomes
I’ve always embraced the idea of defining outcomes for all projects in my project list. It made me feel like my projects were going somewhere, rather then being just a summary of disjointed actionable items which had some commonality because they aimed to achieve a certain goal. Rather, outcomes are expressions of what you aim to achieve with specific projects. And a project contains sets of activities that need to be executed in order to move that project forward. What you can do now is your next action, as per the GTD definition.
Outcome dependencies
There is, however, a problem. Outcomes do not necessarily refer to results that are achievable by you yourself. An outcome, or any benefit you may derive from a certain project, can be dependent on other factors than just your own personal effort. Now, if you are stating outcomes as what you want to achieve with a certain project, there is a real risk you are setting yourself up for failure. This is especially true if an important aspect of your outcome is dependent on factors outside of your own control.
Let’s look at an example. Imagine I have a project “Ensure I get hired by company A”. I use the GTD project verb “Ensure”. Now let’s define an outcome: “Get hired by company A”. Okay, that’s clear in terms of what I want to achieve. However, am I the one in control of that specific outcome? In reality, I can only partly influence it. Even if I do my very best, it is entirely possible I will not get hired. Now I’ve made my outcome, and hence the success of my project, dependent on outside influences. I’ve lost control of my own project. Not a good feeling.
It turns out that quite a lot of outcomes we define for projects are dependent on influences outside of our control. And that makes the successful achievement of a project that much harder. Of course, it also provides us with yet another excuse why we could not achieve the desired result.
The internationally recognized project management methodology PRINCE2 has an interesting solution which can be applied to this problem. Actually, the people who developed the methodology were being confronted with activities which were being executed in the context of a project without it being clear what exactly they contributed to the project. In order to make their project management approach more efficient and effective, they decided to focus on project products and products rather than activities. Of course they still define activities, but only as a means to delivering a product somewhere in the process. If it does not lead to a concrete product, an activity should not be executed. A product is also under the final control of the project manager.
If we assume we are the managers of the projects we define in GTD, the approach developed by PRINCE2 actually makes a lot of sense in for our GTD projects as well. Rather than defining a project “outcome” which may not be entirely under our own control, we define products which are either directly or indirectly under our control and which contribute to the desired outcome.
Clarifying the PRINCE2 vocabulary
Any PRINCE2 project starts with a project product. That is what a project must deliver in order to gain acceptance. Since we are both project managers and project sponsors of our own projects, acceptance means project success. Each project product can in turn be broken down into products. A product, in PRINCE2 parlance, is “an input or output, whether tangible or intangible, that can be described in advance, created and tested.”
In plain English, in order to make a project successful we need to be very clear about which products need to be developed.
Okay, that still makes sense, now doesn’t it. Let’s go down even deeper into this particular rabbit hole. Products, when used, will lead to change. An outcome, according to PRINCE 2, is the result of change, normally affecting real-world behaviour and/or circumstances. And ultimately, we aim to achieve a benefit, according to PRINCE2 the measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders. Ideally, but not exclusively, for GTD projects that stakeholder will be you.
Again, in plain English: these products, when present in the real world, will be interacted with and will lead to something changing. Ideally, to a situation better than before, an improvement, but at least an outcome as a result of that change. That change will result in a measureable effect, a benefit.
Again, from a GTD perspective this all makes sense. Let’s apply this to our example:
“Ensure I get hired by company A” is an outcome that will result in a benefit for me. If I want to achieve that benefit, I will need to do something. In order to be as effective and efficient as possible, I want to make sure that everything I do leads to an increase of the likelihood I will get hired. So I will be as concrete as possible, I need to deliver a convincing recruiting story and package. This is my project product. I will need to break this down into specific products that I can describe, create or have created and test. I will likely need to actualize my CV (actualized CV), update my website (updated website), update my credentials (updated credentials), get a good picture taken (good picture of self).
The project product can be broken down into specific products which in turn can be broken down into specific actions, with timing and dependencies if so required, which are very concrete and actionable.
In conclusion
Rather than an intangible outcome which is beyond my control, applying some of the basic concepts of PRINCE2 to GTD has led me to define a project product and related products to that project. Defining my activities and next actions around developing these products to specification will lead to a higher degree of control over the project I aim to achieve as well as distinguishing what I can do from what is beyond the scope of my actions. While the approach may not guarantee the benefit being realized, applying this will create a clear distinction between my own responsibilities and aspects of an envisioned outcome and resulting benefit outside of my control. And that should bring my GTD projects back where they belong, under my own control.
Exploring The Black Box 