Critique of a real life IT Project

Table of contents

1 HISTORY OF THE PROJECT

2 MAJOR DECISIONS TAKEN DURING THE PROJECT

3 PROBLEMS ENCOUNTERED

4 ATTEMPTED SOLUTIONS

5 REPORTED EVALUATION

6 ANALYSIS OF THE PROJECT.
6.1 Project Integration Management
6.2 Project Scope Management
6.3 Project Time Management
6.4 Project Cost Management
6.5 Project Quality Management
6.6 Project Human Resource Management
6.7 Project Communication Management
6.8 Project Risk Management
6.9 Project Procurement Management

7 MY APPROACH

8 REFERENCES

1 History of the project

The PRS (Performance Right Industry) is a non-profit organization in the United Kingdom that collects the royalties for the holder of the copyrights of music songs when they are performed at a concert or played at the radio. With the guardianship of the musical performance rights from over 750,000 copyright holders and a £155 million collected from 26,000 UK members each year the PRS has a complex role. It is controlled by the General Council, which is responsible for the administration and formulation of the policy. The management team consists of a CEO and his team of executive directors who are responsible for the day-to-day running of the business. For the complex administration processes several distinct applications are running on multiple mainframe computers.

The PROMS (Performance Rights On-Line Membership System) project was conceived in 1987 with its aim to get rid of the mainframe computers and replace them through several mini computers. The data and mainframe applications should be combined into one coherent database to reduce the redundant sets of identical information stored on different computer systems. The new system should allow 300 people to use the computers concurrently. Therefore a special OLTP application was needed to provide adequate response times for all users. Concerning this application, which required a high performance hard- and software environment, there was a heavy debate in the industry about the feasibility to use such a demanding software on minicomputers. For this reason the project required a careful design and planning. (The Performing Rights Society – Case Facts, no year)

2 Major decisions taken during the project

The initial phase comprised establishing a feasibility study and a requirement analysis by undertaking a series of investigations and preliminary designs. Reviewed by external consultants the results in form of a business case were

submitted to the General Council in 1989. As the go-ahead for the project was given the hardware was purchased and the contractors started working on the system’s components. The project management decided to pay them according to their amount of work done rather than by what they delivered since it was planned that the system will be delivered on time-and-material. As the first problems occurred in autumn 1991 due to software and hardware difficulties nothing was done until February 1992 with six weeks to go to the projected implementation date. With the abandonment of this date the General Council demanded monthly progress reports. As further problems occurred the revision of an external consultant agency was conducted which claimed the project plan to be inadequate. But the suspension of the project was rejected and a new plan was produced to complete the system by the new implementation date in September 1994 with further investments of £6 million needed. But the General Council intervened and decided to suspend the project, having more than £11 million spent since the commencement of the project. The following assessment of an employed external consultant agency revealed that it was not feasible for the system to become salvaged any more. As many senior managers left the organisation a computer literate CEO and an IT director were appointed as a direct reaction of the PROMS disaster. Their first action was to install a new mainframe. (The Performing Rights Society – Case Facts, no year)

3 Problems encountered

With the project start in 1989 everything appeared to run smoothly until the autumn of 1991 when a 10-week delay was reported to the General Council. The contractor responsible for the software development of the database received insufficient information and to complete his tasks he made various assumptions that turned out to be wrong in some cases. As a result the database design was totally inefficient with unacceptable response times for its users. In addition the choice of hardware and operating system was not meeting the performance requirements needed to run the large 40Gb database. The implementation date in March 1992 had to be abandoned. Further problems

arose with the hard- and software as well as the data files over the summer of 1992. The assessment of the project plan by an external consultant company revealed its inadequacy so that it had to be rewritten by the project management that cost a lot of time. But the new cost estimates turned out to be too high and the projected finish date of the project too far away so that the project could not be continued and was therefore suspended. (The Performing Rights Society – Case Facts, no year)

4 Attempted solutions

