Increasing productivity and achieving more from existing resources is a challenge every software development business or team manager faces.
People apply buffers in an ad hoc way in their day-to-day life, most likely without realising it. When someone leaves home early because they assume there will be traffic, they are giving themselves a “paranoid” buffer of time. The “hysterical” buffer would be leaving so early that they are protecting themselves for extreme variations e.g. in case there is an accident, or Godzilla is found roaming the city, blocking roads.
It is common for businesses to work out the profit of each job (product or service), and then seek to produce more of the ‘more profitable’ jobs.
When deadlines approach, it commonly triggers supervisors to try and cause on-time performance by expediting or rearranging the sequence of work, switching between jobs and multitasking. Taking such actions close to the deadline is often referred to as “end of month syndrome” or “student syndrome”.
Currently in the marketplace, the majority of businesses are under the assumption that ‘on time’ means ‘in control.’
When we are implementing change projects, we commonly rely on waiting to see what results happen, and we adopt the tactic of letting the results, when they occur, create stakeholder ‘buy-in’.
People know that when working on a task there is a high probability of variation arising that increases the time to completion. This knowledge causes people to be very hesitant in providing accurate duration estimates of tasks and projects when they believe they are going to be held accountable for an estimate that leaves no room for error. This results in three problems that interact:
If you’re interested in how your business is performing, you probably have, or want to implement some measures.
Changing behaviour is harder than it looks every year at 9am on January 1st. On that special date, at that point in time, everything is possible (though much less probable than we’d like to believe).