Skip to main content

Verified by Psychology Today

Career

Should You Finish What You Start?

Here’s how to start things so you can finish something.

Jaksmata/Wikimedia Commons
Source: Jaksmata/Wikimedia Commons

Our parents badgered us to finish what we started. And some of us never quite fully internalized the message.

I’m talking about those of us who have several half-finished books sitting on our nightstand, several half-finished articles sitting in a Word document folder, and several half-finished improvement/repair projects underway in our homes. The backlog is daunting, and there’s that nagging voice in the back of our heads telling us to finish all of it.

Fortunately, there are more than a few economists standing ready to absolve us of all guilt. These economists will tell us that we should set projects aside whenever something more promising comes along. To do otherwise would mean we have succumbed to the “Sunk Cost Fallacy.”

Unfortunately, there’s also a monster lurking in the shadows looking to devour any and all who take the advice of the economists too seriously: the Specter of Eternal Deferment.

Like the person who never finds true love, because they’re always willing and ready to “trade up,” we run the risk of never completing any projects because we’re always ready and willing to abandon our old ones when a seemingly better idea comes along.

There’s even something approaching a statistical law governing our growing backlog. The more good ideas or opportunities we tend to have, and the longer our projects tend to take, the more likely it is we will be tempted at some point to drop our current project for another.

Well, that’s no good. Even if we are the hardest working and cleverest person in the world, we might never actually get anything done. And that’s why we’re going to consider a suggestion that takes the side of our parents (while throwing a bone to the economists).

Bigger Is (and Is Not) Always Better

The more ambitious we are, the more likely we are to want to take on large projects. And that presents some problems.

First, the larger the project, the longer it takes to complete. And that means there is more opportunity for a more attractive project to come along while we’re working on it.

Second, the larger the project, the more complex it typically is. And that means it’s more likely that at some point we will come across an unexpected complication that’s difficult to overcome. If we are three months in on a six-month project and we’re not sure it’s going to work, that can be a dark place. And the temptation to set the project aside at that point can be very strong (and, frankly, is also sometimes the right move).

So bigger is not always better. But, at the same time, who are we kidding? Go big or go home, right? Bigger projects tend to have more impact and bring more praise and self-satisfaction. So bigger is clearly better.

Bigger is better and bigger isn’t better. That sounds like a contradiction. It isn’t really. We want our projects to be bigger in some ways and for some reasons, and we want them to be smaller in other ways and for other reasons. That’s not a contradiction. It’s just mixed feelings.

But Genrich Altshuller (the “father” of TRIZ, a theory of inventive problem solving) taught us that when we frame things as “contradictions,” we often see our constraints more clearly, and are more motivated to devise inventive solutions.

And so he would advise us to meditate on the fact that we want our projects to be both bigger and not bigger at the same time, and then search for solutions that would allow us to do both things at the same time.

Some folks in the software development field did just that. And they invented the “Agile” project management philosophy. And the philosophy, in various forms, has been wildly successful, allowing software development teams to produce products that, all told, take months and sometimes years to complete, while avoiding many of the downsides and dark places that come with big projects.

The neat thing is that some of their tricks aren’t just for software teams. They will work for creative individuals as well.

Sprints, Not Sub-Projects

The key move is to break our projects into a series of “sprints.”

Here are the key features of an ideal sprint:

  1. It lasts just a week or two.
  2. It yields a finished (though not polished) intermediate product of some sort.
  3. That intermediate product has some value independent of the overall big project.
  4. That intermediate product can be evaluated by others (and ideally those who might have an interest in the project)
  5. That intermediate product contributes reasonably efficiently (though not necessarily perfectly efficiently) to the overall goal.

Now this is similar to the idea of breaking our projects into “sub-projects,” but it’s not quite the same thing. The main difference is that sprints are designed to produce parts or successive prototypes that have some independent value and can be evaluated by others. Sub-projects often don’t have any value until the whole project is completed.

For example, if we are writing a book, we might spend a week outlining the whole thing and trying to write an introduction. At the end of the week we have a cryptic outline that only we understand, and which will probably have to be re-worked several times before the book is done, and our half-written introduction will be a bunch of stage setting for a stage that might not look the same by the time we’re finished.

Alternately, we might spend the week writing an essay that sketches the main argument, with the intention of publishing it on a blog. Then, even if we don’t ever finish the book, we will at least have a blog post published and can get feedback on the main argument. And, if we do eventually finish the book, our effort will have contributed reasonably efficiently to that goal.

If we are remodeling our house, we can create a big vision, rip out all the drywall, and hunker down for a few months of bringing our vision into being.

Or we can schedule a party for a couple weeks out, commit to finishing one bathroom, and then get some feedback on our handiwork and artistic choices before moving on to another part of the project.

More frequent feedback means we are more likely to notice unexpected complications earlier, when they are easier to deal with, and when we haven’t already sunk so much effort into what might be a dead end. And independent value means that, even if we don’t finish the big project, we still have something to show for our efforts.

If you plan your projects as a series of sprints, get feedback along the way, and commit to finishing each one- to two-week chunk even if something a little better comes along, you should finish more big projects, get more value out of the ones you don’t finish, and dampen your project-related emotional mood swings.

As for that pile of books on your night stand, you’re on your own there.

advertisement
More from Jim Stone Ph.D.
More from Psychology Today