Impressive! Don’t fret I am going to try and simplify things in this article. In my last article I focused upon the concept of “work breakdown” and how it can help overcome the paralysis that may arise when we are confronted by a seemingly over-whelming project proposition.
In this article I want to focus upon the concept of dependencies in creating a project schedule. To some of you this may be old hat to others revelatory, wherever you are hopefully the following will be of benefit.
When creating a schedule tasks can be identified as being the predecessor or successor to other tasks in the project. To establish predecessors and successors we create dependencies between tasks, the most common and easily understood being the Finish to Start dependency, in essence once I have done A I can then start B. Simple and familiar, we all employ this thinking every day in how we plan what we are going to do. At its simplest level a project schedule can be little more than a sequential to do list.
If you stick with just the Finish to Start dependency you can end up with very monolithic and time consuming projects. The chances are however that you will not have as much time available to you as you would like and it is here that the three other types of dependency employed in creating a schedule come into play.
A Start to Start dependency will suggest that a task can commence when another task commences, the start of one triggers the start of the other and there would be no point in doing it if the other task had not yet started. Reading that sounds a bit complicated so here is an attempt at a simple illustration. If you were planning on drastically changing your garden layout you might need a skip to dispose of excavated materials and the like, there would be no point in having a skip in place if the works had not started consequently you might plan to have the skip in place when the excavation works start.
A Finish to Finish dependency will suggest that a task cannot finish until something else has finished, in most cases we want to co-ordinate the conclusion of various things so that they finish at the same time. As an example if you were cooking a traditional Christmas Dinner you would serve a variety of dishes as part of the main course, each dish from the roast poultry to the peas and gravy will take differing amounts of time to cook. The person responsible for orchestrating this annual ritual will no doubt put different things on to cook at differing times so that they are all miraculously ready at the same time – in theory.
The last and most unusual dependency available when creating a schedule is the Start to Finish dependency, it is designed to promote continuity. Something cannot Finish until something subsequently has started. A good illustration of this principle in everyday life is the notion of shifts being continuous – a nursing shift in an intensive care unit will keep going until the next shift has started, they cannot Finish unless their successors have Started.
Thankfully this last dependency is the least commonly employed type of link between tasks.
As I mentioned before we employ these “relationships” between tasks all the time and in the main we tend to just get on with things without having a plan to refer to – invariably we hold a plan in our heads and as we are the only person involved that works just fine. Projects however invariably involve scale, complexity, other people and of course CHANGE.
By structuring a schedule we can identify the timings for various activities and prepare for them and ensure the right person is available at the right time, we can also appreciate what happens if a change occurs to our project. If one thing is delayed it will like as not have an impact on subsequent successor tasks. Sometimes the impact can be quite significant other times we can absorb such changes with minimal impact to our schedule. Without creating a schedule however you will forever be reacting to events instead of being in charge of them. Having a project schedule does not guarantee success but if it is well structured and sufficiently detailed it will hopefully have covered most eventualities so that you are in control of events rather than being dictated to by them.
In addition to the types of dependencies scheduling also employs the concept of lag or lead to introduce time delays between some events in the schedule. For example I cannot complete contracts until 4 weeks after I exchange contracts – this would be exhibited as a Finish to Start dependency with a 4 week lag between exchange and completion, completion lags exchange by a period of 4 weeks.
Lag periods can be a measurement of time or progress and in some cases the passing of time will be an absolute measure of time rather than a measure of working time. For example a plastered wall takes time to dry out before it can be decorated – the drying process is continuous and will happen regardless of whether or not we are celebrating New Year, Easter or any other official non-working days.
Continuing on from my last article any project is likely to consist of a number of phases or stages. In the main we would suggest that when creating dependencies you look to create links “within” a stage or a phase, in essence regarding it as a mini project. Creating numerous dependencies “across” phases or stages can sometimes create overly complicated schedules.
An established project management principle is the use of “Milestones” to mark key points along the way. Milestones can also be used to conclude a stage or phase and to trigger subsequent stages or phases.
In the illustration below the item in the middle is a Milestone that marks the conclusion of one part of a project and also triggers the next part. It has numerous predecessors and two successors. It can be regarded as being a control gate mechanism.
Quite frequently in this day and age progress on the next stage of a project cannot proceed until authority to do so has been given. Once the decision has been taken there can be a flood of things to do but none of them can proceed until Authority has been granted.
Just because you can create dependencies between tasks does not mean that you should do, try to avoid over-complicating things by only linking tasks if there is an obvious valid reason to do so. I have seen people create project schedules that implode or exhibit unexpected behaviours due to there being way too many dependencies.
Having said that I am now going to contradict myself, ideally every task in a project schedule should have at least one predecessor and one successor with two exceptions – the exceptions being the first and last tasks. The first task will have no predecessor as it is what starts the project and the last task having no successor as it is what concludes the project – these two excluded every other task or milestone should have at least one predecessor and one successor.
This approach was drummed into me at Building College, no sniggering there was such a thing many moons ago. On my course we had a module on project management and we had it drummed into us that when creating a project schedule it should have a “Closed Network” – this is what you will get if you adhere to the advice in the paragraph above.
Try to avoid linking phases to or from anything, phases or stages in the schedule reflect what is happening within them and as such should reflect rather than affect the schedule.
In this article I have mentioned how a schedule can illustrate the impact of change and how sometimes change has significant consequences. In my next article I plan to focus upon the principle of Critical Path Analysis and how a project schedule will comprise a mix of critical and non-critical activities.
[ribbon_new header=”h2″ style=”dark”]Next Steps[/ribbon_new]