Assignment 6 / Project Management - Lisas.de

6 downloads 196 Views 64KB Size Report
This section will be an introduction first to project management in gen- eral and the ... Since the focus of this assignment is on project management the classical.
Project Management Michael Hauser February 2002

Workshop: SW1 Module: EE5048 Tutor: Mr. Prowse Course: M.Sc Distributes Systems Engineering Lecturer: Mr. Turner

CONTENTS

Contents 1 Aims and Objectives

3

2 Introduction 2.1 Project Management . . . . . . . . . . . . . . . . . . . . 2.2 London Ambulance . . . . . . . . . . . . . . . . . . . . .

4 4 4

3 Staff involvement 3.1 How it should be . . . . . . . . . . . . . . . . . . . . . . 3.2 How it was in the past . . . . . . . . . . . . . . . . . . . 3.3 Success factors . . . . . . . . . . . . . . . . . . . . . . .

5 5 5 6

4 Risk management 4.1 How it should be . . . . . . . . . . . . . . . . . . . . . . 4.2 How it was in the past . . . . . . . . . . . . . . . . . . . 4.3 Success factors . . . . . . . . . . . . . . . . . . . . . . .

7 7 8 8

5 Conclusion

10

2

1 Aims and Objectives

1

Aims and Objectives

Aim of this assignment is to get in touch with the basic principles of project management. This will be achieved by reviewing the enclosed case history of the London Ambulance project. The facts from [2] will be reviewed.

3

2 Introduction

2

Introduction

This section will be an introduction first to project management in general and the second part will be an introduction to the London Ambulance project.

2.1

Project Management

Since the focus of this assignment is on project management the classical management will be neglected here. In contrast to classical management, project management is appropriate when objectives are unique, the work that has to be achieved is transient and team and work methods are novel. The main principles of project management are to define the work that has to be done and to find individuals that are responsible for delivering a part of the work. Another principle is to focus on the output of the project, not on how it can be achieved. This enables a greater flexibility and makes a project more robust. The third principle is to balance technical and cultural objectives by adjusting the project to the technical and personal possibilities of the involved environment. A forth point is the ongoing comparison of in- and output. If there is no benefit seen in doing something most people will see no need at all to do it. The last point is to keep things simple by showing individuals how and why his work is useful to the organization. The main task of project management is to deliver business objectives that are non routine. So there will be no absolute rules how something has to be achieved, but with some structuring and organization the risk of new products or processes can be reduced.

2.2

London Ambulance

The London ambulance is a good example to study different parts of project management. There where two attempts in 1987 and 1992 to introduce new despatch systems which both crashed. In 1994 a third attempt started with Ian Tighe as project manager. The parts of the assignment that are specific to the London ambulance project are mainly based on his statements [2]. The two parts this assignment will cover are the involvement of the staff and the risk management. The mistakes that the first two attempts made were that the staff was not involved in the development of the new despatch system and the risk was not managed at all. Those points will be treated in the next sections individually. The sections will consists of three parts. First the theory, how it should be, then what went wrong in the first two projects and third the factors that led the third project to success.

4

3 Staff involvement

3

Staff involvement

This section treats the involvement of staff in the project. The three sections show how staff should be involved in theory, what went wrong in the last two attempts at the London ambulance and what made the third try successful.

3.1

How it should be

Depending on the nature of the project staff has to be involved more or less. A driver for example doesn’t care about the motor of his car as long it delivers the power he wants, but he will care much more about the colors and materials of the interior of the car. So he can choose the colors and materials of the car from a much wider range. Since the London ambulance project is a so called PSO project (it changes People Systems and Organizations) the staff is heavily involved. The work that was done in the past by passing pieces of paper between people is replaced by a computer system, that moves the information from on to another. To be successful this requires that the staff doesn’t have the feeling that the system is build to replace them. Since the staff is involved very much in the project it can be considered as a team member. According to [1] the people working in a team together should have a common identity, a common purpose and a psychological attachment. To be a team all three of these are needed. Another point is the view the different stake-holders have. It is very important to know what the stake-holders think of of a project and what influence they have on the project. If some of them are convinced that the project has a negative influence on them (even if that’s not the truth) and their opinion can not be changed it will be nearly impossible to establish new systems or processes. So the project manager has to make sure that all the stake-holders stay informed, motivated and supportive.

3.2

How it was in the past

One of the first things Ian Tighe was told by a staff member was ’It isn’t possible to bring computer systems here’ [2]. This was the statement of the control room manager. After two attempts to install computer based despatch systems had failed his opinion is comprehensible. After the systems that were build in 1987 and 1992 had crashed the despatch system had returned to a manual method. And it seems reasonable that if someone has seen two projects crash he’s convinced that any further attempts will fail also. And what was even worse was that the staff was told that children of eight could operate the system. So the staff not only had to return to manual methods, they also had the feeling to be obsolete if the project had success. Another point was the the users’ views concerning the realization of the system were ignored. They were not asked when the input masks for the system were designed even

5

3.3

Success factors

though they were the ones who know best what was necessary to ensure that no vital data is missing. It seems like the ons who decided to install a computer based system never thought about the staff at all. The attitude seemed to have been that the hole system is replaced by a computer that does all the work and only some people to supervise it. All things considered it seems that the former project manager had a view of the project as a pure technical one and not as a PSO project.

3.3

Success factors

