The Sodor Oil Terminal

Introduction

The Sodor Oil Terminal project was undertaken by a team of students as a case study in project management. The purpose of the exercise was to organize and plan the project as part of a project team, and deal with events arising during the project life, utilizing techniques and tools learned during the study of project management.

Management of the Project Team

Team Selection

The team selection for the project was left to individuals, who had to form themselves into teams based on personal choice and internal acceptance. In an educational setting random group selection is very common but not realistic as it does not consider the diversity of skills among the students (Blowers 2003). In terms of skill sets the team forming in this project was random in that there was no comparison before a team was selected, merely a choice of friends or acquaintances. This would seem to be negative and, as Blowers (2003) pointed out, totally unrealistic in the business world, where teams of high skill-set individuals would be chosen to give a project the highest possible chance of success.

However, the team selection was not as random as it first seemed, as four members of the team had worked together before, and although it was not acknowledged formally, were aware of each individual’s skills and working methods. This proved to be a positive feature in the project development. There were an additional two members of the group who were known only to one of the core four, and this also proved to be significant during the course of the project.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!
Find out more about our Essay Writing Service

Team Development

Tabaka (2006) paraphrasing Tuckman and Jensen (1977) stated that in the ‘forming’ stage the team members must acquaint themselves with each other and judge their own and others role in the team. This stage was already accomplished in the team which formed for the Sodor project. Four out of six members had already worked with each other in previous projects and knew each others’ capabilities. The two ‘extra’ members were unknown, did not turn up initially, and showed no enthusiasm for participating in the project tasks. They were therefore largely ignored in terms of expectations of the other team members.

The second stage according to Tuckman and Jensen is ‘storming’ where team members try to exert power over one another, and jockey for position within the group. This stage was also already completed within the core team at the start of the project, and the team had already surpassed Tuckman and Jensen’s ‘norming’ stage, with the trust having been built up in previous team encounters, and the ability to work together successfully having already been achieved. The team was therefore ready for Tuckman and Jensens’s ‘performing’ stage. Unfortunately the two ‘outsiders’ to the team never achieved a real measure of trust within the team, so they remained ‘outsiders’ for the rest of the project, but were allowed to contribute in a small way whenever they expressed a desire.

Team Project Management

In the initial stages of the Sodor project tasks, most of the project team was missing for the meetings. This would seem to be a very unfortunate and negative feature for the progression of the project. Ericksen and Dyer (2004) maintained that most of the successful project teams they had studied had had a very decisive launch, with solid project management, direction and clarification right at the beginning, as opposed to the teams who had procrastinated and lacked direction.

As there was no-one else to take the position, the one team member present in the initial stages of the Sodor project took on the responsibility of project manager, at least for that stage of the project. The team member had to act alone at the start of the project and was able to be decisive and act with direction precisely because there was no-one else to interfere, and no negotiations to be performed, and the project was able to progress. As the team was already ‘normed’ it was able to move into the ‘performing’ stage. The reaction of the other team members was approval that the team member had shown the responsibility to take on the task. There was also an underlying understanding that the other team members would accept future responsibilities. This understanding was formulated into an informal contract of work within the team, more out of conformance to the project guidelines than from the need within the team.

Throughout the course of the rest of the project the other team members fulfilled their roles as had been agreed in the contract of works. It was decided that the areas of relevance within the project would each have an individual largely responsible for that particular area. The areas of relevance chosen were planning, costing, procurements, and configuration or change management. The four core members of the group accepted responsibility for an area each with little consultation between members, with the two ‘outside’ members agreeing to assist whenever needed. This seemingly discrete allocation of tasks would have been a negative feature in some teams but was suitable for the character of the team members, all being highly motivated and goal oriented individuals, but also having a high level of trust in their other team members to deliver. There was an element of informal skills measurement in the allocation of the tasks, done on a purely experiential basis rather than empirical evidence.

