Friday, June 22, 2007

How To Do Anything

As the title suggests, what follows is a strategy for accomplishing any goal, no matter how easy or how hard. Some of the rules may not seem to apply to your goal. Some of it is age-old wisdom, while some is just stuff I've noticed. Which is which will almost certainly be obvious.

I use the terms 'task' and 'project' interchangeably in what follows, except for the connotation that projects are more complex than tasks. A simple task, however, can reveal or become a huge project. A project can also serve as a metaphor for a lifelong dream. The process is recursive: treat each task in a project as a project.

  • Think First, Do Second
    Planning is only necessary if you want to succeed. Before you start work on some project, learn about it. While a novel approach sometimes strikes out of the blue, most of the time your 'novel' approach will be the first one that everyone else who ever tried to do what you're about to do thought of the first time, too. When you are learning about a subject area, don't be too quick to come up with a plan, but let the new information percolate. Time spent thinking, drawing pictures, or asking around will save many multiples in wasted effort, or will avoid the same amount in the paralysis of procrastination. It may also mean the difference between success and failure, or falling prey to threats for which you should have accounted. Periodically on the way to your goal, revisit your plan to make sure external events haven't changed your requirements, and to be sure you haven't gotten away from the plan.

  • Read The Fine Manual
    A lot of things seem impossible until you know how to do them, but are easy once you do. If you don't know how to do something, perhaps someone else does. Few things are really new. In the modern era of search engines and instant communication, getting instructions has never been easier. No matter what the task, by the Green Tennis Shoes Principle, someone probably has a web page describing how to do it — with a printable checklist and a flash movie of the tricky parts, and a forum of users with answers to questions you didn't even know enough to ask. The instructions will generally also tell you how to mitigate any risks.

  • Ask For Help
    People don't know you need help. Ask. Sometimes just asking even someone who has no apparent skills at all to help you will be enough to make you realize what you have to do. There's nothing like teaching a thing to make you learn it. But you most often will be surprised at how a fresh perspective will confront a problem, making what seemed hard before much less so.

  • Divide and Conquer
    Almost by definition, any task worthy of a plan will have component parts which can be handled separately. Take on the largest or most difficult portion you can reasonably achieve while leaving the rest for later.

  • Know What You Have
    Every project has finite resources. Most often this is time, but there may be some other key finite resource such as a raw material, money, distance to be covered, or pounds to be lost, for which you need to account more closely than time. You also need to consider the helpers and groups who will be available to you, and any who may oppose you. The opposition (even if that is only entropy) gets a vote, and so every part of every plan must account for as many kinds of failure as practical.

  • Consider Dependencies Carefully
    One reason a project seems complicated is that one part may depend on other parts being done, or simply started, first.

  • Set Deadlines
    Even if your project has no external deadlines, set them for yourself. Think carefully about these dependencies, and set your deadlines accordingly. Set milestones or benchmarks for each phase or portion of the project, in terms of the key finite resource.

  • Do the Hard Part First
    If there are several independent parts to some project, you have the option to pick off some of the easier portions before tackling what you think will be the hard parts. Other things being equal, it's best to get the hard parts out of the way. This is especially true when "easy" and "hard" are actually euphemisms for "fun" and "not fun", or "rewarding" and "unrewarding". The hard part typically will have the biggest uncertainty in terms of time and resource requirements; doing it first allows you the greatest control over your own deadlines.

  • Measure Twice, Cut Once
    After your plans are made, and you think you know what to do, go over those plans again. Start from what you are sure you know, such as a factory edge, a bank balance, or a spot on a map, and measure your key resource in a different way than you did before. Repeat this process until all measurements match.

  • Do Something Next
    If you don't know what to do next, it usually means you haven't thought or planned enough. But in the middle of a project, it may be inopportune to go back to the drawing board. To avoid indecision paralysis, just pick something. Sometimes it will be a suboptimal choice, but most of the time will be as good as any other, and only rarely will you choose a task order that is harmful.
    Sometimes, just do what you can do. But beware of avoiding things you don't want to do.

  • Don't Bang Your Head
    If you find yourself trying to do the same task repeatedly and having it not work, stop. If you are banging your head on a wall, it either means you need to look for a window, a door, a way around the wall, or you're working on the wrong wall. Perhaps you're just doing it wrong, and need to ask for help. Take a step back and look at the overall project. Is this wall even part of the plan? Is there something else you can do first? Sometimes nibbling at the edge of some other part of a project will make the whole thing easier in ways you didn't understand during initial planning. But most of all, doing something else will allow you to come back at the head-banging problem fresh, perhaps after your subconscious has had a chance to solve the problem.

  • Serialize Parallel Steps
    Some jobs require, or appear to require, doing several things at once. Typically, however, it's possible to take those things one after another, repeatedly switching among them. For people who find it difficult to juggle many tasks at once, taking this serial approach to parallel tasks may make all the difference.

  • Parallelize Serial Steps
    In Divide and Conquer, we saw that sometimes it's possible to accomplish parts of a task independently of one another. If resources permit, taking up several of these independent tasks at the same time, rather than one after another, may make doing them all easier. This is particularly true if there are helpers who can be working on the different pieces.

  • Delegate the Repetitive
    Computers, robots, employees, and tools are helpers. They give you the ability to parallelize, but require time for setup and maintenance, as well as for coordination and inspection of the finished work. Many times a skilled or well-designed helper can perform a task better than you can. Sometimes one of them, especially in the case of humans, really ought to be your boss. Confront (or ignore) such concerns and focus on the project. Delegate, and apply your own ability where it is best used.

  • Invent A Tool
    If you are having difficulty with a particular task, and no one seems to know how to do it, and you've followed all of the other points here, it may be time to step back from the process of doing, and become a toolmaker. Even if you lack the skill to make the actual tool, sometimes you can envision a tool that someone more skilled never thought of making, or never thought to apply to your use. Don't be afraid to invent a tool you will discard after the job. Toolmaking helps especially if you are banging the wall, or if you know you need to delegate a parallel task but don't have any helpers. The hard part will seem easy when you have the right tool.

  • Completeness
    Finish all of the parts, even the ones that don't show. Dependencies lurk everywhere. An incomplete or sloppy job at a minor task here, a corner cut there, and pretty soon you are wasting key resources on reworking tasks that you thought were done, introducing new dependencies and foiling all your plans. Do things right the first time, and do them completely.

Each of the above points could get an entire blog entry, and someday they may. Each of them deserves examples and other justification. Many deserve some scientific at least philosophical underpinning. For all of that, brevity won out.

No comments: