A project is defined, in part, by its outcomes. They describe us what it looks like at our intended project destination, in terms of where we are but also in terms of what we have learned, gained, developed. By defining good outcomes, we actually develop a great way to regularly check whether we are still on course. You typically do this at regular intervals, for example when you are performing a (weekly) review.
But sometimes formulating these outcomes is difficult, not to say almost impossible. I want to take a quick look at this type of situation, what may be a cause and how we can attempt to solve it.
What defines a good outcome?
A good outcome should be SMART. If your outcome is specific, measurable, attainable, realistic and time bound, it becomes adequately concrete to be followed up. There is a reference, an adequately concrete basis for developing a baseline. I've written about this before here.
what can go wrong? A concrete example
Now, theoretically I'm very much aware of what a good outcome should be. I mean, I've even adapted some text expander snippets for that exact purpose. However, the following happened to me only a couple of days ago.
In the course of my weekly review I bumped into the following inbox item (duly captured in my GTD process) "learn python". The source of this idea was an interesting post on MacStories by Federico Viticci on Pythonista for iOS. I'm a real pushover for this kind of excellent articles.
I knew this was not a simple next action. After all, you cannot 'do' learn python. So, it's a project. A project has both a defined 'why' and an outcome. The why was easy. Because I am curious about python. Okay, now the outcome. What does it look like when I get to the other side? Mmm ... Well, I know python. But what does that mean? Knowing is not adequately concrete. I cannot measure knowledge of python unless I define an objective benchmark. But I don't know enough about python to be able to define such a bench mark. ...
It turns out I never really considered what relevance python has or can have for me. I actually did not have enough information on python to assess its use for me. I simply did not have enough basis yet to motivate my (significant) investment in learning this language.
So I converted the project into "research relevance of programming languages for BTC, casmo and personal activities." In Covey speak, I did not have the end in mind. My project now has a number of steps aimed at identifying languages, understanding what I can do with them and matching or approximating this to a need I have or may have in the future.
Now, The answer may be that I have no need for learning a programming language. Perhaps I need to focus on bettering my CSS skills first. But at least I will not be off squandering my time on a no doubt interesting topic that will not contribute to my development or efficiency.
Don't get me wrong. I may still find arguments to learn python, even if it will not yield direct and measurable benefits. But, and that is a highly relevant difference, it will be a considered choice. That choice may mean I need to give up a number of other projects. But it will be considered.
I failed to properly formulate a smart outcome for a project. While I was very motivated to learn python, I did not have a good enough reason for committing to it yet. There was no project, only enthusiasm about a potentially interesting subject matter I could get lost in.
While sometimes it may be your subconscious resistance to work that is pushing you in that direction, this was just an inadequately considered idea. Which is why doing the necessary research is a smart sub project to execute.
what has this taught me?
Well, first it taught me there are quite a few potential projects in my inbox or equivalent that are significant time sinks that I have yet to define a good outcome for. As long as the outcome is not clear, as long as they don't qualify as a real problem or issue I am trying to solve, I do not engage with them other than doing some research to clarify my thinking about the end I have in mind.
It also taught that that the SMART framework, heavy as it may be, has a marked advantage: if you fail the SMART test, you have an outcome issue. You are not clear enough. So you need to go back and think it over, again.
For those of you interested in the outcome of this specific issue, you may be interested to know that post my research I decided not to study python yet, and 'learn AppleScript first, as it allows me to automate more on my Mac. This will more directly impact my productivity.