I have this little free-standing sign on my desk that I printed out years ago. It is a reminder of the things I've learned over time that help me Get Stuff Done and remember why I did it. I thought I'd share the list in case someone else finds it as useful as I have.
Although the list was inspired by my work in software development, looking it over, I realize that I've applied it to many aspects of my life. Good habits usually have universal application in one way or another. I believe these tips are useful any time you have complex tasks to accomplish, and who doesn't have a few of those?
In any case, here's the list...
Most worthwhile accomplishments cannot be completed in a single step. They require a goal, an action plan, and step-by-step implementation while keeping the big picture in mind. That requires concentration, and distraction is the mortal enemy of concentration.
Our world today is filled with distractions. Instant messaging, cell phones that buzz you about every email you get, and uncounted other things we've added to our lives that interrupt whatever we are doing to get our attention. While you are subject to those distractions, it is very difficult to get anything truly useful or productive accomplished. The next time you decide you actually want to get something done for a change, turn off the distractions and "batch" things like email into a deliberate time slot.
Just about anything you do can be done better. Our tendency is to come up with a way of doing something, and the next time we need to do it, just repeat the process. It's more efficient that way, right? We don't have to figure out how to do it all over again. That kind of thinking is fine for activities that occur rarely, but for activities that take up a significant percentage of your time, a little extra analysis may be in order.
The way to identify procedures that would be worth tweaking is to take a look at the things you have to do that you really don't look forward to. These are the things that frustrate you or that cause you to complain about the amount of time they take. Just stop for a moment. Is there a better way to do it that fits into your schedule better? Can you eliminate the activity all together by "outsourcing" it to someone else? Can you automate it somehow? If you think about what your time is worth to you, you may find it worthwhile to spend some time optimizing your biggest time-consuming headaches.
Just as we tend to use the same procedures over and over again without rethinking them, we tend to fix the symptoms of the same problems over and over again without taking a closer look at the true source of the problem. Granted, not all problems are worth solving. Sometimes it actually costs less to fix the symptom and leave the problem alone until a later time when fixing the problem is more necessary or convenient. But the decision to fix the symptom or the problem should be one you make deliberately.
If you have a leaky tire that requires you to go out every morning and pump air into it before heading off to work, doesn't it make sense to spend a little extra time and money to just get the tire fixed? Probably. But what if you only have to add air once every six months? Perhaps not. You'll most likely wear out the tire and need to replace it before the extra time you spend adding air adds up to the cost of fixing it.
You make decisions and take action every day based on circumstance, politics, and available resources. All of these things change over time, leaving you second-guessing yourself. Later, some of the decisions you made seem foolish because circumstances have changed, and you often don't remember the rationale for your earlier choices. When asked to justify your actions you end up scratching your head, frustrated with knowing that there were good reasons, but not remembering what they were.
I saw this a lot in the programming world. Software developers are mercilessly critical of each other's work. Turnover tends to be pretty high, and the next team inevitably blasts the work of the prior team. In most cases, this happens because the new team has no idea of the rationale for why decisions were made. Circumstances change and our processes need to change with them, but that doesn't mean the prior efforts were "stupid" or ill conceived.
If your actions are documented in any way, you should include why those decisions were made as well as what actually happened. Doing so not only gives you a way of retrieving that information later, but it adds quite a bit of dimension to your documentation. It shows that you really thought through your decisions and gives you an opportunity to explain why you rejected alternative approaches that might have seemed better on the surface.
Some activities in our lives are complex by their very nature. By complex, I don't necessarily mean difficult so much as consisting of multiple steps that must be accomplished in a specific order. One of the best ways to be more productive at complex tasks is to work from a check list or a set of instructions. An even better way to be productive is to outsource the task to somebody else, and that pretty much requires that you create a set of instructions for them.
It is particularly important to spend a few moments documenting complex tasks that you have to do repeatedly, but not often enough for the procedure to become habit. The next time you have to go accomplish one of those tasks, you can whip out your trusty check list and feel confident that you aren't forgetting something important to the process.
Plan for Change
As belabored above, circumstances change. You can help your future productivity by planning for change in the procedures you create. A good way to do that is to group closely related steps of your procedure into manageable chunks that can be modified (or outsourced) independently. In the programming world, we call this practice "modularizing."
You can go too far with planning for change. To be complete, my tip should be "plan for change, but act for today." Planning for change does NOT mean incorporating anticipated changes. That never works out well because whatever you anticipate will never materialize quite the way you expect, if it materializes at all.
When thinking about how to group your activities into "modules," think about how information moves from one module to the next. The more useful work you get done within each module and the fewer dependencies you have between them, the easier it will be to replace or outsource one of those modules later. In the programming world, this is known as "cohesion" (how good a job you've done at isolating closely-related work within a module) and "coupling" (how good a job you've done at minimizing the interaction between modules).
Plan for Reuse
Planning for reuse goes hand-in-hand with planning for change. If you are successful at breaking your activities up into independent modules, you not only make your procedures easier to modify, but you make it easier to reuse them elsewhere.
Outside the programming world, this tip can be a bit difficult to conceptualize, but what it comes down to is this: If you have to perform the same type of activity in multiple, unrelated projects, it makes sense to formalize the process in some way so it can be easily "reused" in all future projects.
Here's a simple illustration of what I mean. If you need to prepare a project status report in Word for every project you work on, it doesn't make sense to start from scratch with an empty document every time. At the very least, you should start with a prior document and modify it, but an even better approach would be to create a template that contains the basic elements every report requires, allowing you to more or less "fill in the blanks."
One of the best ways to deal with complexity is to eliminate it. While you are busy applying the other tips I presented, consider ways in which you can simplify or eliminate the process itself. Once you've established a routine, you often stop looking for ways to improve it. That behavior is a natural part of the rational process, because it really doesn't make sense to re-evaluate every process every time you perform it.
On the other hand, circumstances change, and it is natural for a procedure to become out-of-date, or for you to learn better ways to do things. The best candidates for re-evaluation are procedures that are time consuming, difficult, or expensive. Is there a better way? Can you replace it with something better, faster, or cheaper?
Note that there is a difference between optimizing and simplifying, although the simplest approach is often the most optimal approach as well. Optimizing focuses on getting the best benefit for the cost, while simplifying focuses on reducing complexity. A simplified solution may increase your cost or reduce your benefit when compared to an optimal solution. You just have to decide which is better in your situation.
All of the tips I presented have a common theme: awareness and cognition. They require you to actually stop and think about what you are doing. The distracting world we surround ourselves with (and yes, that is a deliberate choice) prevents us from keeping our attention on much of anything for any length of time, and without attention, there can be no awareness.
What I'm suggesting is that you become known for your actions, not your reactions. Make a plan, take action, and watch for ways to make things work out better next time. It's a fulfilling experience.
[For those who are interested, my Nerdy Musings web site has an abbreviated, programmer-oriented version of this list in my article 6 Keys to Programmer Productivity.]