Why is having a definition of done so valuable? I have grouped the benefits it provides into the following categories:

Higher Quality

Definitions of done should typically focus less on the activities people normally do and focus more on the activities that tend to be neglected or forgotten. In software development this means specifying activities that ensure the quality of the code being produced, rather than the actual act of coding. Quality often means much more than just few defects: it can also mean readable code, a clean design, or achieving any number of other non-functional requirements such as security, performance, and scalability. A definition of done that includes quality aspects serves, therefore, as both a reminder of the importance of quality in the day-to-day work and as a set of expectations regarding the level of quality to strive for.

Out of curiosity I decided to check out a number of publicly available definitions of done and count the percentage of items that clearly related to quality. Here are the results:

Standardization

A written, clearly-specified definition of done is essentially a standard. Standards provide many benefits when properly applied using a lean (pragmatic) mindset rather than a bureaucratic mindset. The proper mindset can be summarized using the following dichotomy: a standard represents the best way we know today of doing some activity within some context, yet each day we search for a better way so as to improve the standard. As implied by this summary, standards help form the foundation for future improvements. This is because following standards brings consistency which makes it easier to analyze the results of the work being done, determine the root cause of problems, and identify how to improve. For more on how standards help improvement efforts see my article on a framework for continuous improvement.

Standards have a number of other benefits. Checklists can be created from the standards for use by both the people doing the work (as a reminder of what to do), and by the people verifying the work (as a quality assurance check). Standards are helpful in training new team members. Having documented standards can also be helpful for achieving certain certifications like ISO or passing regulatory requirements such as Sarbanes-Oxley.

Most definitions of done do not mandate the specific step-by-step procedures to follow, but rather set expectations regarding the final product produced. To illustrate, a definition of done for coding features will likely mandate that certain kinds of testing be done (automated unit testing, functional testing, etc.), but will typically not mandate the sequence in which the testing and coding activities are done. (So unit tests could be written before the code as per test-driven development, or they could be written afterward - either approach will satisfy the definition of done.) Team may choose to standardize which procedures are used, but this is typically kept separate from a definition of done.

More Accurate Estimates

Having a definition of done helps estimation accuracy in two ways. First, it serves as a checklist of all the steps required to complete an activity that can likewise be used to estimate the effort remaining. When estimating the work left on a feature, for example, a definition of done can help ensure that time is estimated not just for the coding, but also for reviewing and testing.

Second, a definition of done makes it easier to track the actual progress, since activities reported as done are more likely (but not guaranteed, unfortunately) to actually be done. This means there will be less surprises in terms of additional work required for previously 'completed' assignments. These surprises, of course, significantly reduce estimation accuracy, so the more they can be eliminated the better the estimates.

Better Teamwork

The previous benefits apply when you are working on your own, but software development is more commonly a team activity. And in addition to these prior benefits, having a definition of done will make your team more effective. Many of the challenges of working in terms such as achieving unity of purpose, clear communication, and coordination of effort, benefit from having a definition of done. When team members are communicating about the work that has been and needs to be done, having a clear definition of done helps avoid misunderstandings. The definition functions, in essence, as a communications technique for ensuring that when team members use the word "done" they all mean the same thing.

For examples of what happens without a clear definition see this story of a team of five having three different viewpoints regarding done and this story of someone reporting a status of 'finished' that really wasn't.

Concluding Thoughts

This article has mostly discussed definition of done in the context of software development and specifically coding, but the concept is much more broadly applicable both within I.T. and beyond. Staying within I.T. I can see the benefits of having definitions of done for activities such as incident resolution by support staff, product high-level requirements definition, and pursuing sales. So I challenge you to look for opportunities to use a definition of done to help achieve superior performance.

The very first thing to do to minimize email distractions is to disable in Outlook all the indicators (like the bell, pop-up that fades, and system tray icon) that announce that a new email has arrived. I have always found these annoying and disabled them years ago. (Why are they enabled by default?) Every productivity expert I have read who mentions email also makes the same recommendation, so if you are reading this now and have those indicators set stop and disable them.

