Expectations 3: Time dilation

22.04.18 06:04 PM By Matt Koopmans

Einstein described the dilation of time in his Theory of Relativity - two different observers experience a difference in time elapsing, based on their difference in velocity and/or experienced influence of gravity. In projects, a tongue in cheek analogy can be made: measuring the velocity of elapsing time by minutes of accomplished tasks, the passing of time seems to slow within a large program. Of course, there is no physics at play, just program dynamics caused by increased complexity with increased team sizes.

The larger the size of the project, and the closer to the centre of activity you are, the slower things tend to get done.

 

The "slack effect"

Any good project schedule has slack strategically placed in the plan:

·  Scheduling contingency - actual time spent on tasks tends to be in round figures - i.e. 2 hours as opposed to 1 hour and 45 minutes, 40 hours as opposed to 37 hours, etc. 

·  Risk contingency - slack built in to reflect risk in certain tasks taking longer before completing, therefore keeping the program completion date fairly stable independent of these risks occurring

·  Dependency slack - risk contingency applied to dependencies to the critical path, minimizing risk that slippage will slip the critical path.

Slack tends to behave like storage space in a home - the space available tends to get filled with things, and the average value of the things occupying the storage space is in direct, but inverse relationship to the storage space available. In other words: if you have slack in the program, it tends to get filled with activities, and the more slack there is, typically the lower average value the activities return to the program. This is the "slack effect". 


No slack or low slack planning?

Having no slack on the schedule is just asking for trouble - things will go wrong. The question is: where will things go wrong first - at customer end, or at the implementation partner? It is like the proverbial escape from the charging bear: you don't have to be the fastest runner, as long as there is at least one slower than you! In other words, this tends to create a situation where customer and implementer each look for dependencies on "the other side" and use those to build slack in their own schedule where needed. Although it does not exclude it, this is not conducive to a cooperative environment. Planning slack is something that simply needs to be done. but there are some guidelines to follow to keep it under control in both scheduling and managing slack:

·  Schedule slack in sequence - beware of compound slack. Start with the largest slack, scheduling contingency, and then work down to the lower level detail risk contingency and end up with dependency slack. This prevents scheduling contingency being applied over risk contingency, which in turn is applied over dependency slack.

·  Schedule slack separate from the task - if a task is scheduled for 8 days, and you add a day of slack, do not just add the day to the task, as that will be seen as a normal schedule. You can either schedule a day of no task between this task and its successor, or schedule a task called "slack" without assigned resources between the task and its successor (assigning a slack task allows for easier measurement of slack and its use into he program).

·  Using slack should not be "business as usual", nor should it be excessively difficult to apply. There are two actions that need to be taken at the end of each task completion: first, update the time with actual - second, set the slack hours to 0. 

·   Manage activities like slack does not exist - the team should be encouraged proceed according to plan without slack. This means that once a task is completed, the next task moves forward.

·  Schedule slack in grouped tasks - wherever logical, group tasks together and apply the slack task only at the end. This saves a lot of administration work!

·  Manage slack both from customer side as well as implementer side as one. The slack is not a commercial instrument for contracting, it is a mitigation on scheduling risk.

·   Manage and report both duration of task, as well as program timeline.

The complexity in managing contingency and slack is proportional to the complexity in the program - a program with 10+ streams running over 2 years is tremendously difficult to manage by itself, adding contingency and slack management to this is a monumental task. In such cases, it is highly recommended to cut the program up in smaller task-sets - ideally between 6 to 13 weeks in duration. Each task set can then be managed as a separate project within the program from a slack and contingency perspective.

A final thought - in order to arrive on time, it is essential to leave on time. In my personal experience, large programs are difficult to contract, there are a lot of T's and C's to be negotiated. In one particular example, the negotiations went on over eight weeks, eating four weeks into the schedule of the first milestone, which had a duration of six weeks total. This is not setting the program up for success! Allow for complex negotiations to complete, and where necessary (in case of a time-sensitive compelling event) allow concurrent execution on letter of intent - but be aware that negotiations are a dependency in the program, and appropriate slack there is not a luxury.

 

Originally posted: 29 January 2018

Matt Koopmans