Tenenberg (2008) questioned whether people who are highly individual can be encouraged into more collaborative behaviour in order to make teamwork more effective. He quoted Cain et al. (1996) and stated that software development should be regarded as essentially social and that the social side of the activity needs to be addressed – the same principle could be applied to any projects which are team-based. Tenenberg (2008) stated that teams have in common a set of ‘collective action problems’ which require teamwork to be solved. One of those problems mentioned is that of dealing with people who do not contribute to the teams efforts. The Sodor project team did not address this problem at all, largely because the team worked as co-operative individuals rather than a team, and those who did not co-operate were simply ignored and their potential workload absorbed by the co-operating members.

Akgun et al. (2007) also postulated team processes as a way to improve the chances of a projects success, and put forward the idea of ‘group potency’ – a belief held by team members that they can be effective. Although the Sodor team worked largely as individuals there was a genuine trust among the main members and a genuine belief in the ‘potency’ factor – which may have been mistaken.

Summary

The team did not behave as a traditional team with a high level of interaction and decision making but rather as a set of co-operating individuals. It did, however, go through the traditional Tuckman and Jensen (1977) stages of development, albeit before the Sodor project began, and also displayed some of the characteristics of a team as defined by Katzenbach and Smith (1993) – complementary team members with common goals and approaches who were willing to be held accountable to the other team members.

Evaluation of the Project

General frameworks of project management can be found from many sources. Gannon (1994) suggested that project management should consist of six functions – ‘planning, organizing, executing, monitoring, reporting and controlling.’ Prodomos and Macaulay (1996) proposed four main activities – ‘planning, monitoring, co-ordinating, and reviewing’. The Sodor project will be evaluated using the categories of planning, and monitoring and control.

The Gantt charts and cost schedules from this section can be found in the Appendix attached.

Planning the Project

Prodomos and Macaulay (1996) cited Jordan and Machesky (1990) and proposed that the planning stage was the foundation for the other project activities. Dvir et al. (2003) reported that a belief amongst project management professionals (supported by the Project Management Institute’s Guide to the Project Management Body of Knowledge – hereinafter referred to as the PMBOK) is that planning is an essential activity which cannot guarantee success, but without which a project will most certainly fail. This belief was reflected in the Sodor case study where half of the activities were on planning the project.

Activity Planning

Initially, the Sodor project was presented as a textual case study, providing information to construct a work breakdown structure. Andersen (1996) argued that in a real situation activity planning cannot be completed when it is most useful, i.e. at the start of the project, because all of the activities cannot be known then. The Sodor project’s activities were identified and provided, so a work breakdown structure could be constructed by the project leader. Other categorizations of the work and different breakdowns were possible but the project team was happy with the project manager’s decisions.

Project Planning

Hughes (1995) suggested a ‘Step Wise’ guide for software projects with details of the stages a project planning team must complete to achieve an effective project plan. PRINCE2 – a methodology advocated and required by the UK government also prescribes stages of project development including planning, which reflects the PMBOK areas of Scope, Time and Cost Management. (Siegelaub 2004).

Scope management was outside the brief of the Sodor project team as it was provided in the project information. Clear objectives and methods were also provided and no feasibility study was necessary. Therefore the first main planning activity of the Sodor team was in time and cost management – to produce a Gantt chart and estimated costs schedule based on the work breakdown structure and provided task precedences to calculate an estimated project end date and project cost.

The next stage in planning was to choose vendors.The vendor selection process was carried out by one member of the team acting as project manager. This was where the rest of the team should have had more input, as two important issues in project management would arise which had implications later – risk management and quality management.

Risk Management

The PMBOK devotes a whole knowledge area to risk management and PRINCE2 identifies risk as one of its components. The PMBOK suggests four phases of risk management – identification, quantification, response and ultimately control.

The Sodor project was totally dependent on third party vendors for both the supply of materials and construction. The biggest identifiable risk for the project would be the failure of a supplier or contractor to deliver on time. This would be particularly relevant to the tasks within the project which were on the critical path in the original estimated plan. Therefore the vendor selection for these tasks should have been carefully considered.

