Approaches for breaking down big tasks

This is not an introduction to project management, a profession dedicated to turning a need into a set of tasks that can be executed and monitored. This is aimed at the individual. In a separate post I’ll cover how to build on this if you have a responsibility for a team and the option to delegate tasks.

When I was learning to be a project manager I was given two rules of thumb for task decomposition. The first was: break all tasks into chunks of no more than 2 weeks and each chunk should be verifiable. The second was: never allow the longest task to be longer than you are prepared to be late. If you are reading this you’ll need to tailor that approach. In project management and individual task management there is a trade-off between granularity and the cost of the process. To manage a 3 year project with 50 people working on it by planning out effort to the nearest ¼ day is overkill. To manage your own time in weekly chunks is clearly not granular enough. My recommendation is to break tasks down into chunks that match your attention span.  If you can focus for 2 hours – great. That is your planning time box. I’d advise against going longer than 2 hours, but I’ve not yet coached anyone who thought they could concentrate for that long. If you can only focus on a single thing for 20 minutes use that. I use 50 minutes (scheduled in my calendar as an hour so I can have 10 minutes to make a cuppa).  I recently had the task of reading the PRINCE2 Agile book in preparation for the exam. Rather than have that as a line in my actions list I looked at the number of chapters and the number of days until the exam. I use a Bullet Journal, as covered in an earlier post, so I set daily goals for completing particular chapters. I’ll cover more on tips for business reading for dyslexics in a separate post.

There are 3 approaches I recommend for breaking down tasks depending on the characteristics of the task

Familiar tasks that you have done before can be broken down into chunks matching your attention span. If I need to recruit a web developer I might break this down into: write job description, document hiring justification to boss and confirm post funding, meet HR to give them job description and agree recruitment timetable, source paper sift panel and arrange sift sessions, and so on. Like many tasks I can’t decide to sit down and bash through all of this in a day or so as there will be times when I need to wait on things (applications coming in, availability of other application sifters). Working through all the steps and the likely gaps (lag) between them will give an indication of how long the entire task will take to complete.

Unfamiliar tasks  are a little trickier. It is not unusual to have  a task where you don’t really know what’s involved and you can’t break it down into tasks because you don’t know how long any of it will take. Here you can look at the elements that make up that task (in project management this is product based planning). If you wanted to start producing a podcast your first pass at breaking this down might be to identify the elements: record, publish, advertise. This first pass is often enough to get some task traction. The record task will need some recording equipment, possibly a test run, some content for the show and each of these can be further broken down if needed. Chances are if you have never published a pod cast the next element will pose a challenge. There is probably some uploading to somewhere involved and perhaps something to do with iTunes.   For the publish subtask we are going to have to do a bit of research – so that’s the task. We now have the advantage that we can be a lot more focused with our search: we no longer need vague search teams like “how do I podcast” but instead can use focused terms like “publishing my first podcast” or “how to upload a podcast”.   You can set tasks to determine how to do each of these.

Some tasks fall in-between these two extremes. Some tasks don’t have a fixed end date by which they need to be completed. In these instances the Getting Things Done technique of identifying the next action works well. In GTD anything that takes more than 1 step to accomplish is called a project. While it’s not the definition of project I’d use, I certainly agree (in both contexts of the word project) with David Allen that projects don’t get done. You can’t do a project, you can only do all the tasks that make up the project. The reason many to-do lists fail is because they contain stuff that can’t simply be actioned. They are cluttered with things like secure new customer account, redesign website, learn python. I’m not a GTD purist so what follows is more inspired by GTD than GTD as written. For these three projects the next action might be: phone 5 qualified leads and update CRM tool, review website feedback to identify priority areas to improve, find 3 online python courses that start in the next 6 weeks. When that task is complete the next action is added to the actions list. I like to always finish a task having identified and captured what the next action is as I find it makes picking up the state and resuming the task easier. I also like to leave a few 5-minute actions on the list so I have something productive to do if I find myself between meetings with a little bit of spare time.  GTD is a great book, well worth the read, or listen on Audible. Or if video is your thing there is a 90-minute overview on Lynda.

Why go to all this bother – especially for known tasks where it is easy to reel off all the subtasks? These sub-tasks can serve as a powerful motivator and also a progress indicator. If you track your progress against the sub tasks you also benefit from the learning opportunity, as you can start to see what takes a lot of time. When tracking progress a task has 2 states: done or not done. Working in software projects many programs were 90% complete for months which was no help in working out what caused delays! Breaking down big tasks into small subtasks removes the need to guess at percentage complete. Finally, and most powerfully, breaking down tasks will help you identify steps that may be eliminated, automated, or delegated.