The Courage to Try Something Old: Time Management – Part A
In the previous articles I wrote about the importance of the old skills of facilitating meetings and scribing and why it takes courage to use both. In this article I’ll give an overview another skill that has fallen out of favor over the years—time management.
We’ve been trying to manage time since the beginning of time and it’s not easy and it takes courage as you’ll see. [i] Whether our title is BA, PM, or vice president of sales, we have to manage our time. We need to manage our daily schedules and the projects or portion of projects that we are working on.
Here are some tips and tricks I’ve learned over the years that work when managing our daily schedules and our project work:
Not everything can be top priority. We can’t manage to an unspecific time period, such as tasks that are marked ASAP or “get this done before anything else you’re working on.” We can only manage to specific end dates.
End dates. When we have a small block of time available to us, it makes sense to complete a small task. But generally speaking we don’t want to complete small tasks before large tasks just because they’re easy. If we have a small task due in two week and a large task due in two days, we need to figure out how to get the large task done.
Less is more. In time management, smaller is better. We get large work done by developing the detail for what we know. We can estimate small user stories more accurately than epics for example.
Communication. When I started working on projects, I was under the false impression that I would always get every task done on time. And that I had to make a final commitment to a date before I had much detail, which made me and everyone around me miserable. Of course, we’re going to hit some targets and miss others. The key is to communicate as soon as we know we’re going to be late and set a new target at that time.
Resource availability. The key to every successful project is knowing how available each resource is. That is, we need to figure out how much time on average each resource spends on their non-project activities, including admin time, vacations, holidays, critical issues that arise and so forth. We also need to know how many projects people are working on. We have to mesh together those non project and project hours to get a realistic amount of time.[ii]
Advertisement
[widget id=”custom_html-68″]
Here are some common time management pitfalls:
Being overly optimistic. Most of us think we and everyone else we work with have more time than we do. What I’ve learned over the years is that not only do tasks take longer, but we tend to estimate based on false assumptions. For example, we ask a stakeholder how much time they can devote to the project at hand They say 50%. So, we think, well that’s about 20 hours a week or four hours a day. However, I’ve learned the hard way that many stakeholders are lucky to have 4 hours a week to devote to all their projects—on average.
Estimating vs. reporting. A common pitfall is to start with the end date and then estimate how long it will take to get there. But we’ll be more successful if we first determine the deliverables then the tasks to complete the deliverables. Then we can we estimate how long each task will take. From there we can determine milestones and report end dates for each major milestone. In other words, estimate details but report at a summary level.[iii]
Estimating but not tracking. The best way to improve estimating both our project and day to day work is to track our time.
Managing our time is going to take courage because some people are going to view planning to the detailed level as intrusive. That’s particularly true when we ask them to track their time. We often get accused of micromanagement, a term thrown around to intimate us. They will say that But one of the easiest ways to lose credibility is to estimate poorly and keep revising our estimates. So it will take courage to counter their distrust.
What’s worked for me, over and over are three things:
Use detail to establish credibility. The first is to use the detailed estimates to keep people off our backs. If people say, how could it possibly take so long to get through business analysis for example, we can show them the detail and ask them what they would like to cut out and they never ask again.
Use detail to get more resources. These can be more team members, more stakeholders, and more technical staff, as well as more time and budget.
Use detail to improve estimates. Never ever under any circumstances use estimates to judge the performance of anyone in any way. If someone estimated a task would take 20 hours and it took 40 hours, we use it as a learning experience.