Risk is usually quantified as a function of the risk’s occurrence probability and occurrence impact. (Williams 1996). The probability is a difficult judgement to make but the team was supplied with ratings which were based on how reliable the vendor was. The impact was the penalty cost for late project delivery. The contractors for the two critical tasks of jetty design and construction, and the installation of piping equipment were only rated 2. This proved to cause problems later.

Methods of risk management include trying to reduce the risk (Gannon 1994). Of course, reducing the risk by choosing higher rated vendors would have had a cost and would have to have been judged to be cost effective. This was partly taken into account in the vendor selection policy, but should have warranted more attention from the project team.

Another way of dealing with the risk in a real situation would have been to ‘deflect’ it (Gannon 1994) by transferring it to the vendors. Penalty clauses could have been inserted into their contracts for overrunning the quoted task durations. The Sodor project team were not able to do this, so reduction of the risk was the only option available.

Quality Management

The PMBOK also devotes a whole knowledge area to quality management, so it is obviously an important area for project managers to consider. In the Sodor project the quality of the vendors was the greatest area for consideration. The only indicator of this was the rating provided, which was used in the vendor selection.

In a real world situation vendors could have been required to conform to International Organization for Standardization quality standards such as ISO 9001:2008 dealing with Quality Management Systems Requirements, but this was not an option for the project team.

After the completion of the planning phase with vendor selection, a final baseline plan and costings were produced. In order to adjust the project end date to conform to the required schedule it was decided to pay overtime to the painting contractor. At this point cash flow should also have been considered by delaying the times for the purchase of materials until necessary but it was not, a potentially huge mistake in the commercial world.

Monitoring and Control

Gannon (1994) stated that project performance can be measured by the comparison of actual progress to the original planned progress at any stage in the project. The slippages in the Sodor project at 25 weeks were entered into the project Gantt chart and it was found that as a result of slippage in critical path activities the project would overrun by 4 weeks compared to the baseline, and penalties would apply.

The project team had 3 choices – accept the penalties, reduce the length of an activity on the critical path by paying overtime (known as the time-cost tradeoff problem, (Liberatore and Pollack-Johnson 2006)), or reconsider the precedence requirements (Liberatore and Pollack-Johnson 2006).

It was found that paying overtime to the painting contractor to reduce the project duration by 4 weeks was less than the potential penalties and less complicated than reconsidering the precedence requirements.

Further problems at the 25 April 2001 stage were caused by the vendor selection for the jetty erection. For the same reasons as above it was decided to pay for overtime on the jetty erection thereby reducing the critical path back in line with the required completion date.

By the project closeout it was found that as a result of a reduction in a critical path activity the project completed 2 weeks early and earned bonuses.

Summary

The project was a success if the criteria was to complete the project in time. But more careful selection of vendors could have also cut the costs of the project – the choice of the pipe installation vendor in particular could have produced substantial bonuses.

The complete exclusion of any consideration for cash flow was also a major mistake. In the ‘real’ commercial world, projects can fail because of cash flow problems, so this should have been recognized.

Conclusion

The Sodor Oil Terminal project was a success in terms of completion of the project within the required time. Pinto and Slevin (1988) measure success simply by achieving the projects time and costs schedule, accompanied by an adequate performance. This approach, however, ignores the factors of commercial success in the marketplace, and how the future of the organization as a whole has been affected by the project, factors recognized by Shenhar et al. (1997).

The Sodor project could have been completed within a smaller budget, with greater commercial success and larger profits for future investment in the organization if greater attention had been paid in the areas of vendor selection in terms of risk management. The financial pressure of the large project on the organization could have been offset by greater attention to costings in terms of cash flow optimization.

These negative conclusions can be directly attributed to the project team’s lack of real teamwork in not questioning each other’s actions enough or discussing relevant issues.