I. Introduction
This is a case study that illustrates causes of the project failure. It is a real life case study. The organisation name is a symbolic name as the actual name cannot be revealed due to the security considerations. The symbolic name for the organisation in the case study is MOX.
In 1998, MOX had a major Information Technology (IT) project to replace its old Supply System with the new one. The old Supply System did have the Year 2000 bug. MOX had three main functional divisions. In addition to these divisions, there was an IT Division that was reporting direct to the CEO office. The target date to replace the old Supply System was Nov 1999. One of the functional divisions was using the old Supply System. The other two functional divisions were not using an electronic system as they were using manual process in order to conduct there transections.
The new Supply System was to have additional functionality. A project steering committee was formulated to manage the project from the three division heads and IT division head. Furthermore, a member from each division was represented in the project team. The project coordinator was from the IT division.
As the old Supply System was supplied by the ILS limited, the management decision was to approach ILS in implementing the new system. ILS was engaged in several discussions with the IT division and representatives from the three divisions. Afterword, the scope of work was finalized and then the implementation of the new Supply System was awarded to ILS.
The project started smoothly. The ILS project team mobilised to the MOX Enterprise premises. However as MOX did not follow any project management methodology, the project issues started to appear on the surface. One of the major issues was the scope creeping that resulted from poor initiation and planning phases. There was little or no planning before deciding to get the job done. The scope of work was not detailed enough. As a result, the deliverables that ILS agreed to deliver turned out to require more work than expected. ILS did not have a full understanding of the work involved before committing. Also, the project did not have a project sponsor. The sections below discusses in details the cause of the failures and proposes the solution for each failure respectively.
II. The Lack of Project Management Methodology
There is no organization in the world that initiates a project and has an intention not to succeed. However, most of the time organizations assume project implementation tasks are operational activities that are to be undertaken in order to achieve their goals especially for those who lack project management methodology. Maylor (2010:11) in the table1 below highlighted the differences between general/operational management tasks and project management tasks.
Table 1 Project Management versus General management
General management Project management
Responsible for managing the status quo Responsible for overseeing change
Authority defined by management structure Lines of authority ‘fuzzy’
Consistent set of tasks Ever-changing set of tasks
Responsibility limited to their own function Responsibility for cross-functional activities
Works in ‘permanent’ organizational structures Operates within structures which exist for the life of the project
Tasks described as ‘maintenance’ Predominantly concerned with innovation
Main task is optimisation Main task is the resolution of conflict
Success determined by achievement of interim targets Success determined by achievement of stated end-goals
Limited set of variables Contains intrinsic uncertainties
As project management was in its infancy stage during the year 1998 in the region, most organisations did not follow a particular project management practice. Hence projects were managed as operational activities. I worked for MOX Enterprise for the period of ten years. One of the MOX core business was in the area of supply chain management. The company procured spare parts and stored them in the warehouses for its internal use.
MOX did recognise the implementation of the new Supply System as project, however, the company did not have business best practices in managing projects. Projects were assigned to the individuals based on their experience and specialisation area. For instance, if the organisation has a project in the electrical speciality, the project will be allocated to the electrical engineer and he will be the project manager for that particular project. Hence, the electrical engineer will have to execute his day-to-day operational duties and in parallel manage the project. Maylor (2010) highlighted project management for many years was considered as ‘the accidental profession – people got into it by accident’, as in the past there was no formal education on the project management field.
III. Adapting Project Management Methodology
Adapting an effective project management methodology and following its processes places the organisation in a systematic path that start with planned activities and closes with desired objectives. Not all the time organisations achieve all their desired objectives. However, most of the time following a particular project management methodology assures the organisation the accomplishment of its core objectives.
According to Maylor (2010) many organisation have tried to enhance their reoccurring operations. However, the results of improving the performance were insignificant without major investments. Therefore projects are a key source of competitiveness.
Verzuh (2008:6) mentioned that ‘As change becomes a larger component of every organisation, the ability to purposefully and powerfully direct change through solid project management is more important than ever’. It is important to note that changes and projects are sharing similar characteristics of uncertainty and complexity. In actual fact, one aspect of project is to change from a situation to another. According Project Management Institute (2009:10) ‘Projects are often utilized as a means of achieving an organisation’s strategic plan’. In that, projects are usually approved as a result of market demand, strategic opportunity, customer request, technological advance/constraint or legal requirements.
Maylor (2010) stated that the environment in which projects function may be described by the 5 Cs. The stated below 5Cs are the key ingredients for a solid project management. These 5C are as follows:
o Context ‘ the external general influences on the organisation in which the project is taking place;
o Complexity ‘ the level of difficulty or complication of a piece of work called ‘a project’;
o Completeness ‘ how much of the end requirement a project will deliver;
o Competitiveness ‘ how many other organisations will be competing to deliver that
work;
o Customer focus ‘ the expectation that customers will have their needs met by the project.
IV. Shortening Initiation and Planning Phase
The project steering committee presumed that since the implementation was awarded to ILS, it would take less time and effort to complete the project. The steering committee disregarded the fact that the three divisions operated differently. It took two weeks to finalise the initiation phase. The so called project document was created shortly. It included project executive summary, business requirements, stakeholders, benefits, schedule, and cost. The business requirements included the following high level requirements:
– Fixing Year 2000 bug.
– Implementing a common new Supply System for the tree divisions.
– Enhancing the functionality of the existing Supply System.
The project coordinator from the IT division was leading the project team. The scope statement was determined, but it did not address any operational gaps between the three divisions. After that, the planning activities commenced. A detailed project schedule was prepared by the ILS and shared with the MOX project team. The project schedule was very optimistic. The project end date was determined to be end August 1999. Moreover, the project risks (organisational risks and vendor risks) were not identified and no one cared to discuss any risks.
Project risk management commences with project management methodology that the organisation follow. Risk management begins in the early stages of project development. As the project advances through scoping and design phases, more information about the project becomes available (Gabel, 2013). Not addressing project risks from the beginning of the project, places the project in the reactive mode and hence causes project delays.
The implementation of the new Supply System did face various risks. One of the major risks was the scope creeping. The Land division and the Marine division requirements were not addressed adequately. As a result, when the implementation started, the project teams from the two divisions found significant gaps between the new system functionality and the way the two divisions do their business.
The other risk was the lack of having change management. The IT division and the implementer did not conduct any change management awareness and analysis to surface the gap between the manual system and the electronic system and then address them accordingly. As the two divisions did not have an electronic system, most of their missing requirements in the new Supply System were related to the manual way of performing their business transactions.
Therefore, the project was impacted with multiple change requests that were initiated to add the missing requirements or functionality. The Land division and the Marine division insisted in having all their requirements on board. Consequently, the project budget was exceeded and the schedule was not achieved. The implementation of the new system crossed the assigned end date of Aug 1999. Hence, the top management decided to stop the project and declare the project failure.
V. Planning is the Key Success Factor
The fundamental challenge in project management is getting it right the first time. Most of projects are associated with uniqueness, complexity, and uncertainty. Hence completing a project successfully at the first time to the scope, budget, and schedule is a mission impossible. However, obtaining accurate and organised information is the basis for the ability to overcome these seemly unbearable obstacles (Verzuh, 2008).
Furthermore, Chu, et al (2009) stated projects are often implemented under multiple constraints that could impact project successful completion. Moreover, these constraints interact and entail decisions that are to be taken in order to achieve project objectives. Indeed, managing projects provides the management of Time, Cost, and Quality effectively. These are known as the triple constraints. Most of the project management time and effort is spent in managing these constraints.
Planning is a tool on which all project activities and required resources are captured and executed accordingly. In addition, all project constraints are listed in the project plan. Planning is an ongoing process throughout the project execution. Spending an adequate amount of time in planning is the key to project success. However, shortening planning period could jeopardise the project and exposed it to various risks.
Most of the time, organisations do not see the big picture of having a complete plan ‘ plan addresses all aspects of the project management – for the project. Hence, the main focus is consumed in collecting the business requirements and a minimum effort is assigned to planning due to time constraint and organisation top management pressure. This was the case with the implementation of the new Supply System. The initiation and planning period was shortened and as a result the project suffered several obstacles and risks.
Having a well-structured planning could have avoid the mess that the MOX organisation undergone. According to Maylor (2010), the new Supply System project management plan should have included the processes depicted in the table below.
Table 2 Project Management 4-D Processes
Activity Process
Stakeholders, strategy and success D1 ‘ Define it
Initial planning
Time planning D2 ‘ Design it
Rethinking time planning: the critical chain approach
Cost and benefit planning
Stakeholders and quality
Risk and opportunities management
Project organisation: structures and teams D3 ‘ Do it
Management and leadership in projects
Control
Supply chain issues
Problem-solving and decision-making
Project completion and review D4 ‘ Develop it
Improving project performance
VI. The Absence of Stakeholders Management
As stated previously, MOX had three main divisions. The Land division was looking after ground equipment whereas the Marine Division was in-charged of maritime equipment and lastly the Air Division was responsible of handling Aerial equipment. The new Supply System project stakeholders were identified as listed below. Also, representatives from each stakeholder community were named.
– Land Division
– Marine Division
– Air Division
– IT Division
– ILS
The IT Division was dominating the project management and functional requirement management. Somehow the project was handled as an IT project. The functional divisions had a little influence on the project. Although the stakeholders were identified, but the management of the stakeholders was poor. There was no communication plan in place. The only communication that was taking place was through conducting meetings and circulating the minutes of meeting. The IT Division was under the perception that the implementation of the new Supply System alone will do the work. In fact, the change management was not addressed especially for those two division that did not have an electronic system.
The Air Division did have the old Supply System, but the system had a Year 2000 bug. Furthermore, the Air Division had requested for some system enhancements. The Air Division was treated as the functional Subject Matter Expert (SME). Mainly, the project was driven by the IT Division and the Air Division. Moreover, the project sponsor was not appointed. Indeed, the project coordinator had a limited authority on the project. All major decisions were escalated to the steering committee. As the steering committee consisted of the heads of the three divisions and IT Division, there were issues that could not be resolved via the steering committee due to the personal conflicts. In fact, there were occasions on which the CEO was involved to seek his directives on some of the project issues.
VII. Managing Stakeholders Effectively
Project stakeholders represent a challenge in managing projects. Stakeholders exert influence on project, its outcome, and the project team members (Project Management Institute, 2009). Indeed, project success depends on the stakeholders’ involvement and their contribution to the project. It has been argued that:
At time, it seems as though technology does all the heavy lifting in our economy. A closer look, however, reveals that it is always people who make the technology produce. On project, we call these movers and shakers stakeholders, because they have a stake in the project (Verzuh 2008:38).
Managing stakeholders effectively requires a constructive plan. The plan begins by identifying all project stakeholders; internally and externally. Afterward, conduct stakeholder analysis to identify potential stakeholders.
VIII. Conclusion
Maylor (2010) stated that customers do appreciate that sometime mistakes/errors occur, but what it matters is the actions that follows to rectify and manage the failure. It is those actions that make the difference. He also listed the stages that can be followed in order to manage failure as follows:
– identify that something has gone wrong;
– contain the situation ‘ accept that there is a problem, prevent further damage or
– escalation of the problem;
– put in place recovery actions to regain the customer’s confidence;
– ensure that practices are changed so that this incident does not occur again.
A. [Summarize three main points]
B. [Revisit introduction or tie all ideas together]
X. References:
Maylor, H. (2010) Project Management. 4th ed. Essex: Pearson.
Gabel, M. (2013) Project Risk Management Guidance for WSDOT Project. Washington State: Department of Transportation Administrative and Engineering Publications.
http://www.wsdot.wa.gov/publications/fulltext/cevp/projectriskmanagement.pdf
Verzuh, E. (2008) The Fast Forward MBA in Project Management. 3rd ed. New Jersey: Wiley.
Chu, M, Altwewies, D, & Preston, J (2009) Achieve PMP Exam Success. 4th ed. Florida: J.Ross Publishing.
Project Management Institute (2009) Project Management Body of Knowledge. 4th ed. Pennsylvania: Project Management Institute.