Website Project Management - Part 3

In previous parts of this series we looked at what a project is and preparing for a project. For this final part we will discuss actually managing a project and how people often get into trouble by overlooking some very simple things.

The Project Plan

Before you can effectively manage a project you need a plan. Depending on your situation and experience this might be in your head, a list on a napkin or cigarette packet, an automated to-do list or a gantt chart. The key thing at this point is you need to know what your project involves.

Why do I need a plan?

I promise this is the last platitude ;O)

As seen in the comments in previous parts of this series some people like the thrill of just getting on with a piece of work and not bothering to plan. That's fine for some, especially if you are only accountable to yourself. Some examples of when I think you need a detailed plan

• Where you are accountable to someone else
• when there will be a team that needs to communicate and divide tasks
• when it is not entirely clear how the tasks will acheived
• When you need to know a budget or timeframe
• When you have to manage risk

A good plan helps structure the team, approach and implementation, while communicating goals, progress and responsibilities.

With this in mind I think it is fair to say a back of a cigarette packet doodle is not going to cut it. Far to much of the knowledge is stuck in the project managers head leaving everyone else dependant on that person being involved before they can progress one iota.

We need more detail. At the very least we need to know what needs doing. In the previous post we discussed milestones. Let's take a proper look at tasks and break down a project.

Work breakdown

Anyone familiar with project management will have come across work breakdown or task breakdown structures. The idea is to take the project and break it into manageable chunks. "Chunking" is a good approach for making any large undetaking less scary in fact. Think of any large frightening goals such as passing a driving test. It's a lot less intimidating to think of it one lesson at a time, one skill at a time, than to think of the whole learning to drive experience. There are similar benefits when breaking down a project in this way as we will discuss in a bit.

Before I show you how I approach a project plan let me just explain why I think a to-do list is not the right way of doing it. Let's look at a simple project. I know, seeing as this is Threadwatch, let's make a good cup of tea

Making a Good Cup Of Tea Project v1

• boil a kettle of water
• open the packet of tea
• pour a little of the water into a tea pot
• swirl the pot around and tip it out
• Put a couple of tea bags into the pot
• Bring the kettle back up to the boil
• pour the boiling water as quickly as you can into the pot
• Let it stand for two or three minutes
• pour it into a cup

Deadlines, Time Estimates and Duration

So we have a list of tasks. When will our tea be ready? How long will our project take?

Erm...

OK, we need time estimates and even though we are going to start as soon as we have done writing the plan for completeness we need a start date/time. Start dates are not always this straightforward, sometimes there are dependencies that mean a start date needs to be figured out (see below).

Task estimation should not be done by the project manager alone. You have specialists for a reason, get them involved at least. The best approach is for the person who will do the task to estimate it (sometimes with another person to check and agree .. a BS detector in some cases). It is no good shouting at someone for not acheiving a timeframe where they had no input. Arbitary deadlines pulled out of the air are just dumb and cause nothing but grief. Particularly if chosen by "hardman" project managers who LIKE deadlines (believe me these people exist).

Estimation gets easier the more you do it, especially if you check actual times against estimated times. You will also find it easier if you break down the tasks and further break them down until you get more and more sure of your timings. In the example above we say "boil a kettle of water". This is a macro task that is a combination of finding the kettle, unplugging it, taking it over to the tap, filling it with water, etc. You should break down a task into smaller tasks to the point where the task is estimatable, manageable, and preferably doable by one person. In projects spanning months or for cost estimates I try not to estimate in smaller blocks than a couple of hours. Some of this stuff is more time management than project management but use your own judgement.

Multi-tasking

One of the main traps people fall into when producing a project plan is think sequentially rather than looking for the logical order in which things should happen; most projects are not easily fit into a step by step process, many tasks are performed more efficiently or may even need to happen in parallel. You can open the packet of tea while the water is boiling. There would probably be time to get the milk, wash a cup out, etc. By doing things in parallel you compress the project timeframe considerably. Sometimes it makes sense to add additional bodies so more parallel work can be done. The judgement of if you should have an extra person do a task so things can be done in parallel would be down to the constraints of time and budget ordinarily.

Resources, Risks and Dependencies

Sometimes it helps to have tasks that are there simply as checks. For example Douglas Adams says about tea "water has to be boiling (not boiled) when it hits the tea leaves". You could have a task of "check water temperature". Before you can pour the water this needs to be ticked as complete. This makes "pouring water" dependant on "water temperature". Dependancies are one of the vital things missing from a to-do list. Let's take another look at the task list to see if there are any other dependancies.

We didn't check if we actually had any tea ... Go to Marks and Spencer and buy a packet of Earl Grey tea. Go back to and start over. If you like milk in your tea according to Douglas Adams it is best to put some milk into the bottom of the cup before you pour in the tea. If you pour milk into a cup of hot tea you will scald the milk. If you think you will prefer it with a slice of lemon then add a slice of lemon. 'Course this means you need milk and/or lemons for a start.

You often need to get things from other people, for example is content coming from someone else? Will you need to wait for hosting to be set up and domains to transfer? Put these in as dependencies.

The main resources required on our project is the tea maker (a human resource), tea and water. We also identified possible requirements for milk and lemon. There is a risk of not being able to complete based on a lack of these resources. We can mitigate the risk though by adding a stock check and optionally a shopping list as a first item. These checks would be "predecessors" to the tasks that depend on them. Phew, back on track!

Talking of shopping lists..

Task Shopping List

Now we know a bit of what we were missing we can build a list of what you need to know for each task.

• Task Number for tracking
• Description
• Start and End Dates
• Duration
• Implementer
• Resources required
• Task Predecessor

Once you have all this information you can work out your "Critical Path". This is the "spine" of a project, the tasks that have to happen and in a certain way that determine the length of the project. While delays to other tasks might not have any effect on the project overall, changes to critical path usually will.

Binary Tasks

A task should not be passed and signed off until one hundred percent complete. A task is either done or not done. Allowing partially complete items increases the chance of a build up of forgotten to-do items, patchy incomplete work, bugs and slack project tracking.

What about those Gantt Charts then?

One of my preferred ways of working out projects is using sticky notes and a whiteboard. You don't actually need Microsoft Project or even to draw a gantt chart. I do find though when your team is spread geographically, even in seperate departments, or when there is a client involved, it does help to have a chart and modern Gantt Charts display all the required information in an accessible format.

Summary

Had you given the above tasks out to different people before there would have been no way a team could have worked together without a LOT of communication, communication that could more easily and accurately have happened using a good plan. You want people to be able to get on with their job rather than waste time and money double-checking or duplicating conversations.

Talking is good, needless chatter is not. And what often happens is actually MIS-communication. Having a plan, keeping the plan up to date and sticking to it is far easier.

You don't NEED fancy software (although I find it helps), you just need to know cerain things and to be able to track and communicate them. I hope these posts will help you do it a little easier :O)