As Dr.Neil Roodyn says, keep your task duration/time down to a 30 minute average (which means your tasks can be anything from 5 minutes to 120 minutes in length, it’s the average we’re interested in).
Just as important as the task duration, is the need to ensure that a task can be both started and finished. Long-running tasks do nothing for a person’s (read: developer) motivation and desire to focus on the project in hand. There’s little point asking a person to do any more if their in-basket/work-basket is already overloaded with tasks that have been started, but not finished.
I call this role Starter-Finisher, Dr. Meredith Belbin calls it Completer-Finisher. Either way, the job needs doing; starting can be easy, which is perhaps why Belbin believes the role should focus towards the end of the task, i.e. the finish or completion.
Completed/Finished tasks elicit feedback, feedback drives quality, quality drives customer satisfaction and customer satisfaction drives profit.
So, the simple statement that this post is trying to make: if you start something, finish it. Don’t let anybody distract you whilst you are completing (working on) the task, try and set aside a suitable chunk of time that is free from interruptions. Remember, the shorter the duration [of the task] the more accurate your estimate of time to complete it going to be. If you have to, break longer tasks, e.g. longer than 2 hours, into smaller more manageable tasks. Of course, you may need to remind folks that it is your schedule, not theirs, and that contrary to common belief you won’t drop everything to work on their problem.
In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making
start it…finish it
In which Craig recommends developers keep their tasks short
[…] Getting schedule buy-in from the developers is key – give developers the chance to form and shape their own schedule, let them break tasks up into smaller more managable chunks that can be delivered over shorter periods of time, e.g. every 30 days or less. Don’t force them to buy-in to a [rolling] project plan that spans 6+ months – the speed at which the software business moves at, 6 months is far to far away: focus on what can be achieved now rather than later. Developers also need an endorphin hit every so often (cited as being every 2 weeks) – they get endorphin hits by starting and finishing a task, by seeing a piece of their code [go into production] in front of a user/customer or by visibily moving the project forward in some respect. […]
[…] In this series: #5 – Whose schedule is it anyway? #4 – Start it…finish it #3 – Use e-mail properly #2 – Focus on the project #1 – decision making [link] […]
[…] Failing to start it…finish it. Similar to procrastinating, we often find ourselves revisiting an activity or task thus incurring the “start-up smell” whereby we have to spend time “getting back up to speed”. Interruptions are a key indicator that tasks will be started and returned to at least once prior to completion. […]
[…] this series: #5 – Whose schedule is it anyway? #4 – Start it…finish it #3 – Use e-mail properly #2 – Focus on the project #1 – decision […]
[…] this series: #5 – Whose schedule is it anyway? #4 – Start it…finish it #3 – Use e-mail properly #2 – Focus on the project #1 – decision […]
[…] productivity… PM#6 – You were right and I was wrong PM#5 – Whose schedule is it anyway? PM#4 – Start it…finish it PM#3 – Use e-mail properly PM#2 – Focus on the project PM#1 – decision making […]
[…] productivity… PM#6 – You were right and I was wrong PM#5 – Whose schedule is it anyway? PM#4 – Start it…finish it PM#3 – Use e-mail properly PM#2 – Focus on the project PM#1 – decision making […]