Manual methods – part 4b – contingency part 2
The weather
Data has been collected for weather activity for many years for most parts of the world.
There is information covering daily, weekly, monthly and annual trends. This history of weather constitutes the climate of a country.
For project tasks that must take into account the weather it will vary according to the local conditions in different parts of the world.
The weather contingency cannot be accounted for just by adding a ‘factor’ to the task durations.
The effect on a task will depend heavily on the severity of the conditions.
If rain occurs it may be light or heavy. Under these circumstances many tasks that may go ahead reasonably happily in light rain, may be slowed or completely stopped in heavier rain. There is also the psychology of the workers to consider. When the weather is not conducive to good performance the work rate will slow down any way because there will be less enthusiasm.
When there are high temperatures concrete may begin to dry out before it sets.
Where ever you are working there are likely to be statistics relating to the local climate.
The table above is for a fictitious region and shows average data which may have been collected over 30 or 50 years.
The table is based upon rain affected days in the sense that a rainy day is not good for the project. In a similar fashion it could have represented extremes of temperature with poor days being too hot for the project task.
For each day of the month the rain level has been estimated to give a rating of how many days in the month you consider would be poor for project work. These are then given a probability of occurring which is just the ratio of the ‘poor days’ to the ‘total days’.
The probability is seen as a percentage and in decimal form. This is then repeated for the good days.
The above table gives a black and white view of working on a project.
If we take February there are 17 poor days which gives a probability of 39% of good days for work.
In other words, we are saying you can only work for 39% of February.
This needs to be tailored to individual tasks. For example, the rainfall that is considered could be all forms, that is, a down pour, moderate and light rain. Some tasks may well be feasible in light rain and hence when assessing these you may not use a probability of 39% but 60% of good days, that is you would not extend the duration for these tasks as you would be expected to work on many more days.
The other thing to note is that in the above table it takes into account every day of the month, including weekends.
If we look at April for 2007 there are 30 days and 15 good at 50%. However, there are only 21 working days. Therefore, the good days will be 50% of these, that is 11 days in April.
Also, the data is based upon average values over a long period of time. So, any of these values could be way out for a particular year.
When we think about the duration necessary for the consideration of weather all we need to do is to take into account the probability in the table or modify for the particular task.
So, if we had a task for 12 days in May we would divide this by 61% to give the total of good and bad days needed = 20 days (to the nearest day).
Now these are project days, so, if you:
Start date = Monday, 14th May End date = Friday, 8th June
This is 20 project days but 26 calendar days.
We noticed earlier that the weather data is accumulated over a long period and we see the average. Some months will be better and others will be worse. If you make sure that you carry out this contingency for all the weather affected tasks then poor months and good months will tend to average out over a long project.
Multiple probabilities
When you have to include more than one type of weather constraint you will need to add only the delays to the duration.
For example, assume good days:
Rain probability = 60% Temperature probability = 80% Wind probability = 70%
If the task would normally take 10 project days the increased durations would be:
Rain = 10 / 0.6 = 17 days and the extension = 7 days
Temperature = 10 / 0.8 = 13 days and the extension = 3 days
Wind = 10 / 0.7 = 14 days and the extension = 4 days
Hence, the total extension would be 7 + 3 + 4 = 14 days and the final task duration would be 10 + 14 = 24 project days.
This might be considered too much. If you just take the longest delay, that is 7 days, this would also happily include the potential delays for temperature and wind. Hence, the task could last 10 + 7 = 17 days and not 24.
Incorporating the weather window
In a similar fashion to the case of float the weather ‘delay’ can be put in using a dummy task.
The delay can be put in series after the actual task. If put before it suggests that the actual task cannot begin until the weather delay has completed.
When incorporating any delay it seems easy to just extend the duration of the original task.
Why not take a task supposed 10 days and extend the duration by 6 days to 16 days?
The reason is that delays do not consume any material costs. If a task uses £10,000 of materials it will still do so no matter what the delay. Labour costs will increase, unless you can use people in a part time manner which is pretty much impossible. The delay dummy task uses no materials.
On some occasions there will be a series of weather affected tasks. In this case you can add a collective delay at the end of the final task as a dummy task. The ‘weather window’ delay can also be added in parallel to all of the tasks.
This method gives greater focus to the existence of the weather window and it makes it clear to what tasks the delay is attributed.
This may not be obvious when the delay is in series for a series of tasks.
Under PRINCE2® 2009 planning is covered by the Plans theme.
The purpose of the Plans theme is to facilitate communication and control by defining the means of delivering the products (the where and how, by whom, and estimating the when and how much).
[see Plans - Purpose]
A plan can only show the ultimate feasibility of achieving its objectives when the activities are put together in a schedule that defines when each activity will be carried out.
[See Plans - The PRINCE2 approach - Prepare the schedule]
The use of contingency within PRINCE2 is treated differently.
For PRINCE2 2005:
Contingency may be used where a specific risk has been identified.
Any risks (threats or opportunities) to the project will be known and analysed as part of the process Analysing Risks (PL6).
If the risks are such that contingency plans have been prepared the Project Manager should go to the Project Board for a contingency budget.
This would be needed should the risks occur.
For PRINCE2 2009:
Contingency is not used instead tolerances are set.
A PRINCE2 principle is that projects are managed by exception, setting tolerances for project objectives to establish limits of delegated authority.
Tolerances define the amount of discretion that each management level can exercise without the need to refer up to the next level for approval.
[see Progress - purpose]
Tolerances are the permissible deviation above and below a plan’s target for time and cost without escalating the deviation to the next level of management.
There may also be tolerance levels for quality, scope, benefit and risk.
[see Progress - Progress defined - Exceptions and tolerances]
Although the comments below specifically refer to contingency, PRINCE2 might well advise the use of float in such circumstances.
[see Detailed planning - part 12 – slack (float)].
Float is described under PRINCE2 2009 [see ‘The Complete Project Management plus PRINCE2’].
It is the amount of time that an activity can be delayed without affecting the completion time of the overall plan is known as the float (sometimes referred to as the slack).
Float can either be regarded as a provision within the plan, or as spare time.
The critical path is the sequence of activities that have zero float.
[see Plans - The PRINCE2 approach - Prepare the schedule - Define activity sequence]
PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.