Planning,
estimating and resourcing may be viewed as separate
issues, but they need to be conducted in parallel as they
directly affect each other.
Planning a project is where the Project Manager must bring together the complete understanding of the project's requirements with a deep understanding of all the elements that are required to conduct a successful project. In many ways, it is the centrepiece for the Project Manager's skills. Of course, it all counts for nothing unless it leads to a successful project!
Planning,
estimating and resourcing may be viewed as separate
issues, but they need to be conducted in parallel as they
directly affect each other.
The availability of resources will always be limited. Resources may be required in greater quantities than are available or have competing demands on their time. It may be necessary to make compromises or move work between different potential resources to make best use of the resources available. As these practical adjustments are made, there will inevitably be an impact on the duration and timing of tasks. It may also affect the project's predicted costs.
Here are some of the key issues in deciding what approach to take:
The classic approach to planning is top-down. We divide all the things required into a few high-level items then, explode them into greater levels of detail as the planning process proceeds. Very often this explosion stops at a relatively high/summary level of detail for the initial planning and is only expanded into full detail shortly before each new phase of work.
Top-down is the most logical way of thinking about a project and is usually the best approach to new endeavours. It provides an early high-level plan, including initial costs and timings, which can be used in the project's definition and benefit case.
Bottom-up planning makes sense where we already have a good example of a successful similar project plan to base the new project on. A majority of projects will be similar to something that has been done before and it makes sense to use that as a starting point (assuming it was of good quality). As well as saving time in the planning process, this allows us to learn lessons from the previous experiences. In particular, estimates can often be extrapolated from the previous projects.
In bottom-up planning we start with the full detail of a previous plan and adjust the precise details, estimates and dependencies to be correct for the new project. From the beginning, we have a fully detailed plan. This usually means that where top-down plans need to be exploded, bottom-up plans need to be summarised so that they can also be used at a summary level for things like the project definition, benefit case, and reporting.
Where you have started from a detailed plan and worked bottom-up, you already have the full detail - but remember to review that detail as you progress through the project as things will inevitably change. You may choose to review the detail in stages in a similar manner to the way you would deal with a top-down plan.
If you started with a top-down plan, the question is - when should you explode it into full detail? If it is a relatively simple project, with short timescales and a manageable number of resources, you may easily be able to generate a sufficiently detailed plan at the beginning of the project and stick with it (bearing in mind that the Project Manager has a continuous duty to make sure the plan is realistic).
In larger projects, best practice is to explode the detail in stages. Here are some of the reasons why:
Clearly, you need that detail far enough in advance to make decisions about the allocation of individual people to tasks and to mobilise the resources required. You should also plan out the detail for logically complete elements of the project together so that all related issues are examined together.
Very often this means that detailed plans are best prepared per phase during the project. The first phase of work would be planned immediately following the project definition. Further planning for following phases would be done towards the end of each phase to give a reliable base for the starting dates and any variations in the originally planned activities. It must, however, be done early enough that the required resources can be identified and mobilised in time for work to commence.
Here lies maybe the biggest area of disagreement between those involved in project management. Arguments range from the senior executive's view of a plan - must fit on one page of a flipchart - to those managers who wish to consider the full detail of every task conducted by every person. To put that into numbers, should the plan have ten lines or ten thousand?
Do not confuse the level of detail you need for project definition and status reporting with the level you need to use to assign individual people to individual tasks and track their progress. The full detail is rarely appropriate for anyone except the Project Manager and the Project Office team. The project sponsors and other concerned parties will only want to see key summary information such as milestones and overall costs. Project Team members only need to see the full detail where it is related to their own activities.
Given that the full detail is largely for the Project Manager's benefit - how do you make that choice? Here are some of the factors to consider:
| Factor | Small plan | Large plan |
| Constructing the plan | Low effort / short time | High effort / long time |
| Identifying dependencies | Will be at a high level hence may be inefficiencies and missing links | Can be fine tuned for perfect automatic scheduling |
| Identifying resources | Probably need to assign groups of people to deliver high-level tasks collectively | Can accurately assign individual people to individual tasks |
| Telling people what to do | Probably insufficient detail - you will be relying on "word of mouth" | Should all be in the plan |
| Tracking progress | Low effort but possibility of issues being hidden | High effort - but accurate |
| Reporting progress | May be usable without summarisation | Will need to be summarised for reporting purposes |
It is hard to judge the optimum approach. Very often it will be dictated by norms within your organisation, or maybe by previous plans that you are using as a starting point. Strangely, perceptions do not vary significantly with the size and complexity of the project. In general, people seem to be:
Unfortunately, that generalisation is not fully reliable. The key advice is to get your strategy agreed with the project sponsors and others concerned!
A good way to deal with complexity and with unwieldy large plans is to use a number of sub-plans. There will be one overall plan showing the whole project, but for its detail it will link to various sub-plans. The sub-plans would deal with various subsets of the overall project, for example, there might be one per workstream or one per sub-team. Ideally, each sub-plan will have its own Team Leader. That Team Leader will have responsibility for delivering against the sub-plan and would often be given the job of developing the detail during the planning stages.
The Project Manager will need to consolidate the plans for the overall estimating and scheduling of the project. Particular attention should be given to issues between the sub-plans, for example:
The ease with which the project can be handled as a number of sub-plans often depends on the choice of automated project planning tools. The best (ie most expensive) tools will have no trouble consolidating and scheduling multiple plans. Some of the more basic software tools have limitations that might lead the Project Manager to prefer to represent the sub-plans as separate sections within a single physical plan.
Almost all project planning tools provide automated scheduling - so why would you not want to use it? There are two main issues that you need to consider:
Given the limitations and idiosyncrasies of the various tools coupled with the logical complexity of Critical Path Analysis and resource optimisation, the Project Manager will normally have to put considerable effort into teasing the plan until the automated scheduling gives good results. It would be wonderful if the tool could do "what-if" analysis and try all the tricks in the trade to suggest a good resolution like "did you think of getting an extra programmer - that would halve the length of the project", or maybe "the optimum number of programmers is 3.6 FTE".
The sort of information the Project Manager may need to adjust is:
Try to avoid manipulating the plan by locking in specific dates - unless they genuinely are fixed dates. You will almost always have problems when re-scheduling the plan if some of the dates are considered immovable.
Simple tests of good scheduling are:
Automated scheduling can be seen as an investment. It can take a huge effort to get the plan fine-tuned to the extent that you can rely on it, but, once it is done, the plan can be re-scheduled as often as desired with very little effort. As well as adjusting the plan during the project, this allows you to perform "what-if" analysis during the planning stages (eg "what is the quickest we could do this with unlimited resources?", "how much quicker would it be with one additional programmer?", "how many programmers do I need to meet the required completion date?").
The problem with automated scheduling is the time and effort that needs to be invested to get a good model. Not surprisingly, many Project Managers feel they cannot afford that time. Others try it and find things are not working out - so they give up and lock in manual dates instead.
Manual scheduling is probably the more common approach in reality. It can be justified on the basis that progress is more important than accuracy and optimum performance. If you intend to schedule the plan manually, remember these things:
We discuss scheduling the detailed plan below.
Here is an esoteric debate for Project Managers to discuss over beers in the evening. The question is - how do we define the 'things' in the plan - what are they? Let's take a look at several philosophies: activity, process, deliverable, outcome, and milestone.
The classic and common understanding is that a plan tells you what things to do. It describes the various activities that are required. These would typically be broken down and structured into categories for ease of understanding. This is a basic concept in Project Management - the Work Breakdown Structure (WBS).
Here is a very typical example structure of an activity-focused plan:
Note that because we are talking about activities and tasks we are using verbs - action expressions. In fact the typical construction is in the form verb + noun ie "do the thing".
A variation of this is to use a process focus for the structure of the plan, but, probably, leave the low-level tasks and deliverables at the same level. Process focus is following the evolution in thinking that occurred in analysing business processes - except here applied to the processes of a project. The intention is to tell the story of each process within the project rather than present it in a disjointed way divided up into phases. For example, one section of the plan would describe the story of testing. It would start with the early definition of the project's approach to testing, through the detailed planning, testing preparation, conducting tests and gaining business acceptance. As well as telling the story in a way that is easier to understand, the process focus generally fits in with the idea that projects can be organised into various workstreams, each dealing with a layer of the overall business solution.
Here is a very typical example structure of a process-focused plan:
The problem with a process focus is that it may offend those Project Managers and Project Sponsors who expect the plan to be organised in distinct stages. For example, the testing process will start early in the project when the overall approach to testing is agreed; test planning and preparation will occur in the middle; test execution and sign-off occur towards the end. To place all these together might tell a good story - but it challenges the common belief that project plans should be organised to show logical and/or time progression. Within each process, such staging may be apparent, but in a single view it is hard to present both the staging across processes and the story of each process.
You will probably hear some "rules of thumb" about how tasks should be defined, for example, tasks should not be so long that progress cannot be tracked regularly or so short that they are trivial - some people would suggest five days is a good length. The problem here is that some very important things such as a "sign off" might be very short in duration but vital to the good conduct of the project and others like "track progress" might be very long tasks with no merit in sub-dividing them or measuring interim progress.
One common recommendation about defining tasks is that all tasks should have a measurable output that clearly evidences the task is successfully completed and which represents the main purpose of the task. For example, "Define Scope" might produce a deliverable called "Scope Definition".
This leads some Project Managers to suggest that the entire approach might be better if everyone focused not on doing tasks but on delivering the results - hence the project plan could be expressed as deliverables and sub-deliverables.
For example, in a deliverable-focused plan the previous examples might look like this:
Because the plan is now expressed in terms of its deliverables, the expressions have now become nouns - they are the names of the main deliverables being produced.
We can see in this example a strange possible consequence - the focus is now on producing something called a "sign off" document. One thing a deliverable focus can do for you is to generate a large number of small, new, highly-important documents which serve as visible deliverables for something that is harder to see, for example, agreement.
Alternatively, some Project Mangers would happily have referred to that final output as the "Agreed Benefit Case". This too can work, but it poses the problem that something which is logically the same thing can have a different name because its status has changed. As well as the philosophical and semantic debates, this can lead to practical difficulties when tracking deliverable flow and particularly when using an automated document management system.
Maybe the biggest problem with deliverables focus is more one of usage than intent. Project Managers tend to look for some form of visible document that shows they have completed the deliverable. For example, which of these outcomes do you think a Project Manager is more likely to describe as a deliverable:
Unfortunately, deliverable focus in practice often emphasizes the reports and documents that are to be created and diverts attention from the true desired outcome of the work. The project might appear successful because training materials were produced ignoring whether or not that training had the desired effect on the workforce.
So, to take the argument to its conclusion, the thing most worthy of the Project Manager's attention is not the work done, nor the reports produced, but achieving the desired outcome in the most beneficial manner. There is no doubt that this is a good ambition for the Project Manager. The question is - should the plan be expressed in those terms so that everyone is focused on the outcomes?
Here is a final look at an example structure - this time outcome-focused:
Now the work is described as outcomes. These might be expressed as statements like "Benefits Case Understood and Agreed by All Parties" - except you could shorten that to "Benefit Case Agreed" for the sake of brevity on the plan.
In any of these approaches, or instead of these approaches, you may identify critical checkpoints indicating the completion of a significant achievement, deliverable, stage of work etc. These "milestones" are inserted into the plan as control points for management and reporting. They often represent important review points or interdependencies in the plan. In high-level planning, it may be appropriate to start from a network plan only showing milestones and their dependencies. Where this works well, it is usually because the milestones in fact represent deliverables or outcomes - so maybe a deliverable or outcome view would have worked better.
There are things to be said for and against all five of these styles. Here is a quick summary:
| For | Against | |
| Activity focused | It's what many people are familiar with - instructions that tell them what they have to do | Can seem like a lot of work is done without creating any tangible, measurable result |
| Process focused | Very good at explaining how things are done | Loses the staged view of the overall project |
| Deliverable focused | Focuses attention on delivering the deliverable | Might focus attention on trivial or artificial outputs instead of the major focus of the work |
| Outcome focused | Focuses attention on what really counts | Can seem esoteric and can be hard to measure that the outcome has been satisfactorily achieved. |
| Milestone focused | Presents a simple picture focusing on critical information. | In reality is focused on deliverables or outcomes as described above. Will not normally focus attention on the path or effort to attain each milestones. |
An ideal approach would be to hold all these differing views and criteria in a multi-dimensional model of the project whereby the Project Manager can view and present the plan in any of these manners. Unfortunately the workload to create and manage plans would be high if not prohibitive and the software tools do not exist to make it possible. A good plan will, nevertheless, be organised so that the major activities, workstreams, deliverables and outcomes are all apparent to the reader whichever main structure has been chosen.
The earliest planning overlaps with Project Definition. It is necessary to have some view about the project's approach, timescales, work effort and costs to be able to perform the initial Cost Benefit Analysis and justification.
Following that, the project would normally be planned at a summary or management level of detail. This management-level plan defines all major work for the duration of the project. By this stage, the structure of the work will need to be clear. Phases, major deliverables, activities, workstreams and significant milestones will be defined.
Projects can have any number of different shapes. By shape we mean the way the different elements are structured and how they relate to each other. An IT strategy project does not look like an eCommerce project, which, in turn, does not look like an ERP package implementation. It is more than just a question of what we are trying to achieve - it is also a question of how we will go about it. How do you explain the shape of a project?
Where you plan to use a predetermined methodology for the work, the shape will be defined by that methodology. For example:
Alternatively, you may find you are free to make these choices for yourself. Here are some of the issues:
The waterfall style is the classic approach to projects and is still very popular - particularly in the public sector. In a waterfall, each phase forms a major segment of the work which finishes and is approved before the next one starts. It is called a waterfall because it looks like a waterfall.
|
It is easy to see the problem with the waterfall - it tends to make poor use of time. Typically each phase comes to a halt, then there are some time-consuming review processes, then people start working again. Consider too the way that work naturally takes time to build up at the beginning and how the final few issues take time to resolve. Altogether, this leads to poor use of resources.
Project Managers often use a simple approach to detailed dependencies. They apply waterfall logic to detailed activities and tasks as well as to the major phases. The same inefficiencies will apply, albeit on a smaller scale.
To avoid the inefficiencies of waterfall logic, you can seek legitimate ways to overlap the phases. By legitimate, we mean it must not significantly increase risk (although the deliberate acceptance of risk to achieve faster or cheaper results can be a legitimate business decision if properly assessed and agreed).
The reason for those review points in the waterfall is that it is generally unsafe to proceed to the next stage of work, building upon the previous one, if we are uncertain that the starting point is valid.
Case Study |
| A third party software house was building
new systems for their client. Pressurised by obligations
to meet time and cost targets, the software house had
pressed on with the programming of the new system and
were nearly finished. At the same time, the design
documentation was still held up at the sign-off stage. It
had not yet been finalised and agreed. Our review of the project found the reason why. The design was not what the client organisation wanted. It was not a question of minor corrections - it was the wrong solution. All the development work had been wasted. |
There are ways you can plan to overlap phases, activities and tasks in a safer way to make best use of the projects resources. In general you need to have secured firm commitment to various issues before the "phase end" signoff process. For example, you might agree the hardware architecture during the conceptual design work - so you could acquire and install the equipment needed for development immediately to avoid delays. Here are a few other examples:
Many rapid approaches to applications development, for example "Agile", rely on an iterative approach. Parts of the project plan will repeat until the overall job is completed. This allows progress to be made in easy stages. There are two main forms of iteration:
Iterative approaches are particularly appropriate for eProjects due to:
Here is a high-level example of iteration at work:
The iteration may have multiple layers. In effect, the example above has two levels of iteration - repeating design/build/test prototyping loops building up to each releasable unit. In simple cases the prototyping could be seen as a continuous process. It is only where it needs to go through baseline stages that the planning becomes complex.
Project Managers find it difficult to plan for iterative or
replicated processes. Just how many loops are there going to be?
Do we assume a certain number of design loops and delivery
stages? Here is the Project Manager's nightmare scenario:
Replication within replication within replication within replication within replication...
Probably the easiest way to explain the shape of your project is using a graphical presentation. Let's start by looking at an example. Study this carefully and see if you can deduce all the messages it is trying to communicate before looking at the explanations.
Here's what we were trying to say:
Here are some of the graphical techniques we use:
| Meaning | Graphic |
| Small phase |  |
| Big phase |  |
| Overlapping phases |  |
| Interlocked phases |  |
| Increasing focus |  |
| Initial major focus which then diminishes |  |
| Phase which builds up then tails off |  |
| Iteration |  |
Before the start of each phase, the initial high-level planning needs to be expanded into fully detailed plans with the chosen depth of detail. Unless you chose the bottom-up "big bang" approach to planning and started with a fully detailed plan, there will be considerable effort involved. Even where the original plan was created at a detailed level, it should now be reviewed and revised to take account of the current starting position and any changed circumstances.
As we noted in general, planning is always linked to estimating and resourcing. All these details must be combined to calculate a detailed schedule of work. With good planning tools, a well thought-out Work Breakdown Structure (WBS), milestones, careful recording of dependencies, effort and resource allocation you should be able to calculate the detailed schedule automatically.
The two main formats for preparing a plan are the Gantt chart and CPM or PERT chart. Gantt charts are the most popular as they present an simple picture of the work and make it easy to see when things start, how long they are and how they are sequenced. They are particularly helpful in communicating the plan to people unfamiliar with Project Management. The Gantt chart represents each piece of work as a bar on a chart with a horizontal scale to show dates.
Some Project Managers believe that a PERT (Project Evaluation and Review Technique) chart or CPM (Critical Path Method) network is a more scientific way to think about a project. The PERT chart makes you think in detail about the logic and dependencies of a project. The logic and mathematics behind PERT and CPM are not subjects for the ePMbook. The good news for the practical Project Manager, as opposed to the academic, is that you can leave the detailed calculation to your planning tool. In these forms of analysis, the plan is normally depicted as a network of boxes for work items with their dependencies shown as links.
This depiction shows the logic behind the sequencing. It also helps us to calculate the "Critical Path" - ie which path through the work network takes the longest and therefore defines the elapsed time that will be taken. In both the examples, the Critical Path is shown in red.
Note that this particular style of diagram is not very good at telling us about the nature of the dependencies. As you saw in the Gantt chart, the various pieces of work deliberately overlap, eg we can start looking at benefits before the scope has been fully defined. In fact, it has "Start-Start" dependencies and "Finish-Finish" dependencies as well as the traditional "Finish-Start" links. In some styles of chart, this would be made more clear, for example, by showing the connecting line going to the end of the box if it means "Finish" or the start of the box if it means "Start".
Another problem with PERT/CPM charts at a detailed level is that they can look as complicated as the wiring diagram for a space shuttle. Imagine say 2000 boxes each with an average of 2 dependencies, some of which jump between major sections of the plan. Even if you have enough wall space, it is hard to imagine how you could comprehend it. In fact, the best way to use these networks is to view them in whatever logical sequence you wish through the planning tool. It should let you follow a train of logic such that you can comprehend how it works or what has gone wrong.
With modern planning tools, this debate between Gantt and PERT/CPM is much less of an issue since you can view the project plan in many different ways including traditional Gantt and PERT/CPM styles. Some tools can combine these views, along with many other bits of information, into a single view. See how the Start-Start and Finish-Finish dependencies are shown clearly in this standard view from Microsoft Project 98.
Most Project Managers and planning tools assume that the default dependency between two tasks is "Finish-Start" - ie you must finish (completely) the prior task before you are allowed to start the next one. Most plans are expressed in this way. Conversely, most people conducting the work ignore this and take a more pragmatic approach to make good use of their time.
Very often, the true nature of the dependency is more subtle:
| Dependency | Use | Examples |
| Finish-Start | Successor really cannot start until the predecessor is completed | Agreement is absolute requirement - eg
don't start until you have a contract Physically impossible - eg must have a working computer system to do the development work |
| Finish-Finish | You could reasonably make progress on the successor but you cannot finalise and agree it until the predecessor is safely completed | Start building a prototype based on the
proposed design - but you cannot finish building until
the design is fixed. Preparing a training course could be done in parallel with development and testing work - but it cannot be finished and validated until the final design is fixed and the training environment is ready. |
| Start-Start | You cannot start the successor without at least some output from the predecessor - but you don't need to wait for it to finish | You can document and review fact-finding
interviews as soon as you have started the first one As soon as the testing starts the control and incident management process should start |
| Start-Finish | The successor cannot finish until the predecessor has started | Unusual logic to use! |
Many real-life dependencies have both Start-Start and Finish-Finish components. Take the simple example of documentation. You can start documenting as soon as you start to define the thing it refers to, but you cannot finish it until that thing is fully and irrevocably defined.
When defining dependencies you may also wish to stipulate time delays. In some cases you can build in genuine estimated delays. In some cases, a Project Manager may use arbitrary lags to help with the scheduling and sequencing or to allow for contingency. You might also use a negative lag where you are saying you wish to schedule something in advance. Here are some examples:
Milestones are useful tools in planning and scheduling. They may have been used at a high-level to present the overall project plan. Alternatively, they may be used tactically to identify completion of significant achievements, identify cross-dependencies, then subsequently provide a control and reporting mechanism during the project.
Milestones do not normally have work attached to them. They simply record in the plan that a specific logical stage or accomplishment.
In this example, "User Readiness Confirmed" is not itself a piece of work or a deliverable - it is the state we have achieved when all the individual readiness checks have been satisfactorily completed.
We discussed earlier some of the considerations when deciding how to go about scheduling. Let's now look at some of the detail.
The basic things we need to identify are:
When it starts will be calculated primarily by its predecessor dependencies, plus the need to smooth out the usage of resources. Planning tools normally include complex logic to calculate the optimum schedule - but, as we discussed earlier, they it may take some manipulation to give optimum results. You can often tell whether a plan was scheduled automatically simply by its appearance. Automatic scheduling often appears crazy but gives optimum results. Manual scheduling looks far too neat and orderly to have been calculated by a computer.
How long it takes can be calculated as:
| Duration = required effort / resources applied |
The thing that makes this sometimes difficult is that there are three variables: duration, effort and resource. It is a three way balance that you have to achieve. Here are some examples:
If we are estimating the duration of a
task to type in all the product information for the
product catalogue, maybe the calculation is:
|
If we double the resources, we can get
it done faster:
|
Suppose, instead, that we are scheduling
a 4 day training course for the project team. If we
decide to assign twice as many people it does not become
a 2 day course - it is the effort figure that changes.
|
Very often, however, you know exactly
how many resources you have - so that remains a constant.
I only have 4 of this type of resource available, so if
the job takes 20 days effort - it will last 5 days
|
In each calculation, we tend to lock one of the variables, input something that is variable, and thus re-calculate the third variable - otherwise a formula in the form D=E/P would have infinite solutions.
Bear in mind that this simple arithmetic tends to ignore other complications. Consider whether it is valid in these cases:
This arithmetic and logic is more complicated where multiple resources are assigned to multiple tasks, potentially at the same time (but that will depend on the detailed scheduling), in differing proportions. For example:
Project Tracking
|
So, the Project Manager needs to be available one tenth of the time on average and the Project Administrator needs to spend half time on this work. The duration of the work will be defined by whichever resource takes the longest to do their proportion. In this case, we would want to balance their effort and availability figures so that they both work at the tracking task for the full duration of the project. In other cases, it may be one specific resource that is holding up completion.
Bear in mind also the pitfalls you might discover, particularly with automated scheduling, and the various tricks you might need to play to avoid them (as described earlier). What do you think would happen to this Project Tracking task if the Project Manager had to work full time on a different task for a period of 10 days in the middle of the project?
There are several complications in the
"real world". In the estimating section, we examine the
way complexity does not grow
linearly with scope. Let's take a look at another
complication and see how the complexity factor also affects that.
The common view is that the more resource you make available the faster you can complete the project. It is important to understand that infinite resources do not lead to zero time. Adding in more resources helps you approach the fastest possible timescale - but there is a limit to how fast that could ever be. Applying Putman's Software Lifecycle Management theory" we see that a "limit of possibility" is approached - but never reached. We can also see that applying very high levels of resource or accepting very long timescales does not look like good value for money. The parameters you might adjust as a Project Manager would tend to be in the middle of the curve where putting in extra resource gives you a good return on investment.
Barry Boehm in the "Constructive Cost Model" (COCOMO) allows for a series of cost drivers that recognise the differing levels of complexity in the various aspects of the project. Allowing for the complexity factor we can see that you do indeed approach the fastest possible time - but, once you reach it, putting in more resources will slow the project down.
A further thought on that from Brooks - adding manpower to a late software project makes it later (1995).
Forget the arithmetic you learnt at school: If one person can dig a hole in four hours, two people might dig it in two hours, but four people would fight to get their spades into the same space, and 100 people would probably never be able to get started. |
Planning complex projects with many streams and cross-dependencies is never easy. The learning from the complexity factor discussion suggests that complex undertakings should be broken down into separate less-complex elements wherever possible - provided you do not generate a new level of complexity in terms of the relationships between the sub-divided elements.
Often the best approach is to identify separate streams of work which form semi-autonomous layers of the overall business solution. Most of the dependencies will run along these streams. With good management, only a few key dependencies will cross over between the streams. You should identify these key synchronisation points. This logic is particularly useful if you are managing a project as a set of sub-projects each with its own leader and sub-plan.
A
typical pattern with workstreams is to find there are points
where many elements of the project need to be handled in unison,
and other times when the work can safely progress as separate
streams. Key milestones should be identified to show where the
work has to come together and where it can split.
Try to adopt a logical, structured approach to dependencies, for example:
It is not good practice to keep changing the plan every time there is some divergence from the original expectations (although it can be a useful way of hiding problems). From a practical point of view, it does make sense to recalculate the plan if there has been any significant change. The new plan would be based on the current circumstances - to manage expectations and to schedule dates realistically.
When you do need to issue updated schedules, you should retain the original version of the plan as a baseline. This allows you to analyse progress and achievements against the original targets.
Phase end is always a good time to review progress, check that objectives have been met, tasks have been completed, deliverables have been delivered, quality targets have been achieved etc. You should take a good look at the project's achievements against your plan:
At this time or earlier you should also be preparing for the next phase of work. In particular, you will be developing the detailed plan for the follow stage of work.
At the end of the project, its outcomes should be reviewed and analysed in much the same way as at the end of a phase. Here are a few specific points about the end of the project:
This is when the project's accounting will be finalised, reviewed and reported.
The success of the Project Manager will probably be measured partly in terms of actual performance against the plan.
Planning and tracking information should be brought up to date and stored for future reference.
Past experience is the single most valuable guide for future planning and estimating - do not lose that knowledge! |
 |
| Copyright © Simon Wallace, 1999-2018 |
