Implementation is not feasible – Many projects are over-ambitious and result in project failure.
Poor project control – Inexperienced project manager, he/she is ultimately responsible for the completion of the project and therefore it can be argued that any project failure is also the failure of the project management.
Quality and productivity play an important part in the success of an information system. Quality in terms of the purpose and measurement of what the system is intended for. Productivity relates to the potential rate of progress a project could have. This is in terms of both financial and time invested in a project and its potential return.
RECENT FAILED PROJECTS EXAMPLES
The Passport Office
In the summer of 1999 the failure of the Passport Office’s new IT system caused huge delays in the issue of passports, several hundred people were unable to travel, and phone lines were continually congested.
What went wrong?
A report on the problem blamed over-optimistic planning of the implementation of the new system. The cost of producing a passport also rose. A risk had been taken by introducing the new system in 2 of the 6 passport offices before it was properly tested.
As a result the Passport Agency descended into chaos as the new IT system was introduced and a 500,000 backlog of passport applications built up.
IT giant Siemens was in charge of the contract to produce the system, however got into trouble early on in the development of the system. (1)
The report into the failure highlighted:
• Failure to assess the time needed by staff to become familiar with new computerized systems
• Unrealistic risk assessment and insufficient contingency planning.
• A failure to communicate effectively with the public at a personal level, by phone and through the media
What were the lessons learned?
A number of the lessons indicate that closer attention to project management techniques could have mitigated the failures.
In particular, the main lessons were:
New systems must be thoroughly tested. Poor system testing led to a non-working system. Staff must be fully trained and adequate time allowed to learn new processes
Realistic contingency plans are required should the project fail to deliver on time.
A major lesson from this failure appears to be the need for contingency planning. The project took some high risk decisions without having fall-back plans. The Passport
Office had not predicted the surge in applications and enquiries and had no means of handling them.
BENEFITS CARD PAYMENT SYSTEM PROJECT
The Benefits Payment Card system was a large, complex system, linking transactions at Post Offices with the systems of the Benefits Agency and Post Office Counters Limited. In 1996 the supplier, Pathway, began implementing the new project which was responsible for the issue and distribution of payment cards and the processing of transactions and enquiries.
What went wrong?
The project was an ambitious one, probably not fully deliverable within the very tight timetable originally specified. It had special features that added to its risks; notably its status as a pioneering Private Finance Project, the need to join up the systems of two purchasers with differing business objectives, and the need for the development and testing of more new software than was originally thought(2).
The Department and Post Office Counters Ltd had different objectives for the project which led to increased tension.
The Departments initial business case did not adequately assess the risk and costs of serious slippage. When the contract was signed key parts of the detailed specification had not been finalized.
Too little time was allowed for pilot schemes and the two purchasers did not properly assess the risks involved in such a complex project.
What were the lessons learned?
A number of the lessons indicate that closer attention to project management techniques could have mitigated the failures.
Divided control. The project was run by two organisations, the Department and Post Office Counters Ltd, with different objectives. Although in theory projects can be run by two or more organisations, in practice this is a recipe for dispute and delay, which is what happened in this case. A key lesson to be learned is that it is usually better to let one purchaser take the lead with proper arrangements for information flow.
Inadequate time for specifying the requirement and piloting. A key lesson is that allowing realistic timescales for early planning and detailed specification will pay dividends in time, cost and quality;
A shared, open approach to risk management across the whole programme was not achieved. A key lesson learned is that contractual obligations must be underpinned by recognition on all sides of the need for openness about risks identified and emerging.
UNIVERSITY OF CAMBRIDGE
C.A.P.S.A PROJECT
The University of Cambridge developed a new accounting system that did not work for its first 6 weeks of operation. Several months later it was seen as ‘failing to do what it was supposed to do’, and as ‘unreliable’ as defined by Cleland(2001). This failure led to a major investigation which concluded that basic project management procedures had not been followed and that as a result the system was cancelled as it went £13m over budget.
WHAT WENT WRONG?
Overspend
The purchase of a new computer system appears to have been planned without any serious attempt to calculate the cost.
Project Management Lessons
There was a failure of budgeting for the cost of these particular project deliverables. By presenting a full business case before the project is started, a commitment to resources is obtained from stakeholders and senior management. The construction of a business case also ensures that time is allowed to fully assess costs and benefit of any proposed new system before the project gets underway.
Inadequate attention to tendering and drawing up contracts Consultants seem to have been employed without proper tendering practices being followed, and when engaged were not given written briefs.
Project Management Lessons
Roles and responsibilities need to be clearly defined. This is especially true for staff being brought in from ‘outside’ who will have little awareness of other aspects of the project.
Lack of planning of project infrastructure
Preparation for the implementation of the accounting system was disrupted when the team working on it was moved into new office space which was not yet properly equipped.
Project Management Lessons
This indicates a lack of planning of the basic tools that allow the project staff to conduct their day-to-day work. This problem also indicates of a lack of attention to ‘people’ issues including the infrastructure of the project.
Lack of contingency plans
There were no alternative procedures for administrative staff to follow when the operational system was found to be not working properly.
Project Management Lessons
This indicates a major failure of risk management. If a more phased handover had been planned, or parallel running of old and new systems held in reserve, then staff could have continued with the old system while problems were fixed in a controlled way. One of the key risks for any project is overrunning. Contingency plans for this eventuality are therefore vital for any project.
PART B: THE PROJECT ENVIRONMENT AND RISKS
Kathleen Schwalbe (2003): p6 suggests:
- The project management environment directly affects a project
- The environment affects HOW a project should be managed
- Projects are influenced by stakeholders and issues
The Project environment has two main sections known as the Internal and External Business/Project environment.
INTERNAL Environment
There are a number of issues in the internal business environment that need to be considered when assessing the risks to the project.
The three main stakeholders of a project include the owner, the technical staff and the end-user. Their involvement will ultimately determine the success of the project.
In terms of end-users their participation will include the outputs of the system both directly and indirectly. Project managers/developers view is that they are the ones that will produce and oversee the projects, finally those of whom will finance and commission the project (owners). Within this group it only requires one stakeholder to conflict with another for the project to fail.
All stakeholders will determine whether the project succeeds. End-users may not have enough input into the system and thus resulting in a poorly produced project. Developers may feel that budget and time constraints may overshadow the completion of the project, while the owners may feel that the project has exceeded its budget or may be delivered too late leaving it irrelevant.
Factors such as technological advances and changes in the business environment all affect the success of a project.
EXTERNAL Environment
When assessing the risks to the project there are a number of issues in respect of the business environment external to the organisation that need to be considered.
Is there likely to be any major governmental or political change that may occur during the development of the project, that may affect the stability of the market place, the reason for the project and the scope or content of the project.
Is there likely to be any major change in the economic environment that might occur during the development of the project that may affect the financial aspects, the market place the project provides products or services for now.
Any major change in other countries that may affect the project, including the reason for the project and the stability of the market place.
Are competitors or other organisations, which you are compared to undertaking any major new investments, reorganization or carrying out any other form of competitive edge improvement activities.
The project environment is very important in regards to a project. By understanding factors both internally and externally, only then can a project manager plan a project effectively that will not affect the completion and performance of the project system.
RISK ASSESSMENT
All projects bring with them an element of Risk. In the best-planned projects there are uncertainties and unexpected events can always occur for example project staff might leave unexpectedly, the budget might suddenly be cut or a fire or theft might affect the project progress. The majority of risks are however related to the fact that a project manager’s plan is based on estimates and they are therefore manageable. Risk management is a mechanism that allows project managers to predict and deal with events that might prevent project outcomes being delivered on time.
Identifying Risks
When identifying a new project a Risk Assessment will have to be conducted in order to manage a project without the possible effects of disruption. In order for this to happen the following questions have to be asked:
- What could possibly go wrong?
- What is the likelihood of this happening?
- How will it affect the project? and
- What can we do about it?
The sort of areas that risks are associated with includes:
-
The activities along the timeline and any threats to completion and to timescales.
-
The project components: people, equipment, infrastructure requirements, other resources.
-
Dealings with contractors and suppliers.
-
Other projects that might have an impact.
-
Organisational changes that might take place during the project.
-
Outside influences that might affect the project such as changes in funding, government policy or the requirements of a funding body.
Greatest risk often occurs where there is some sort of interface. This may be an interface between systems, departments, processes or organisations.
The assessment of likelihood of the risk occurring and potential impact if it does occur will come from the experience and knowledge of project stakeholders and others consulted during the risk analysis process. You can think of risks in terms of a matrix(see figure 1)
FIGURE 1
Your greatest effort will be focused on addressing the risks that are most likely to occur and those that will have the biggest impact if they do occur.
Managing Risks
In order to effectively manage risk it is important that each risk is allocated to an identified owner. This should be someone within the project team whose responsibility it is to keep an eye on the situation and ensure that the necessary mitigating actions are actually carried out. Responses to the initial risk assessment may include:
-
Risk Transfer – move the risk to someone more able to deal with it e.g. contract out the supply and support of the hardware infrastructure
-
Risk Deferral - alter the plan to move some activities to a later date when the risk might be lessened.
-
Risk Reduction – Either reduce the probability of the risk occurring or lessen the impact e.g. increase staffing resource on the project.
-
Risk Acceptance – Sometimes there’s not a lot you can do other than accept the risk and ensure that contingency plans are in place.
-
Risk Avoidance – Eliminate the possibility of the risk occurring e.g. use alternative resources or technologies
Managing risk is an ongoing process. The nature of the risks that are faced will alter as the project progresses e.g. staff recruitment may be a big issue at the start of a project whereas staff retention is the issue as the project draws near to an end. At the very minimum project managers should review the risk assessment and management plan at each phase boundary before moving into a new phase of the project. This would allow the project to be managed effectively throughout the system development life cycle.
An example of a risk assessment sheet can be found in the appendix.
PART C: RISK REGESTER AND DOCUMENTATION OF PROJECT RISKS
The risk register is an important part of the risk management process. It allows greater planning and control of potential risks to a project. It has many phases however the first is to store all the risks identified in previous projects so that they can be considered during the risk assessment.
This form of risk register needs to be designed to ensure that the risk is stored in an easily identifiable way for the project manager. They must hold as much supporting information as possible, including which project the risk originated from, why the risk was selected for the special consideration, the risk management actions used and the success or failure of those actions. This is vital for any project as it would allow the project manager to manage the project with the view of identifying any potential impact upon the project if a risk materializes. The supporting information could also include the number of times that the risk has been included.
Recording Risks
A Risk Register should include:
-
A description of the risk
-
The likelihood of the risk occurring
-
The potential impact of the risk
-
The risk owner
-
Details of mitigating actions to be taken
-
Identification of any early warning signs that indicate the risk is about to occur
There are many risks that can effect the system development. These include:
Inability to recruit suitably qualified staff: A risk to the development of a system may be in regards to recruiting adequate levels of qualified staff. The work load may exceed existing level of staff thus resulting in missed dead lines.
Necessary facilities not available: Not having the necessary facilities to complete the project may effect the completion of it. This will ultimately result in delay to the work of the project. This could result in not meeting the agreed deadline and ultimately having the project scrapped.
Exeeding Budget: A major risk to an IT project is the chance of not meeting budgetary levels. This will result in increased costs and ultimately leading the project to be scrapped by the owners.
Not meeting deadlines: A project that is completed late may no longer be of any use to the end-user or the owner. This needs to be avoided as it could cost the project developers a lot of time and money.
Lack of management support. Project owners tend to be passive rather than active when it comes to project success. This is a major risk to any project is the amount of involvement from those of whom are commissioning the project.
Project development has many risks that need to be overcome in order for it to be classified a success. An example of a Risk Register can be found in the appendix see figure 3.
REFERENCES
The following journals, Textbooks and newspapers were used to complete this report.
Bennit, S., Mcrobb, S., Farmer. R, 2002, Object-orientated systems analysis and design, Second edition, Glasgow: McGraw-Hill Education.
Marsh, D, 2000, The project & programme support office handbook, Volume one, Great Britain: Project Manager Today.
Cleland, D., 2001, A guide to the project management body of knowledge of 2000, Chicago: Project Management Institute.
Houstin, L., 2000, Management project procurement, Washington D.C: Primis.
Schwalbe, K., 2003, Information technology project management, London: Course technology.
Carl, S., 2000, Step by step Microsoft project 2000, Canada: Penguin Books.
, J., 2001, Benefit fraud, Computing Weekly, pg. 11.
Timmins, N., Whitehall Passports, Financial times, Dec 4 2003, pg. 4.
Morris, S., Asylum scrapped, Guardian, Feb 16 2001, pg.9.
Barnes, M., Post it benefits, The Times, Aug 14 2002, pg. 23.
Nugent, H., Benefit fiasco, The Times, Aug 16 2002, pg. 5.
