Category Archives: DevOps

By the end of next week

Just a recap of a one-to-one meeting I had a little while back with a colleague and an on-the-spot thought experiment that came to mind.

I am well known for arranging even apparently small pieces of work as a project and how it is essential to break them down into bite-sized, well-scoped tasks.

As part of the planning exercise I asked my colleague how long she thought it would take to complete task X.

By the end of next week was the reply (Aside: is it just me or do most people think the end of next week is a reasonable length of time to complete a discrete piece of work?).

Now, my colleague is a working mum and only (I say ‘only’) works for 25 hours a week. Having heard ‘the end of next week’ so many times triggered a quasi-mathematical thought in me and it goes like this:

  • You have 25 hours per week for work, so by the end of next week you have a total of 50 hours available,
  • assuming a 20% utilisation rate for this particular task gives a completion allowance of 10 hours,
  • so, if you started it now and worked on nothing else (chance would be a fine thing)  would you have it completed by the end of tomorrow – the next 10 hours?
  • No.
  • Then the end of next week isn’t long enough. Allow another two weeks.

The consequence of this type of thinking is that this simple seeming little task that you’ll be squeezing in with everything else is actually going to take a month to complete.

Now, this idea makes people really uncomfortable but the reality is that it actually does that long to complete these pieces of work – I’ll discuss soon of my ideas around working inefficiencies that lead to this later – and that accepting this position we (can hope to) remove some of the pressures we experience when we don’t seem to be making much progress toward the goal and enter the panic spiral as we get closer to deadline.

This idea is intended to be a way of self-analysing expected effort and estimating/guessing whether it might be achievable by the expected deadline. This is also about allowing people to brave with their assessments and not afraid to suggest something that might ordinarily appear to be unreasonable.

As a follow-on from this, there will be situations where the PHB says this isn’t acceptable and the item needs to be delivered sooner. Well, in this case it can then be seen that something else will have yo make way to free up time for the task. This is agreed up front so everyone is at the same level of expectation. This should help contain the stress on the task implementer believing they are expected to complete a task in addition to normal activities. A too-short delivery window can increase the pressure in a way that worrying about completing the task on time detracts from the task itself and leads to a vicious circle.

I include this under the DevOps category because it is entirely cultural  and experience suggests many organisations don’t work this way and will need to change their approach to people in allowing them the space to challenge existing ideas.

Advertisements