Decision and Discrete Coursework - Putting up a tent

Introduction

As part of his job as a children's worker, my father spends the summer running camps in the Dursley countryside, in bell tents which sleep about 7 people each.

Fig. 1: Structure of a bell tent

In the week before the children come, he recruits a number of people who go and put up the camp. Obviously the first thing they need to do is put up tents (otherwise they'd have nowhere to sleep themselves): this is quite a difficult task as a number of different things need to be done, several of which involve a number of people. It is important that it is done quickly, however, as there are 6 bell-tents to be put up and they must be done then in case it starts to rain. I decided to see if critical path analysis could make the job any quicker.

Initial data

I began by looking at what was actually involved in putting up a bell tent. I observed the three helpers at the camp putting one up, and noted what they did:

1. The first thing they did was to each go down to the store shed and fetch the equipment they needed. This consisted of a pole (in two sections), the tent (in a bag) and a groundsheet. The tent was heavy and took longer to bring up.
2. Once everyone was back at the site, they laid out the groundsheet. This took two people.
3. They then put 12 guy-pegs in a circle.
4. Now one of them assembled the pole.
5. Having done this one of them took the tent out of the bag and unfolded it.
6. They then inserted the assembled pole into the tent and lifted it up until it was vertical. One person held the pole and manoeuvred it into the centre of the tent.
7. This person held the pole steady whilst the others attached the guy-ropes to the pegs.
8. Having done this he got out of the tent and they all hammered in the brailing pegs.
9. They then crawled around the edge of the tent connecting the brailings to the pegs.
10. Finally, one of them went inside the tent smoothing down the groundsheet and checking it was sealed in nicely.

I used this to draw a table of the activities they performed, how many people each took and their approximate durations (in seconds). I also added in the immediate dependencies based on their activities^[1]. This gave the following table:

Using this table, I drew an activity network to find out which activities were critical:

Fig. 2: Activity network (critical activities are shown in red)

The last thing I needed before I could start analysing the situation was a cascade chart showing how many people each activity needed and the chain of dependencies inherent in the task. In order to create a comprehensible chart the activities on the chart must be ordered logically (i.e. activities after their dependencies) using cascade activity numbers (see MEI Decision and Discrete 1 page 104). I allocated CANs (cascade activity numbers) using the following algorithm:

1. Set CAN to 1
2. Begin at start node
3. Pick an un-numbered activity from this node and number it with CAN
4. Add one to CAN
5. If not all activities leading into node at end of this activity are numbered, go back to last node with a choice of activities to number, then go to 3
   Else continue to 6
6. If this is not the finish node, go to 3
   Else continue to 7
7. End of algorithm

This gave the following numbering:

Having done this, I constructed a cascade chart (using a program I wrote myself, incidentally). This is figure 3, over the page. Solid lines show dependencies; dotted lines 'float' over activities and do not obstruct their path. The width of each activity depends on the number of people it requires; in this way the cascade chart can be used for resource levelling as well.

I now have all the information I need to see whether I can improve the efficiency of the team as they put a bell-tent up.

Fig. 3: Putting up a tent - cascade chart

Interpreting the data and refining the system

It is quite easy to see from all three diagrams (the table, the activity network and the cascade chart) that the system currently in use is extremely inefficient. For a good deal of the time only one or two people are doing anything useful, whilst the long chain of critical activities means any delay would push everything on. I feel sure it can be rearranged to make it more efficient whilst introducing more slack time.

To do this I will need to make each person rather more independent, by seeing which jobs actually need doing before the process can continue. For example, the guy-ropes don't need putting out until the tent is going to be put up; however the tent must be fetched before it can be raised. I am also trying to lessen the number of people needed for a task where possible: pegs can be put out by fewer than three people though it will take a little longer. Thinking along these lines, I rewrote the dependencies in the following table:

Using this table I can redraw the cascade chart and activity network to see how long an optimal solution to this task would take, but it is important to remember that at the moment this will not take into account how many people there are to do the task; that is, the optimal solution would likely require more than 3 people at some places. It is

Here is the new activity network and cascade chart.

Fig. 4: Activity network

Fig. 5: Cascade chart

As I expected, this solution requires too many people at some points, but with careful use of the float for non-critical activities (such as laying out the groundsheet) I can create a feasible solution which does not take much longer. The final solution I created is explained in the following table, showing what each person is doing at each stage in the task (horizontal lines mark points at which each person must have finished their job for the task to continue):

This translates to the following activity network:

and the following cascade chart:

This has saved 2¹/₂ minutes overall; this may not seem much, but over 6 tents the quarter of an hour could save the team from being caught out by bad weather (always a threat in England). There is also a significant amount more float among the non-critical activities, so a delay would be less likely to affect the process. As you can see, the efficiency of the task has been significantly improved merely by thinking about it in a more logical way, using effective resource allocation and arranging dependencies efficiently.

Mark Hutchinson

^[1]  Note that these may not turn out to be the real dependencies, as they could be waiting for no reason.

^[2]  Because the brailings hold the edge of the tent down to seal it, and straightening the groundsheet checks this.