Without these indicators I still found myself becoming distracted by email. A typical scenario would see me working in one of my dedicated blocks of time focused on a task when I needed to either send an email or refer to an old one. I would open Outlook, see all the new emails in my inbox, and get distracted with reading and/or responding to them, especially if they were marked high priority. (This is the classic mistake of doing the urgent instead of the important.) So I tried a number of approaches.

First I tried to figure out how to send an email without opening Outlook. I wanted a shortcut in my Windows quick launch bar to do this, but what would have been trivial in an Unix environment turned out to be surprisingly difficult. In fact, I couldn't figure out how to do it using a command-line script, and I wasn't about to spend the time required to write a .Net program to do this. (If you know how to do this or know of such a program please let me know.) The best workaround I found was to invoke the Windows Run command (normally found in the start menu, it can be invoked by the shortcut of the Windows key + R), and type in the command "mailto:". The extra keystrokes were enough to prevent me from adopting this as a regular practice, and this didn't help anyways when I needed to reference an existing email.

Next I tried to figure out how to have Outlook check for incoming emails less often. I found a number of settings that seemed relevant, but they had no effect. New emails were still detected in less than five minutes. I was not sure if I missed the correct setting in Outlook, or if it was taking its email-checking configuration from the Outlook server. (If you know, please pass along the information via a comment.) In either case, I was pretty unhappy with Outlook. I considered simply shutting it down, but I needed it running in order to provide reminders for all the meetings I had scheduled throughout the day – including reminders for my personal design times.

I finally found a workaround through a coworker – switch Outlook to offline mode, and it will no longer check for emails. When offline Outlook does not send emails either, which was mildly annoying but a limitation I could live with. It took me less than a week, however, before I discovered another major limitation: while in offline mode changes to my schedule would not be communicated back to the Outlook server (and become visible to others) after I went back online. I discovered this via a not-so-amusing exchange with a coworker who was trying to book a meeting with me for an afternoon he saw as free that I had booked something while offline. The workaround to this annoying problem was to discipline myself to treat my calendar as read-only while Outlook was offline. Despite all the issues, offline mode worked quite well for me.

Recently, I have become more disciplined about remaining focused during my solo blocks of time and have found myself using offline mode less often. This seems to work best for me when I am crystal clear on my priorities (usually due to an impending deadline), so when I do see an email that would normally distract me I immediately think "not a priority" and file it for actioning later. There is usually a small amount of mental effort / distraction involved in scanning the email and making this decision, so it would be better to not have the emails come in until I want.

What approaches do you use to avoid getting distracted by email? I would love to hear your ideas, so leave a comment below.

Use a "Do-Not-Disturb" Indicator

My first approach involved trying to prevent people from dropping by my cubicle and distracting me. I placed a sign marked "Do Not Disturb" on the back of my second chair. When I did not want to be disturbed, I moved the chair so that the sign on the back was visible to anyone approaching my cubicle. I informed my coworkers of what I was doing and they were generally (but not entirely) supportive. This approach helped, but had a number of limitations. Coworkers having a discussion in an adjacent cubicle were sometimes distracting, especially if they mentioned my name or if they were discussing a topic I found interesting. I had to learn to remember to put out the chair when I needed to concentrate – sometimes I forgot. I had to learn to stay focused and not let myself get distracted by other conversations – this takes discipline and I find is an ongoing battle. Coworkers sitting adjacent to me had to learn to be careful asking questions to me over the cubicle wall, as they could not see whether I was in do-not-disturb mode. The biggest limitation, however, was that it did nothing about all the meetings I was being scheduled in. Some days I was scheduled in meetings for most of the day, with only small gaps of an hour or less between meetings.

Block Personal Time Between Meetings

The multitude of meetings prompted my next approach, which was to block off time – a minimum of 1.5 hours - in my Outlook calendar between meetings for my own solo design tasks. Doing this also helped with my previous approach: when the time for one of these blocks started the Outlook reminder prompted me to deploy the do-not-disturb chair and focus on my design tasks. The downside of this approach to my team members is that I became much less accessible, either for impromptu drop-ins or for scheduled meetings.

Schedule "Please-Disturb" Times

