We’re all short of time. Despite all the gadgets that are supposed to save us time there never seems to be enough of it to do what we want to do.

Here’s a simple thought – why not say no to some things?

How many times in the last year/month/day have you heard yourself agreeing to do something that you know deep down that you will never have time to do? And what’s the result? This task will sit on your to-do list and in your guilt box and distract you from, well, everything. When you sit down to do another task this one will pop into your head and nag you. It won’t be forgotten. And you’ll do your original task in a hurry or feeling distracted and probably won’t do it justice.

The end result of all this is that you do most of the things you said you’d do, perhaps not to the best quality, and you’ll leave some things undone, and feel guitly about them.

So the answer is to say no. You can be polite about it, but still say no. “I’m sorry, I’d really love to do ..xxx.., but I really can’t fit it in right now.” The person asking would far rather you came clean at once, so she can find another way of getting her task done, rather than have you either not deliver at all, or perhaps worse, deliver a half-hearted attempt right on the deadline. You might still feel guilty about refusing a request but that’s more easily dealt with. And now you have time to give your full attention to your other tasks.

“Better no job at all than a half-hearted attempt”

One of the little wrinkles in project planning is the difference between the duration of a task, and the effort required.

Stuart’s mean beef stew is a great illustration.

To make it you take a small pile of stewing steak, chop it up and shove it in a casserole with some beer. Leave it to cook for a few hours, then chop some onions, add tomato puree and bits and bobs, stir it into the mixture, and Bob’s your auntie. It’s stunningly tasty, and dead easy to make, and it doesn’t matter much if you vary the ingredients a bit.

The duration of the task is about 4 hours, because you can use cheap cuts of beef which take ages to cook. The effort is about 30 minutes, because for most of the time you are in the garden with a beer waiting for the beef to cook.

When you’re thinking about your project and worrying about effort & duration, just remember the beef stew, and all will be well.

And if you want to try it, you can find the whole recipe right here – Stuart’s mean beef stew.

Enjoy!

Why do projects fail? And how on earth can you make sure that your project doesn’t fail? Simple answer – you can’t. But you can improve your chances of success dramatically, by considering some of the reasons that projects go wrong, and avoiding them – easy! I know this sounds like a bit of back-to-front thinking, but trust me, it does make sense.

Projects fail for many reasons, and the weird thing is that no matter how big or complex they are, the most ‘popular’ reasons tend to be the same; and the top five are…..

• Project team unsure of project objectives;
• Project team unsure of project deliverables;
• At the end of the project, the objectives were only partially met;
• The planned schedule tended to run late;
• The budget was exceeded. 

Project Objectives

It seems so obvious when you think about it, but the most important thing you, as project manager, have to do is to make sure that everyone – everyone – involved in the project has a clear understanding of what the objectives are. You must include the customer and/or end user in this list. If you don’t what you’re doing, and the customer doesn’t know what he’s getting, you’re going to fail – period.

Define the project objectives in simple clear language. Use SMART objectives – Specific, Measurable, Achievable, Realistic, & Time-related. This technique makes it very difficult to remain uncertain of what the project is all about. Equally, a set of SMART objectives makes it clear what the project is not about – it defines the boundaries. Write the objectives down and get everyone to sign up to them, in blood – preferably their own.

Deliverables

Having got that, how will you know you’ve achieved the objectives? Answer, by understanding what the project will deliver in specific terms. Make sure that everyone knows what your team will be delivering, how and when. Deliverables don’t just mean hardware –books, furniture etc. A completed specification is a deliverable; so is a completed grant application. Be specific about what the project expects. The more specific you are, the surer you can be that you have succeeded.

On the other hand, a vague list of deliverables generates the possibility for endless doubt – “What does xxxx really mean?”, and doubt means delay and that means failure.

Objectives partially met

There can be many reasons why project objectives are only partially met. Perhaps the objectives were woolly in the first place – in which case you only have yourself to blame! (Sorry for being harsh, but it’s true) If the objectives were good, maybe they were unreasonable – remember the ‘A’ in SMART, in which case you still only have yourself to blame for accepting them. Things can change over the life of a project, and part of your job is to cope with change and still bring the project in on time and budget. However, there are some things that change too much, and render the project impossible. If this happens to you, you need to renegotiate the whole deal – redefine the project based on the new circumstances. It may be possible to salvage a part of it, it may be possible to extend it in time or budget or both. You need to be looking for a way to turn potential failure into success – maybe this project can spawn another to come along later, and you can then claim success for both?

Project runs late/budget exceeded

Any project is a balancing act between time, cost and quality. These two problems are clearly related, and there are a million reasons why they come up so frequently. If I had to choose, I’d say the two most common are optimistic estimating and indifferent teamwork.

How often have you embarked on a DIY project that is a “5 minute job” only to be still working at it when everyone else has gone to bed? When you set out, you didn’t intend this to happen, but you didn’t give the job sufficient thought, didn’t consider all the things that might go wrong, in short, didn’t think it through. Your project is filled with well-meaning people like you who don’t always think things through, and who don’t like giving you unpalatable information. As project manager, you need to be absolutely sure that estimates you’re given reflect real life, not the fantasy world that most of us inhabit. In your project, a task that overruns will cost you in salaries, heat, light, etc etc, not to mention embarrassment when the launch date is missed.

There is no miracle cure for keeping projects on track. The best technique I know is keeping on top of things. You need to know what is going on in your project, not what you’re told is going on.

Consider these two project managers. Fred sat in his office most of the time, working on his computer. He used Microsoft Project, and his plan was absolutely up to date, all the time. All the resources were there, all the costs, every last detail. He had the team report progress to him weekly by email. His project review meetings were a dazzling display of whizzy technology.

Bert spent 80% of his time out of the office, talking to the team, understanding the problems, celebrating the successes. He knew how far they had progressed from first hand experience. He knew which of the team’s estimates were good, and which not. He knew what was going to happen before it did, and he took steps to modify his plan. He made sure all the team were involved. He maintained his plan on Project, too, but his project reviews were not so flashy as Fred’s.

Who do you think was more successful? Bert’s projects didn’t hit absolutely all the dates, but he was always a lot closer than Fred. And Bert’s team would have jumped through hoops to achieve a milestone – his team really was a team. All Fred had was a group of people who worked in the same place.

Project management is not just about planning and scheduling. A lot of it is about teamwork and managing people. Often the people on your team will not work for you. You’ll have to work extra hard to meld them into your project team. But it is worth every minute you spend on it.

Conclusion

Sorry – there are no magic answers. You can’t just turn a handle and deliver a successful project, but now you are aware of the top five pitfalls in this risky business, you are in with a better chance. Project management is a risky business, and that’s part of the fun – go on, enjoy!