During the project one can observe a lack of mid-course corrective actions that could carry the outcome of the project to another result. As the software difficulties were reported to the General Council the work continued regularly without any counter measures until the absolute project deadline (March 1992) had to be abandoned. Several months later the General Council demanded monthly reports about the progress of the project and it was beginning to question different aspects of the project. At that point the new project plan was developed and interim and detailed plans were submitted in May/July 1992. As the series of problems did not end in summer 1992 the assessment of the plan from external consultants was conducted. Although the plan was evaluated to be inadequate the suspension of the project was resisted and the managers wrote a final plan. But the results revealed further funds and time required to successfully complete the project, so the General Council terminated the project abortively. After that independent consultants were ordered to assess whether the system could be salvaged or not. (The Performing Rights Society – Case Facts, no year)

5 Reported Evaluation

Within the project there were multiple flaws identified that had an enormous impact on the project success. After the suspension of the project the General

Council has employed external consultants to provide an evaluation of the project:

The preliminary work of 1987-1989 was reviewed by a group of consultants before the business case was submitted to the General Council. But this group was the same one that did the preliminary work, so no independent authority examined the accuracy of the work: “It is more than difficult to review one’s own work.“ (The Performing Rights Society – Case Facts, no year)

In addition there were inadequacies in the behaviour of the managers responsible for the project since no one actually had knowledge about IT and the needs of developing large projects. They acted if nothing was serious.

The senior management did not understand the administrative processes within the company that should be computerized. Those were so complex that even staff, suppliers and programmers were not able to understand them. No time has been spent on becoming familiar with all the processes involved in the system – the manually held information was not ready to be computerized. Due to the lack of understanding they put too much complex processes into one task, did not check whether the written data format of distinct forms can be transferred into the database and above all they went ahead building the database without understanding the inconsistencies and information in the processes. The project failed due to the lack of simplifying the information required to design the database.

Therefore the contractor got insufficient and vague information and made assumptions in order to complete the work. That reflects the incompetence of the contractor because it is usual to warn management about the risk of proceeding the development of the database in case of a lack of information.

The sources for the hardware problems were the managers and consultants themselves, who were attracted by the opportunity to work with the leading edge of technology. Therefore they selected UNIX as the platform for the critical OLTP application rather than considering all alternative technologies available as potential solutions for the project.

In general the attitude among staff at all levels was not conducive for the project’s success since there were tensions between the PRS and the General Council. The PRS tried to prevent the General Council from gaining access to the organisation they were supposed to control. So it becomes obvious now that

a project that was flawed from the beginning could continue for nearly two years before it was suspended. (The Performing Rights Society – Case Facts, no year)

6 Analysis of the project

Examining the project one will find a lot what actually went but should not go wrong in such a large project. The first obvious thing to mention is that they did not divide the project into different phases. They are essential to the project’s success since they provide better management control. Achieving its deliverables, followed by a thorough review (called phase exit or kill point) to determine whether the project should continue with the outcome of the phase or not, completes a phase. In that way errors can be identified and corrected more efficient. Since PRS did not split the project into phases and did not allocate deliverables to them they recognized the flaws at a point where there was no correction possible. Due to that the management did not have the basic control over the project’s development. (Duncan, 1996)

All processes within the project lacked one very important component, the controlling process. As stated above the missing kill points neglected the question whether the process was successful or not. So they could not ensure whether the project objectives are met since they did not monitor or measured progress properly. The PRS submitted reports to the General Council, but they were kept confidentially, so nobody was informed about the status of the project. The reports did not fulfil their intention and no flaws could be detected and corrected.

Regarding the distinct stakeholders they had different expectations of the project and there was no resolution to those differences. While the General Council wanted to cut down costs and add value to the customers, the PRS and the external stakeholders like the contractors and consultant agencies saw the project as a change working with the edge of technology. This was not only due to tensions within the organisation rather than a lack of communication between the stakeholders.

The further analysis will be divided into the 9 areas of project management to examine the project from every possible angle:

6.1 Project Integration Management

