Tag Archives: time management

Sweating the small stuff

In a previous role, in preparation for a major datacenter migration project, I figured that there were a ton of really small mini- or micro-projects that we needed to get sorted before we’d be in a position to undertake the big stuff: migration of filestore from Netware to Windows, internal app upgrades, non-disruptive re-platforming, the kind of things that were often talked about in the office for half an hour and then lost to the ether, or, jobs that were important to a particular team member, that would have been started but lose momentum when the bigger stuff takes over.

Realising that these small-scale projects are a genuine way for the team to deliver incremental improvements, rewarding in their own right, I figured that why they usually stopped or lost was because they were no actual targets, that the individual knew what was required and didn’t need to write any of it down.

Also, knowing that techies are lousy are keeping track of their ideas, I asked the powers that be for some low-key project management assistance, not a formal project, but keeping tabs on the wee items that need to be done, most of which wouldn’t appear on the radar of a proper project.

Because the PM wasn’t really interested in tracking it ‘properly’ (because it was a proper project, had no budgetary implications, no vendor managements, or contracts to negotiate) he put as little time and effort into as possible, just checking up on the progress the devs and infrastructure were making on their areas. And it was just two or three people, agreeing on a set of tasks to be done whenever they got done.

But after a while, I noticed that all he was doing was getting agreement on: what needed to be done, who was going to do it and when it should be done by; he was an independent (and uninterested arbiter).

All the tasks were simple and achievable, but having an agreed list where each part needed to be ticked off at regular brief meetings was key. I already appreciated the need for actively tracking tasks (I tried using a now-defunct tool called todoyu) but trying to get the team to manage their own work like this just doesn’t work; that external guide was the key.

And it delivered. Not everything, of course, but enough to make a difference; the stuff that didn’t get done that way turned out to be much more complex and needed to be a project in its own right, but this becomes obvious.

To me, there are two real benefits of an approach like this,

  • stuff gets done,
  • there is a record of stuff getting done

When a team is working toward a strategic objective there are many small items that get in the way or get forgotten about in the flood of important matters, but in the end it all counts.

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.