My team at work has leapt into action because there is an audit coming up next month. Sneakily, I’ve told them the deadline is an earlier than it actually is – which I know is bad of me, and I need to trust them more, but I’ve been burnt too many times. I need to slowly bring them round to be trustworthy.
Now, I’ve known for a while that the secret to running projects is to have a very clear brief. In fact, I’d say that’s the key part of running a successful project. But it’s become very clear to me in this situation. If you want to run a project well:
- You need a definite deadline that everyone is working towards and feels that they cannot miss. There need to be consequences to missing it too.
- The deadline needs to be short enough that there’s a continual need to be working towards it. If the deadline is too far away, people lose their sense of urgency.
- Everyone needs to be very clear of what they need to do to get to that deadline. If people don’t know what they’re doing, they get aimless.
- The aims need to be specific and measurable.People need to know if they’re hitting the target or not, and need to know how far away they are from the target.
If your project is bigger than this, and almost every project is, you need to break it down into smaller projects with smaller deadlines. Otherwise nothing will happen.
There’s a couple of projects I’ve been working on that I thought were going to be really easy and were actually incredibly difficult. I’ve realised, there are so often so many unforseen circumstances.
I’ve realised that even though I’d read Jeff’s article on estimating before, I’m still rubbish at estimating how long things will take:
When you compare the original single-point estimates to the Best Case and Worst Case estimates, you see that the 11.25 total of the single-point estimates is much closer to the Best Case estimate of 10.5 days than to the Worst Case total of 18.25 days.
You’ll also notice that both the Best Case and Worst Case estimates are higher than the original single-point estimate. Thinking through the worst case result can sometimes expose additional work that must be done even in the best case, which can raise the nominal estimate. In thinking through the worst case, I like to ask developers how long the task would take if everything went wrong. People’s worst case estimates are often optimistic worst cases rather than true worst cases.
I need to start doing this in my projects, and, also, asking other people to do this as well.
I had to get angry with our outsourced IT partner this week as they came to a meeting having not done the one thing I asked them to do. I think I got the balance right – calm but very displeased. So we’ll see if they do it again.
Afterwards, they were so eager to please me that they said they’d get the next bit of work done within a week. I probably should have pushed more for best case/worst case estimates.