Start big tasks or small tasks first?

Regularly on my projects, there’s an assumption to get going on the big challenging tasks early and finish the easier tasks at the end.  It’s an interesting assumption because there are advantages and disadvantages of each approach.

“Big tasks first, small tasks after” reduces risk later in the schedule. If you may run out of time, starting on the more challenging items first will give you the earliest warning of possible schedule risk.

“Small tasks first, big tasks after” allows following subsequent tasks to start earlier. If your project has people waiting to start their work once predecessor tasks are completed first, completing small tasks earlier gets them started sooner (e.g. testing functionality after development).  This validates the approach and organizes who needs to be involved earlier.

The arrow points at extra available time to coordinate any issues for the future tasks and establish a process earlier in the project.  This enables your team to figure out any processes and communications early on.  Imagine of you had to redo Big Task 1 or Small Task 1 because the subsequent items just won’t work – good thing you tested the process with a small task!  This can save your project because any delays in the “Big tasks first” approach will push out your schedule.

Apply this effectively

When planning your project, consider where process-related holdups could occur.  These delays will affect your schedule.  Separately, under-estimated tasks will be apparent earlier if you start big tasks first.  I see process issues causing more delays than under-estimation issues, so I recommend the “small tasks first” approach.