In the last post I argued why you don’t want goals, and that you should frame them as projects. But this is the actionable stuff that I know you’re chomping at the bit for.
The Standard Model
Conventional wisdom states that you begin with a vision and that you set a goal that will achieve that vision.
I don’t think that works very well. I don’t think in most cases that we know enough to know what will constitute a good goal that will achieve your particular vision.
It’s relatively easy to produce good goals — — there are thousands of resources available to you.
Only you will know whether or not your goal actually achieves your vision, though. You can nail your goals…but so what? If they didn’t deliver on your vision, they were merely an exercise in discipline.
What’s worse, though is when people fail at the goals and assume they’ve failed at the vision.
That just makes me want to rend my clothes and take a hairpin to my eyes. Which is why every vision should spawn projects, not goals.
A goal is static and one-dimensional. A project is flexible and nuanced. But building a flexible and nuanced project from a vision can be tricky.
The first problem to be tackled is motivation and follow-through.
The second problem is responsiveness to the changing understanding of what the vision is.
And the third is guarding against scope-creep and consolidating your gains.
Maintaining Motivation and Follow-Through
The most engaging projects have three things in common:
- A problem to solve
- Something compelling to learn
- Build something.
The first condition usually comes directly from the vision: You need to get from point A to point B, and the project is aimed at solving that problem.
Now, if you already knew what to do to get from A to B, chances are you would already be doing it. Since you’re not, you probably have to learn a skill, (more likely several) in order to get there.
Building something is the bonus lesson here. By building something, you create a built-in reward, a target, and a sense of progress. This is what goals were meant to emulate and fail so miserably at.
If you want to learn SQL (a programming language,) you can teach yourself out of a textbook (but then you’ll lack “experience” if you want to look for a job.) Instead, why don’t you decide to build a database using the SQL skills you’ve yet to develop?
In contrast to Joe Schmoe who hated running, if you actually did want to run a marathon, an example of “building something” would be to get donations for charity contingent on you running the marathon. Essentially, the “build something” condition is the shorter-term, concrete target that will motivate you to keep going, even when the more abstract vision isn’t helping.
You don’t have to have all three. Shorter projects require only one or two. But for big projects, over the long haul…it helps. It helps a lot.
Staying Responsive
The reason the project paradigm works so well is that people understand that a project is an inherently flexible framework. I defy you to show me a project that didn’t get the parameters changed at some point during the process.
And that’s what you want. Goals don’t have that built-in responsiveness.
That way, when you start making 80K a year at your job but you realize you gave up too much autonomy to do it, you didn’t have your goal turn to ashes in your mouth. You just realized that being able to dictate your own schedule is more important to you than the money. The project parameters changed. Now you know that your project is constrained by your need for autonomy. And so you carry on.
The Insidious Threat of Scope-Creep
Goals fail horribly on another front: satisfaction. No sooner do you achieve them (or sometimes before) you’re on the prowl for the next win. This is where ambition can get the best of you, and you start expanding your vision, not because of your own desires, but because of the envy it will excite in others.
That’s why the “Build Something” condition is so helpful. It gives a logical end-point and a point to re-assess your vision.
You see, if you run a marathon, then good for you. However, the question is now, are you going to continue as if you were training for a marathon? Are you going to schedule another marathon? Or was running a marathon just to prove that you could run a marathon? (And in which case, is the health and fitness aspect of your life where you want it, or do you need to start another project to address that?)
Reflection and consolidation is a crucial part of the project process.
Say you did love running. Even if you don’t run a marathon, you regularly run 15 or 20 miles a week. You’ve fit it nicely into your routine. But without the marathon to motivate you, you take the risk of losing what you’ve gained. You’ve made a habit. Now make it a routine. Schedule it if you have to.
This is something you want to keep doing, right? But it doesn’t need more than minor tweaking, correct? That makes is a routine. And there are some best practices for routines, too….
More on that on Monday.
Any thoughts on goals that you can transform in to projects?
Do they fulfill the three conditions?
If you like this post, please share it!
[ssbp]
