Project Work

A project characteristically involves a complex piece of work being undertaken by numerous participants, requiring, in the assembly of the final product, the intricate integration of the results of their work[66]. Relatively autonomous organisational members collaborate to perform complex tasks that require specialised knowledge and expertise[67]. While these definitions focus on development work they are equally applicable to deployment projects.

Social theorists perceive the way in which time is organised and managed in human projects as dependent on the knowledgeable actions of human beings within their particular social context (e.g. Giddens 1984)[67]. IS development work however manages time by treating the work as decomposable into discrete activities that can be organised into an orderly process and whose duration and interactions may be reliably estimated[67]. These activities form the tasks and milestones of the project plan that states when each must be completed and often by whom.

Keeping to schedule in extremely important in development projects and this is a fact engineers are very aware of. Determining in advance of doing it just how long a task should, and will take is however often a problematical issue, and there is commonly a discrepancy between the time allocated by schedules for the completion of jobs and the time that the actual task will turn out to take[66]. ‘Aggressive scheduling’ combined with inevitable misjudgements about the actual time required, means that engineers are always looking at uncomfortable deadlines, and are invariably under pressure to solve problems in ways that can be dealt with in the available time[68]. In order to complete tasks on time it is common for short cuts to be taken and the ‘quality’ compromised to produce an acceptable rather than perfect solution[66]. Sharrock and Button found in the projects they observed, that monitoring how quickly the work was getting done against the demands of the schedule was a routine activity that was undertaken in any meeting on project business[68]. While a variety of constraints operate on a project, time is seen as the most important to address.

Problem lists are often used by engineers in a project to help judge how they are progressing. In the early stages of a project it is expected that the number of problems

will expand and relatively few will be solved. Eventually however the rate of clearance should start to reduce the number of outstanding problems and the rate of accumulation of new problems should drop[66]. Engineers are able to judge how long this process should take and whether they should be clearing problems quicker. This accumulation and clearing of problems and the use of problems as a method for monitoring progress is something that was seen in the GEOMETER project.

Due to the separation of activities in the project plan and the interrelated nature of project work it is necessary for team members to coordinate their activities. Many different activities are competing for team members’ limited time resource and have to be fitted into, and interwoven with the stream of their other activities[67]. This scheduling is subject to many constraints including the availability of other team members and the completion of their tasks. It is common for several tasks being carried out by different team members to require completing before the work can progress.

As previously mentioned, it is difficult to estimate how long tasks will take. In order to meet deadlines tasks become more compacted within the plan and it has to be adapted accordingly. As the work overruns tasks run into the time previously allocated to testing, leaving testers struggling to complete the necessary tests in the time available[69]. Inadequate testing has been attributed as one of the reasons behind many high profile system failures including the PAS system at the UK Passport Agency and the opening of Terminal 5 at London Heathrow Airport. Whittaker argues that as software becomes increasingly more complex, so does testing that software[70]. This is a point that seems to be forgotten when allocating time for testing, with some tests being postponed in order to meet deadlines, a problem seen in the GEOMETER project.

In complex projects where plans are constantly changing, being able to adapt your work accordingly is important. Developers heavily rely on informal, ad hoc communication to fill in details, handle exceptions, correct mistakes and bad predictions, and manage the ripple effects of all these changes[71]. It is this informal and ad hoc communication that allows them cope with the instability of project work. As projects become larger and more distributed this becomes more difficult as it is

hard to know who is available and initiate communication across distances. Tools developed to help with these problems are described in section 2.3.

Previous research on project work indicates that engineers are aware of the many problems they are likely to face in a project and are constantly working to try and produce something that meets the needs of the users in spite of these ever changing constraints. While this awareness of the difficulties can be helpful, the high number of projects continuing to fail to deliver what they promised, on time and on budget suggests that more help and support is needed.