To address this issue of reduced accessibility I adopted a practice that ironically is the opposite of the previous one: I scheduled "please-disturb" times (in Outlook) during the week for team members to ask questions and get feedback on their work, and communicated these times to the entire team. While I wanted to ensure I was still available to the team, I hoped that having a scheduled time to talk to me would reduce the number of unscheduled drop-ins. In practice this saw mixed results for obvious reasons: team members with questions or needing a review sometimes did not want to wait a day or more, potentially impacting their ability to get work done, in order to wait for a scheduled time. But the approach did work in guaranteeing a certain amount of availability to the team.

Block Personal Time First When Most Productive

After a while using the approach of blocking personal time between meetings I started to notice some patterns. I always seemed to be most productive first thing in the morning rather than after one or more meetings. After meetings my mind is less fresh and I am sometimes distracted by issues discussed in the meetings. Plus I personally have a higher energy level in the morning than the afternoon.

So the idea occurred to me to schedule blocks of personal time first thing in the morning when I am most productive and best able to focus. I also aimed to make these blocks longer – at least two hours and preferably three – than the blocks of time I was scheduling between meetings. I found scheduling these blocks in the current week hard due to meetings, so I started scheduling then in advance. First I scheduled them just for the next week out, but I found this insufficient so I switched to scheduling them a month in advance, and in some cases set up reoccurring events in order to permanently block certain mornings. I then sent an email out explaining what I was doing and that I would be unavailable for meetings most mornings before a certain time.

This approach did cause grief for people trying to schedule a meeting with me as it became much harder for them to find time for me. I have had to make compromises – typically by sacrificing part or all of a blocked morning to important meetings. But otherwise I am very pleased with the boost in productivity I have experienced as a result.

A logical extension of this approach is to expand this practice out to the entire team, so that everyone has the same meeting-free and interruption-free blocks of times throughout the day. I have heard of this being done but have never tried it, partly because other team members typically have far fewer meetings and drop-ins than me. If you have been part of a team that has tried this, please leave a comment describing your experience.

How Does it Work?

The basic concept is simple: clearly identify the next task you should work on, write it down as your next step, and then work on it. Given a typically large set of tasks – what I like to refer to as to-dos from a to-do list – a lot of time can be wasted jumping back and forth between tasks and figuring out what to do next. This is especially true when you are inflicted with frequent interruptions, distractions, or breaks.

How you choose the activity for your next step is critical. While the decision should take into account multiple factors such as importance, urgency, and time available, I believe the primary factors that you should use are motivation and progress-ability. Which task are you most motivated or interested to work on next? For which activity do you have the clearest idea of what to do next in order to make progress? By emphasizing these two factors you maximize your productivity on each task: you are as motivated and as clear as possible as to what needs to be done. This is especially true when the tasks are all related to a single project, such as coding functionality for an application. In this case it matters far less what order the work is done in than the amount of progress you make each day.

Putting it into Practice

A key ingredient to implement this technique is a simple and fast method for recording tasks for a piece of work - what I like to call a to-do list. This is necessary because when you are working on your next step and identify an unrelated idea or issue, you need to write it down on this to-do list to get it out of your mind and avoid having it distract you from the task at hand.

I use different approaches to implementing the next step technique depending on the work I am doing.

When writing code in my IDE (Integrated Development Environment), I record to-dos as special code comments that the IDE filters and displays as a list. Instead of recording my next step in a similar fashion, however, I record my next step on a piece of paper on my desk. I use this low-tech solution for a few reasons. The next step is often not as fine-grained as individual to-dos, and may include several to-dos and multiple source code files. Writing it separately allows me to express it at whatever level of detail is appropriate. Using a separate piece of paper provides an area for me to jot down brief design notes, if necessary, as I work on the task and need to resolve design issues. When the task is complete I cross it off on the paper and write down a new one, perhaps flowing logically from the current task or perhaps pulled from my to-do list in the IDE.

When writing large documents in Microsoft Word or Open Office, I use a different approach. Before I write content, I start with some sort of outline – usually a partial outline that I expand and refine as I write. I represent the sections of the outline using headings within the document. Correctly using styles for the headings allows me to use features like the document map or outline view in Word to view the outline. I represent to-do tasks using the text "TODO" with a yellow highlight. For sections that I have not yet started or are incomplete I suffix the heading of the section with this to-do text in parentheses. This allows me to view the outline and see what sections still need to be written. When I choose an outstanding section as my next step, I prefix that heading with the text "NEXT STEP" with a red highlight. When I finish the content for that section, I cut and paste this text to the next section I have chosen.

Why It Works

This technique incorporates a number of elements that make it effective in several ways:

Improving Focus: Explicitly choosing and writing down your next step and providing external storage for any extraneous ideas that come up (your to-do list) helps orient your mind towards the task at hand and keep it free of distractions, which improves your ability to focus on it. I find this especially useful for tasks which I must do but have lower motivation for: my mind tries to suggest distractions to derail me, but my strong focus makes it easier to push through and get the work done.

Recovery From Disruptions: Having your next activity clearly identified in writing makes it much easier to resume work after a break or interruption.

Maximizing Productivity: Choosing your next step based on motivation and progress-ability maximizes your productivity on each task you work on.

Your Next Step

I challenge you, the reader, to immediately put this technique into action. For your current project or to-do list deliberately decide on your next step and write it down. Let me know via the comments below how this technique works for you and how you adapt it for your own use.

1. Say No To Meeting Invites

The best strategy that I find the hardest to use is to turn down meeting invites. Being asked to attend a meeting is often an acknowledgment that your input is valued, especially the more senior the other attendees. Furthermore, meeting with senior technical or management people is often beneficial for your career, while repeatedly turning down such meetings is not. This produces a natural inclination to want to attend meetings. To combat this, I ask two questions to determine if the meeting is worth attending:

• Can I reasonably expect to make a useful contribution at the meeting? In other words, will others benefit from me attending the meeting?
• Can I benefit from attending the meeting?

If the answer to both of these questions is no then it becomes easier to decline the meeting invite. Unfortunately, few meetings meet this criteria.

2. Leave Meetings That Do Not Deliver Value

If you are in a meeting that is not providing any value for you being there, then one option is to get up and leave. Your ability to do this will depend on your role in the meeting and your corporate culture. I have heard that at ThoughtWorks it is considered acceptable and normal for anyone to leave a meeting at any point if they do not feel it is worth their time to be there. The organizations I have dealt with have not had such enlightened cultures, but I have used and have seen others use this strategy at times. This strategy works best when you are an optional attendee.

3. Tentatively Accept, Then Choose When To Go

Regularly scheduled status meetings are a significant percentage of the meetings I am asked to attend. This is especially an issue with being on multiple projects when each has one (or more) regular weekly or biweekly meetings. The biggest problem with regularly scheduled meetings is that they consistently use up your time, week after week, and I find that they deliver limited benefit for the time spent. One strategy I use is to only tentatively accept the invite for such meetings. This gives me the freedom to choose not to attend, whereas accepting the meeting creates the expectation that I will attend every one. This works especially well for formal meetings with published agendas and minutes. If the agenda has items that are worth my time to attend, I will, otherwise I'll just browse the minutes or talk briefly with someone else who attended.

4. Double Book Meetings

Double booking two meetings at the same time is another time-saving strategy. With two meetings scheduled for the same or overlapping times, you can choose which to go to, with an excuse for missing the other that almost every manager will accept. This works especially well when one of them is a regular status meeting that you can afford to skip. Another option is to attend a portion of both meetings. At the start of the first meeting if you point out your need to leave early, you can often get the agenda shuffled to talk about the issues requiring your attendance first. You can then leave for the second meeting having derived most of the value from the first meeting in a shorter period of time.

If your organization uses a shared calendering application that allows you to see the availability of others when scheduling meetings then using the prior strategy of tentatively accepting meetings makes it easier to get double bookings, as others will schedule meetings for when you are tentatively available. This in turn makes it easier to only tentatively accept their meeting, with the excuse that you may have another at the same time.

5. Penalize Projects For Meetings

A different strategy I use is to "penalize" projects for wasting my time in status meetings. I accomplish this by allocating a fixed number of hours per week to each project. If I only allocate four hours a week to a project, and the project manager wants me to attend a one hour status meeting each week, then that uses up 25% of my time for that project. I have at times emphasized this point. When asked in a status meeting how long it will take me to finish a task, I'll point out that I lost an hour due to the meeting, and thus have one less hour left in the following five business days to work on the task.

At this point you may be getting the impression that I think that status meetings are always a waste of time and do everything to avoid them. Not at all. Status meetings are useful for a variety of reasons, and I do attend a fair number of them. Since I am expected to produce work outside of meetings, however, I do need to ensure that I have significant blocks of non-meeting time available.

6. Schedule Meetings With Myself

It seems ironic that one solution to too many meetings is to schedule more, but it works. When I absolutely need to get a piece of work done, I'll schedule a meeting just for myself to work on the task. This strategy works best when your organization uses a shared calendering application such as Microsoft Outlook that allows you to see the availability of others when scheduling meetings. Other people trying to schedule a meeting with you will see that your schedule is busy and change the meeting time to accommodate you. If the topic is urgent, people may decide to meet anyways without you. In order to make progress on significant work tasks, I sometimes schedule full-day meetings one or more days in a row. The downside with doing this is that the next few days afterwards tend to completely fill up with meetings if I am not careful.

There are several variations of this strategy that I use as well. When others want me to review a design or document with them in a few days and ask when I will be available, I tell them to schedule a meeting with me. This ensures I'll have a block of time available that day to meet and go through what they want reviewed, rather than waiting till that day and risk having it fill up with other meetings. When I am waiting for others to do some tasks for me, and not seeing results for a significant period of time, then I will schedule a meeting with them which they will invariably accept. When they come to the "meeting", I review the tasks I am waiting for and then explain that the next hour (or however long the meeting is) is for them to work on these tasks. My logic is hard to turn down: if they had the time to set aside to meet with me, then they have the time to do my tasks.

Too many meetings can sap your productivity and prevent you from achieving the state of flow when working on a design or coding task. So a necessary component of managing your time is to manage your meetings.

For a working professional, the best opportunity to learn by doing is at work, as I wrote about in my article on learning in the workplace. But if this doesn't work out - perhaps you want to learn a technology not used at work - then the alternative is do so on your own time. I refer to each personal learning task that I take on as a personal development project. I use the term project because I prefer to invest significant effort to ensure I better retain the skills I am developing. Spending just a few hours one time is not enough.

The first step is to pick something to do for a personal development project. If your goal is to learn, then there should be some novel element to the project that you have not yet been exposed to. An example for software developers is using a new language, a new library, or a different design approach. I highly recommend choosing something that you are strongly interested in and motivated to work on. There are typically no external motivators like a paycheck or a supervisor, so the stronger your internal motivation, the better. I have started projects highly motivated, but then circumstances changed, I lost interest, and as a result I made no further progress.

It is not actually bad to fail to complete a project. If your goal is solely to learn a particular skill, then you may feel you have accomplished this before you are completely finished. In my experience, I have noticed that many of my personal projects have some less-interesting and less-educational work required in order to complete them. When I get to the point when this type of work is left, unless I have a compelling reason to complete the project, I stop. The decision to stop or continue is based on a cost-benefit analysis: what value do I derive from continuing this project compared to the time and energy I will invest in it?

The biggest challenge to working on personal development projects is finding the time and energy. I find I need a good block of time - ideally at least a couple of hours . I also need sufficient mental energy: trying to code in the evening after a day spent developing code at work seldom works. So weekends end up being the best time for me to work on my personal projects. This means that a week passes before looking at the project again, so I find I need to keep more careful track of where I am at and what I am planning to do than if I was working on the project on a daily basis. At work, there are periods when I am not doing any heavy coding or designing due to spending my time on other activities such as requirements-gathering, reviews, documentation, planning, etc. In these cases, I find I still often have the mental energy to code in the evening after work.

As a software developer, many of my personal development projects do involve developing software. At home I maintain a complete development environment with all my favorite open-source software. My Software page contains some of the results of these projects. But a personal development project can be something completely different. For example, when I read Getting Things Done : The Art Of Stress-Free Productivity by David Allen, I wanted to try out the organizational system described in the book. So I started a personal development project to set up and use this organizational system. This project was a success - I am still using the system today. Another example is this website. Setting up, operating, and writing articles for my website has been an incredible learning opportunity, exposing me to activities that I have not had the chance to do at work such as visual website design, server log analysis, and operation of a publicly-facing web application.

Learning by doing is a powerful tool. I challenge you to set up a personal development project and start benefiting from it.

One common strategy is to allocate a fixed amount of time each week to one or more of these important tasks - usually about four hours a week, which is only 10% of a 40-hour work week. Since it is usually more efficient to use a larger block of time for one task, a common variation is to allocate an entire day less frequently - one day every two weeks is still only 10% of the total work hours.

I have found a couple of difficulties with this fixed-time strategy. The first problem is actually choosing when to spend this time. For example, at the start of one week I decided that Friday afternoon would be reserved for important, non-urgent tasks. But on Friday morning a serious operational problem was discovered that required my attention for most of the day, and the important tasks had to wait. The second problem is that working on a task for only a fixed period of time does not mesh well with my preferred style of working. I find it most productive to break up a task into separate pieces and only switch tasks after completing a piece - not in the middle.

I therefore developed a strategy that works better for me. Whenever a week goes by in which I have not made any progress on my important, non-urgent tasks, I choose one of these tasks as my next major work item. In my next available significant block of time I work on this task, ignoring all but the most urgent issues. My goal is to complete one or more logical pieces of the task. I don't pay particular attention to how long it takes, although it is usually no more than a day.

Another strategy that works well for me is to gradually increase the urgency of a neglected important task until it is done. This is how I ensure I regularly exercise. If I miss a workout, my sense of urgency about it starts to increase day by day until I finally do it. The key to this approach is that you need to hold a conviction about the importance of the activity and why a continued delay in doing it would be bad. The case for exercise is simple: the benefit comes from regular physical activity - a minimum of three times a week is recommended - so the longer the interval between workouts, the worse the effect on my health.

These strategies are based on a common principle from Stephen Covey's book First Things First which classifies activities into four quadrants based on their importance and urgency. My description of tasks as important or urgent is based on the classification from the book. This common principle is to choose the important over the urgent. Unimportant tasks, even if urgent, should be neglected in favor of important tasks. While urgent important tasks need to get done quickly, it shouldn't be at the expense of non-urgent tasks that are equally if not more important.

Making time for the important is often a challenge. I have presented some of the approaches I use to ensure that important but non-urgent activities get done. If you have particular strategy that works well for you, please share it.

While the research for this book was performed on larger, publicly traded corporations, I believe the same principles apply to smaller companies, non-profit organizations, and even to each of us as individuals. One factor of greatness I found particularly interesting was the concept of a "Stop Doing" list. To quote the book:
"Most of us lead busy but undisciplined lives. We have ever-expanding 'to do' lists, trying to build momentum by doing, doing, doing - and doing more. And it rarely works. Those who built the good-to-great companies, however, made as much use of 'stop doing' lists as 'to do' lists. They displayed a remarkable discipline to unplug all sorts of extraneous junk." (page 139, Good to Great)

This quote resonated with me. Several months ago, I implemented a new organizational system (see my article Getting Things Done for the details), which improved my ability to manage my tasks - my 'to do' lists. I found myself becoming more aware of everything that was on these lists. I realized that I was great at generating ideas for tasks to do, but I would automatically add these ideas to the appropriate 'to do' list. As a result I would become busier, yet accomplish less of what I really wanted to do. The solution slowly crept into my awareness and then finally crystallized when I read the above quote: I need to do less in order to do more.

In order to make a 'stop doing' list, you must have a clear, focused goal of what it is you do want to do. Then to actually stop doing the items on the list requires discipline, as the quote above states. Clear goals and a culture of discipline are two of the other distinguishing factors of greatness discussed in the book. These need to be in place before a 'stop doing' list will work.

So here's an assignment: stop reading and take two minutes to think of one activity in your life that you can do without, then commit to not doing that activity for 30 days.

Things that I really liked from the book:

• The concept of the 'next action' runs throughout the book. For any project / task / meeting, it is extremely helpful to ask the question 'What is the next action'. A next action must be something physical - something tangible and concrete. A typical example: you have a task to hold a meeting on some topic. But that's not an action. A next action would be to create the agenda, or to create a list of attendees. Determining the explicit action and writing it done is often mentioned as a key ingredient in achieving your goals and visions, so it was interesting to see it presented as a key component of the book's organizational system.
• Everything in your head is written down, even items not worth doing now (if ever). This clears your mind from worrying about these items, since they are recorded in the system.
• Actions are organized primarily by context - the environment available to you. For example, an action to discuss something with your manager requires the presence of that person, while an action to purchase new office supplies requires you to go to the appropriate store.
• The weekly review is a key aspect of the overall system. Once a week you systematically review everything recorded in the system and make sure nothing is being neglected. I've tried before certain techniques from the book's system like maintaining a waiting for / delegated task list, but it didn't work because I didn't systematically review it.
• The book's recommendations for organizing the filing system worked great. It seems like such a low-level, mundane issue, but it really does make a difference in terms of the overall system.
• The book did a great job explaining the reasons behind the different pieces of the system, most of which are based in human psychology.

I've implemented the book's organizational system and it has been working quite well so far. I did encounter a few issues:

• It took a few days to fully implement the system, during which time I wasn't getting much of anything done. However, this included cleaning up all sorts of old files & papers and a re-organization of my office area, both of which were long overdue.
• The book did a decent job of discussing different approaches for actually storing / managing the recorded information - i.e. paper in folders, paper lists, electronic - but naturally left the choice up to the reader. It was a little tricky to try and figure out the approach that would work best for me without yet having used the system. There are one or two things I may still tweak.
• I'm still trying to determine how to coordinate my paper-based actions with my email-based actions. For example, I record an action in my paper system which results in me sending an email and waiting for a response. Do I keep the action in my paper system? Probably not, but what if after the email response, there is a follow-up action that is offline?
• The new system requires a higher level of discipline than my old, less-organized system. I think I'll be able to maintain the new system (I consider myself fairly disciplined), but certain personality types may have greater difficulty. The book never addressed this issue, and in fact implicitly makes the point that to survive in today's information age, particularly as an executive, requires you to have a highly disciplined system for managing the information & tasks that come your way.

I recently came across the following quote: "Time can't be managed, only activities can.", by Earl Nightingale. I think that's a good summary of what Getting Things Done is all about. I highly recommend reading this book and try adopting the organizational system it presents. You owe it to yourself and to those who are depending on you.

What's your next action?

The same concept is discussed in the book First Things First by Stephen Covey, which I highly recommend reading. In First Things First tasks are classified according to two dimensions: importance and urgency. Covey says that we should spend our time on the important tasks before addressing the unimportant. This seems obvious, but he explains that the natural tendency is to address the urgent tasks, whether or not they are important, which leaves one with no time for the non-urgent yet important tasks. Part of the difficulty is determining which tasks are truly important: this is aided by having a clear set of goals.

Of course, thinking about goals and the importance of tasks takes time. And if you are 100% busy with urgent tasks (i.e. always fighting fires), then you probably feel like you can't afford to spend this time. In reality, if you are that busy, then you can't afford to not do this, or else you risk never completing some (all?) of the important tasks. I view the time spent thinking about goals, objectives and task importance as a planning component of time management. Planning is usually considered a management activity, and everyone needs to manage their time. So if you aren't doing any planning at all of how you spend your time, it probably is not well managed.

I think that the points DeMarco and Covey make mesh together quite well. You need to regularly review and update your goals and objectives based on changing circumstances, both internally (i.e. completing some objectives) and externally (i.e. new technology, new competitors, new market). You also need to reflect on your work - the importance of your tasks, how you work, and improvements that can be made. However, I really don't like calling this slack time - I consider it an integral part of professional software development.