This area in project management ensures the proper coordination of the elements the project contains. The main component for integrating the distinct areas is the project plan. It should guide the project execution, plan the reviews, document the decisions and assumptions made, facilitate the communication among the stakeholder and should provide the base for project control. But a thorough analysis of the PROMS project reveals that the plan was obviously not used for the stated intentions. It was more a thing to satisfy the higher instances within the organisation’s hierarchy rather than a tool for mastering the complexity of tasks. It was developed from people who did not have a clue about the complexity of the project and about IT, so the precision of the plan was not adequate enough. Due to this lack of expertise the preliminary work in 1987-1989 led to a poor project plan that caused a disaster where no counter measure was able to undo the damage. But the failure of the project could have been recognized earlier when the performance had been measured and reports had been written to update the project plan and to gain overall control. Since the risk of such a large project is extremely high having control over the activities is more than important. Therefore a high-quality and up-to-date project plan is unavoidable. (Duncan, 1996; Schwalbe, 1999)

6.2 Project Scope Management

Scope Management includes identifying all the work required to complete the project successfully. This is a crucial issue in the PROMS project since it was totally flawed already in the planning phase. In terms of scope planning, which should be the basis for future decisions, the processes involved were not understood and analysed properly, which caused fatal consequences later on. There was absolutely no statement that dealt with how the scope will be

managed, how the scope changes will be integrated into the project. Moreover no assessment of the expected stability of the project scope was done. Due to the fact that the project management team lacked the understanding of the processes multiple complex tasks were combined to a single one. They were not able to manage the scope when they realized that their planning did not work. With the insufficient planning their Work breakdown structure (WBS) did not include the detail required. The input (scope statement, deliverables, etc.) for the WBS was already missing, so how is it possible then to divide deliverables into sub components? The scope was not verified either. The acceptance of the project scope by the stakeholder could be gained since the planning phases were reviewed by the consulting agency that actively participated in these phases. An inspection by an external company that cannot give an independent and unbiased evaluation could not identify the flaws. (Duncan, 1996; Schwalbe, 1999)

6.3 Project Time Management

This management area ensures that the activities within the project are completed on time. The important input for this area is the accurate description of the work to be done in order to sequence them and to estimate their duration. But as already stated above the input was already incomplete and flawed. The activities and their dependencies could not be defined precisely and therefore the accuracy of their duration was not verifiable. When it comes to schedule management one can observe that no start and finish dates for the activities were defined. There were no dates for deliverables or major milestones declared. That is the reason for the lack of pressure to do anything against the time overruns, since the only big due-date was far away in March 1992. The overview about the progress of the project got lost accounted through the loss of schedule control. Again reports could have helped to identify and to react on delays. In order to avoid potential time problems in future prospective planning must be considered. That means embedding changes in schedule or activity durations into the project plan. As the project plan was reviewed it was too late to finish the project within the given time frame. The complete baseline to

measure and report schedule performance would have done a major contribution to the project’s success. All in all the time management of the project failed due to the blurred scope. (Duncan, 1996; Schwalbe, 1999)

6.4 Project Cost Management

Concerning cost management issues the project lacked the appliance of a satisfactory resource planning. Before and throughout the project the precision of the overall cost estimates was not known. The expert judgements by the consultants did reveal information about the expected benefits rather than the costs involved with the execution of the project. They were attracted by the fact being able to deal with the leading edge of technology. Costs, benefits, feasibility and the customer expectations that had to be met were neglected. However, in terms of costs no alternative solutions for the project were considered. There was actually no cost management. Cost estimations could not be verified concerning their accuracy and they were not refined during the project as more information became available. In terms of cost budgeting a cost baseline could not be established since the unavailability of a useful WBS, the missing cost estimates and the neglected project schedule. Therefore the overall costs estimate could not be allocated to the distinct work items to measure project performance. Since the quarterly reports to the General Council were kept confidentially the stakeholders were not informed about the current cost situation of the project either. So no corrective actions could be applied in time when information is hidden. Again the control of costs suffered from the incompetence of the project management skills of the consulting agency that was in charge and the relationship and communication abilities among the stakeholders. (Duncan, 1996; Schwalbe, 1999)

[...]