What made Ian Tighe successful with regard to staff involvement were the following points: He gained users confidence first by some small and safe warm-up projects and involved them after he had success with this way in all the phases of the project that were relevant to them. He gave the users the certainty that they would not be replaced by the system, but supported in their decisions. To gain the users confidence his first action was to replace radio, telephone and power backup systems. With this change that hat nearly nothing to do with the computer system that was to build but that had immediate influence on the users of the system he started to win some friends. After the first successes Ian Tighe introduced his idea of the ’golden circle’. That means he isolated a problem and let only those work on it that were directly involved. This gave the users the confidence that they were needed and the system would be build after their needs. To deliver quick results prototyping was chosen. This means more work, but the results are by far better. Another point was to install the new control room after the wishes of the users. If they like their environment they are able to much better work. Ian Tighe says that ’the success of a system is always in the hand of the users’. He realized that the project is a PSO project where special attention for the users is needed.

6

4 Risk management

4

Risk management

The second section is about risk management. Again the subsections contain information about the theory, the way it was realized in the first two tries at the London ambulance and what in the end made the third try successful.

4.1

How it should be

The first part of risk management is to identify the risk and it’s impact on the project. If the risk is not identified the impact can not be estimated. Risk can be parted in three regions: risk that is within the control of the project manager, risk that is without the control of the project manager and legal risk that falls within criminal or civil law. Those risk categories can be further divided. Risk that is within the control of the project manager can be technical or non-technical. External risks that are without the control of the project manager can be business or insurable risks. The third kind of risk, the legal risk has a third part: tort. After the risk is identified it has to be assessed. A simple approach is to calculate the impact is to multiply likelihood and consequence of a risk. After the impact of risks is calculated (with a more qualitative then quantitative result) the risk has to be combined. There exist two approaches: a top-down approach and a bottom-up approach. The top-down approach is done by identifying the main components. A reasonable number of components would be 20. Then the risk of each component is looked at and the impact of the risk on the other components is determined. The bottom-up approach is a Monte Carlo analysis. A project model is calculated hundreds or thousands of times. Each time random values are assigned to the key parameters (within reasonable bounds). The result shows the distribution of time and cost for each parameter. With this result the critical paths can be looked at.and minimized. After minimizing one critical path the model is run again to find a new critical path. This can be done until a satisfying result is reached. Strategies for reducing risk are the following: avoidance, deflection and contingency. Avoidance is the best so it should be the goal to plan out the risk. Where elimination of risk is not possible at least it’s likelihood should be reduced. Where reduction of risk and decreasing it’s likelihood is not possible the goal should be to reduce at least the impact on other parts of the project. Deflection is the second best way of managing risk. There are two ways to deflect risk, either by passing it on to a contractor or to a insurance. Passing it on to a contractor is no good idea because by passing it on to someone else it is without the direct control of the project manager. But the risk may be parted, so every side can control the part of the risk that it can manage the best. Insuring the risk by paying money to an insurance company is a possibility for risks that can not be avoided. But in some cases it is cheaper to manage the risk alone. If the likelihood and impact are known and within borders, it’s cheaper to have a budget

7

4.2

How it was in the past

to adjust a damage. Sometimes there is no choice but to hope that an occurred risk will not be fatal. For those risks at least a recovery plan is needed that allows a fast reaction to minimize the impact after the risk occurred.

4.2

How it was in the past

There exist two different types of risks that have to be dealt. Risks that imperil the project itself and risks that endanger the going concern. Both have to be dealt by the project manager. The first to make the project itself successful, the second to ensure operabillity during the lifetime of the delivered system. The risk that made the two predecessors fail was that change and the resultant risk was not managed at all. The project manager tried to change everything in one big step. If the problem had only be technical this could have worked, but since many users with different skills were involved it was nearly sure that this could not work. Another point is that there was also a technical risk, since the system was installed and then should have worked, but it didn’t. The system was slow, and what was even worse, showed a behavior that was unpredictable. What was also dangerous for the first two projects was to pass the risk to contractors. This was caused by the financial pressure. Because of this pressure key elements had to be bought from the supplier that offered the best price. This risk could have been avoided by not only looking at the money but also at the experience of the supplier. In a project like this not spent money can be fatal to those that are dependent on the ambulance system. The second kind of risk that has to be dealt with is the risk of the system failing in production or operation. Even though a back-up control center was build it was never tested and failed when it should have ensured function. And a second risk that could have nearly be eliminated was the training of the staff. Because in the chief executive’s opinion the system could be handled by children of eight to less money was spent on training the staff, so when the first errors occurred they were overextended. They could not interpret the meaning of the error messages and therefor they could not react appropriate.

4.3

Success factors

Again the ’golden circles’ were a key factor for success. Not only that people felt save in there to develop a good functionality because they were also protected from outside influences. What was even more important is that the ’circles’ protected the outside from the changes that were made within the ’circle’. So the risk could be minimized. The whole system was not changed at once but in small steps that each itself could not endanger the whole process. It was easy to go back on step if the result was not as expected. Nearly the whole system was build at the site, so the risk was within the control of the project manager. This enables much

8

4.3

Success factors

better control and faster reaction if something unexpected happens. To minimize risk in operation the staff was trained over and over again. Only if all people feel confident with the system it can fulfills it’s purpose in a good way.

9

5 Conclusion

5

Conclusion

The central point of this assignment are the ’golden circles’. They provide good results for projects like the London ambulance despatch system. They are optimal to involve staff in the development. The staff feels that they are taken seriously. This eases the introduction of new methods and techniques if the staff has confidence that it will work because it’s designed after their wishes. The ’circles’ also reduce risk to a minimum because changes only occur in the ’circle’ while the outside is protected form the changes until a functionality that is implemented works. This method is appropriate if a running system has to be changed in operation. When the task is to build a completely new system there is no use this method. If a project is more or less purely technical nature this method will neither be advantageous. But it is the method of choice for PSO projects.

10

REFERENCES

References [1] Rodney Turner Effective Project Management [2] 999 RESCUE The Computer Bulletin October 1997

11