ConceptDraw Project
Planning Project Structure

Buy :: Try

Having decide what the specification intends, your next problem is to decide what you and your team actually need to do, and how to do it. As a manager, you have to provide some form of framework both to plan and to communicate what needs doing. Without a structure, the work is a series of unrelated tasks which provides little sense of achievement and no feeling of advancement. If the team has no grasp of how individual tasks fit together towards an understood goal, then the work will seem pointless and they will feel only frustration.

Planning Project Tip

The simplest way to create such a structure is using a Gantt chart provided in project management software.

To take the planning forward, therefore, you need to turn the specification into a complete set of tasks with a linking structure. Fortunately, these two requirements are met at the same time since the derivation of such a structure is the simplest method of arriving at a list of tasks.

Work Breakdown Structure

Once you have a clear understanding of the project, and have eliminated the vagaries of the numbties, you then describe it as a set of simpler separate activities.

Planning Project Note

Gantt chart allows you to create tasks with subtasks of any nesting degree.

If any of these are still too complex for you to easily organise, you break them down also into another level of simpler descriptions, and so on until you can manage everything. Thus your one complex project is organised as a set of simple tasks which together achieve the desired result.

The reasoning behind this is that the human brain (even yours) can only take in and process so much information at one time. To get a real grasp of the project, you have to think about it in pieces rather than trying to process the complexity of its entire details all at once. Thus each level of the project can be understood as the amalgamation of a few simply described smaller units.

In planning any project, you follow the same simple steps: if an item is too complicated to manage, it becomes a list of simpler items. People call this producing a work breakdown structure to make it sound more formal and impressive. Without following this formal approach you are unlikely to remember all the niggling little details; with this procedure, the details are simply displayed on the final lists.

One common fault is to produce too much detail at the initial planning stage. You should be stop when you have a sufficient description of the activity to provide a clear instruction for the person who will actually do the work, and to have a reasonable estimate for the total time/effort involved. You need the former to allocate (or delegate) the task; you need the latter to finish the planning.

Task Allocation

Planning Project Note

Again you can use some software to allocate all the tasks to people and arrange them in the needed order.

The next stage is a little complicated. You now have to allocate the tasks to different people in the team and, at the same time, order these tasks so that they are performed in a sensible sequence.

Task allocation is not simply a case of handing out the various tasks on your final lists to the people you have available; it is far more subtle (and powerful) than that. As a manager you have to look far beyond the single project; indeed any individual project can be seen as merely a single step in your team's development. The allocation of tasks should thus be seen as a means of increasing the skills and experience of your team - when the project is done, the team should have gained.

In simple terms, consider what each member of your team is capable of and allocate sufficient complexity of tasks to match that (and to slightly stretch). The tasks you allocate are not the ones on your finals lists, they are adapted to better suit the needs of your team's development; tasks are moulded to fit people, which is far more effective than the other way around. For example, if Arthur is to learn something new, the task may be simplified with responsibility given to another to guide and check the work; if Brenda is to develop, sufficient tasks are combined so that her responsibility increases beyond what she has held before; if Colin lacks confidence, the tasks are broken into smaller units which can be completed (and commended) frequently.

Sometimes tasks can be grouped and allocated together. For instance, some tasks which are seemingly independent may benefit from being done together since they use common ideas, information, talents. One person doing them both removes the start-up time for one of them; two people (one on each) will be able to help each other.

The ordering of the tasks is really quite simple, although you may find that sketching a sequence diagram helps you to think it through (and to communicate the result). Pert charts are the accepted outcome, but sketches or Gantt charts will suffice. Getting the details exactly right, however, can be a long and painful process, and often it can be futile. The degree to which you can predict the future is limited, so too should be the detail of your planning. You must have the broad outlines by which to monitor progress, and sufficient detail to assign each task when it needs to be started, but beyond that - stop and do something useful instead.

Guesstimation

At the initial planning stage the main objective is to get a realistic estimate of the time involved in the project. You must establish this not only to assist higher management with their planning, but also to protect your team from being expected to do the impossible. The most important technique for achieving this is known as: guesstimation.

Guesstimating schedules is notoriously difficult but it is helped by two approaches:

• make your guesstimates of the simple tasks at the bottom of the work break down structure and look for the longest path through the sequence diagram
• use the experience from previous projects to improve your guesstimating skills

The corollary to this is that you should keep records in an easily accessible form of all projects as you do them. Part of your final project review should be to update your personal database of how long various activities take. Managing this planning phase is vital to your success as a manager.

Some people find guesstimating a difficult concept in that if you have no experience of an activity, how can you make a worthwhile estimate? Let us consider such a problem: how long would it take you to walk all the way to the top of the Eiffel Tower or the Statue of Liberty? Presuming you have never actually tried this (most people take the elevator part of the way), you really have very little to go on. Indeed if you have actually seen one (and only one) of these buildings, think about the other. Your job depends upon this, so think carefully. One idea is to start with the number of steps - guess that if you can. Notice, you do not have to be right, merely reasonable. Next, consider the sort of pace you could maintain while climbing a flight of steps for a long time. Now imagine yourself at the base of a flight of steps you do know, and estimate a) how many steps there are, and b) how long it takes you to climb them (at that steady pace). To complete, apply a little mathematics.

Now examine how confident you are with this estimate. If you won a free flight to Paris or New York and tried it, you would probably (need your head examined) be mildly surprised if you climbed to the top in less than half the estimated time and if it took you more than double you would be mildly annoyed. If it took you less than a tenth the time, or ten times as long, you would extremely surprised/annoyed. In fact, you do not currently believe that that would happen (no really, do you?). The point is that from very little experience of the given problem, you can actually come up with a working estimate - and one which is far better than no estimate at all when it comes to deriving a schedule. Guesstimating does take a little practice, but it is a very useful skill to develop.

There are two practical problems in guesstimation. First, you are simply too optimistic. It is human nature at the beginning of a new project to ignore the difficulties and assume best-case scenario - in producing your estimates (and using those of others) you must inject a little realism. In practice, you should also build-in a little slack to allow yourself some tolerance against mistakes. This is known as defensive scheduling. Also, if you eventually deliver ahead of the agreed schedule, you will be loved.

Second, you will be under pressure from senior management to deliver quickly, especially if the project is being sold competitively. Resist the temptation to rely upon speed as the only selling point. You might, for instance, suggest the criteria of: fewer errors, history of adherence to initial schedules, previous customer satisfaction, "this is how long it takes, so how can you trust the other quotes".