Tag Archives: Critical Path

Sensitive not critical

With the greater part of the input and modelling parts of the project planning app complete, I came to a bit of a hiatus. As an iPad app I wanted it to have a lot more in common with finger painting than technical drawing, encouraging the playing with and testing of ideas. The first part of making a plan is done usually with a logic diagram, and that’s what I’ve included. It is on this one screen that you set up all the main bits of work and their relationships. To illustrate with the banal example of making a decent cup of tea you have :- Fill kettle, boil water, warm teapot, add tea to pot, add water to pot, brew, get cups, pour tea, add milk. These resolve themselves into dependency chains thus:-

Logic diagram

In this example I have rather daringly assumed a preference for MIF (Milk in first). If you have a NON-MIF preference, then “Add milk” needs to follow “Pour tea”.

For each of these activities, you need to estimate how long it will take and add a list of people who need to be present to execute it.


Make tea now

This being done, the app can generate a timeline like this.

The great benefit of diagrams like this is that you can see at an instant that you can faff around a bit collecting cups and milk without any problem, but any time wasted filling the kettle, adding the tea or any of those activities which are back to back from the beginning to the end, will delay the tea, and that wouldn’t do.

This is what project planners call the concept of float. The two activities of getting cups and adding milk have between them four time units of float. The others have none and are therefore considered critical and the route through them is the critical path. Any delay to any of these delays the whole project commensurately. For large organisations using contracts that they either have prepared themselves or are familiar with, this is all good stuff as it provides some sport for their teams of quantity surveyors and lawyers to take on another team and issue legal claims and counter claims to enforce the doing of the work on time, or to gain compensation.

For most of us dealing with an in-house team, or a small local contractor we tend to adopt the same means of control and influence as a Falconer does with his bird; we aim to become the preferred source of food / money / kudos, and then keep it in short / controlled supply. We are generally not interested in building a case we can take to the county court when the plumber’s wife has to go to hospital and he won’t be in on monday, rather we want to know what the impact of the delay will be on the work of others and on the project as a whole. In other words we want a tool that doesn’t quantify and document problems, so much as help us manage them.

It was whilst looking at this that I decided that :-

a). my users wouldn’t be overly interested in critical paths per se (After all they are dull aren’t they?), and

b). not all critical activities are the same.

To explain, suppose in the example above each unit of time is a day, and each task is done by a specialist. If the teapot warmer only comes in on Wednesdays, a delay in boiling the water doesn’t cause a delay of one day, it causes a delay of a week.

The app has a calendar attached to each project, so that you can set the project to work weekdays only for instance. In addition, each person has their own calendar so that their working weeks, leave and planned absences can be included in the calculations.

Instead of showing users the usual charts and lists showing critical paths and float, my app shows a simple timeline for the plan, and a diary type report for each person, and the project as a whole. As soon as the plumber’s calendar is updated with his forthcoming absence on monday, the delays will show and can be dealt with.

To try to locate problems beforehand, rather than flagging up critical path items the app concentrates on the activities and people which will cause the biggest headaches when they fall behind or let you down.¬†What the app does is model and re-model the project with delays of one to five days on each activity in turn to see which are the most “sensitive” i.e. more than critical. These are the ones it flags up for attention. I haven’t yet figured out the best way to test which people the project is most reliant on, a hot bath should help.