How many from your recent projects or services did you deliver on time? Of course, complete and without the need to work overtime or on weekends.
Four years ago I started collecting photos of the problems that software development organizations face, regardless of the working method they use. Last year I started expanding my collection with photos from industrial companies.
Do you know which the most recurrent pain is?
– Project delays. Which in turn lead to cost overruns.
What increases the disappointment of the person accountable for a delay is that she has done everything to avoid it: she has tried to break down the work, address risks correctly, add buffer to the estimates, etc, etc.
Yet, Murphy’s law got in practice, “everything that could harm the project came at the worst possible moment”, e.g:
- A colleague got sick and her work had to be distributed among the other team members
- Two new important projects started, and their implementation had to be conducted in parallel to the rest of the work
- Some tasks happened to be more complex than expected, therefore it took longer to do them and this affected the other work.
- The approval from a customer or a supplier delivery arrived later than the planned date
- There was a crazy day when everyone was calling and asking for something, and the day ended without any progress on the planned work
- Etc, etc.
Do these reasons for a delay sound familiar to you?
Can you imagine a week when you do what you have thought, having all the information when you need it, organizing your tasks without the pressure to finish some before others, without interruptions, completing everything as well as you like?
Five days going home satisfied with the work performed and having time and mood to enjoy the evening with your family!
What causes delays?
The first reason that comes to mind is the estimates.
Estimates of what?
Traditional methods such as CMMI and PMBOK include practices on the development of a project / service schedule. These methods suggest the following to define a schedule:
- Break-down and define the work in sufficient detail
- Sequence the tasks
- Estimate the size of the tasks and hence the effort for implementation
- Take into account the availability of resources for work
- Take into account the levels of experience and training of the resources
- Identify and assess the impact of project risks
Traditional methods estimate the size and effort, but do not estimate the time for work completion (the fact that a task requires five hours of effort does not mean that it will end up 5 hours after being started).
Agile methods use fixed duration sprints (usually two weeks) and estimate the scope (user stories) that can be implemented in this time-box based on team’s velocity. That is, agile methods do not estimate the time of work completion.
If our problem is the deviation in time, why do we estimate effort instead of time?
The first enemy of meeting deadlines is confusing time and effort
Since I started studying in depth the problem of delays, the data from the companies where we measure these parameters shows that the effort ranges between 7% and 20% of the job execution time. For example, if the time between starting and finishing a task is 10 days, the effort that is allocated to it is less than 2 days. The rest of the time the task is stopped for different reasons: waiting for additional information, another urgent task, etc.
At Lean Kanban France-2012 Zholt Fabok presented even more worrying data: “95% of execution time spent waiting”. See Measure and Manage Flow in Practice for more details.
Time and effort are two different measures.
Separate their estimates, if you want to reduce delays.
When we stop a task in order to [re-]start another one, sometimes we have the feeling that both of them are progressing.
FALSE!
Multi-tasking only slows down the completion of the work and reduces productivity by 40%. (Samsung Business)
The second enemy of meeting deadlines is the amount of work in progress
Check Little’s law to understand that the more work at hand, the more it takes to complete each piece.
An example: in April Ander became dad for a first time. A happy moment in his life! Before leaving on a paternity leave he concentrated on completing as much work as possible so that his two team-mates did not stay task-less while he enjoyed the time with his son. He left a pile of designs started and not finished (the other two guys had to complete what was remaining). Consequence: the average job completion time increased from 13 to 21 days (an increase of 60%).
I know this is counter-intuitive. Therefore I suggest you to check it yourself by doing the exercise below.
Summary
Not distinguishing time and effort and the amount of work in progress
are two hidden enemies that always attack the deadlines.
If we want to reduce delays, we have to control the time of conducting work.
To reflect and feel the pleasure of delivering on time without stress, do the following exercise:
- For a week register the following information for each task you do: start date, end date, effort spent
- For each task calculates the Lead time = End Date – Start date +1
- Reflect on the following:
- Ratio of Effort spent vs Lead time
- Relationship between the average (Lead time) and average (Work in progress) (the number of open tasks) per day
- Let me know your thoughts.
Related posts:
• Lean Kanban Analytics: Lead time
• The Principles of Project Management that (Almost) Nobody Teaches
• Project Management with Kanban – Forecasting, by David J Anderson
