Minimising IT Project Management Failure

2.0 REVIEW OF EXISTING KNOWLEDGE

The following sections will provide a critical review of the research work that had been undertaken. This information is relevant to the project and most importantly is associated with the project aims and objectives. A variety of sources were analysed in order to achieve a better understanding in some of the areas considered for this research project.

2.1 Project Management

The fundamental aspect of this research is project management as it focuses on how IT project management failure can be minimised.

There are numerous definitions of project management; one definition given by (The Project Management Institute, 2009) states;

“The application of knowledge, skills, tools and technique to project activities to meet project requirements”

According to (Lewis, 1995) however, project management is the planning, scheduling, and controlling of project activities to achieve project objectives.

The first definition of project management focuses more on the soft skills of project management. The definition of soft skills given by the (Oxford Dictionary, 2010) is

“Personal attributes that enable someone to interact effectively and harmoniously with other people”

In comparison to Lewis this is more specific to what actually is required. Although Lewis’s description is not invalid, it gives a more generalised approach to project management highlighting the fundamental points. These two definitions contain different characteristics that are important to project management but what both of these definitions have in common is completion of the project requirements or activities.

To generalise project management is to apply certain personnel management skills and the application of knowledge, planning and scheduling to achieve a desired objective.

2.2 Project Methodologies and Frameworks

Yardley (2002) identifies it is overwhelming why many IT projects fail. Yardley (2002) states that if something was to fail and keep on failing then at some point there would be gradual improvements to why failure occurs so often in the particular area. Gradual improvements should have been made from the lessons learnt from the failure of IT projects over a period of time. However this has not been the case as there have been many failures in IT, with the same problems reoccurring. For example, common reasons for IT failure given by (Computer Weekly, 2010) are;

• Commencing work too early
• Ambiguous contracts
• Inadequate estimation of work
• Breaking the contract
• Lack of engagement

Al-Ahmed et al (2009) suggests that the IT industry is still young compared to other industries such as manufacturing but still attributes failure to the project management methodologies. Therefore the IT industry is still yet to formulate the needed operational standards and procedures. However as the following sections will clarify, there are “guidelines, frameworks, rules, methods” in place to counter such argument. These will be identified and critically evaluated in the following. With all these clarification in place it is overwhelming to understand the amount of failure in IT as stated by (Yardley, 2002).

2.2.1 Managing a project

Lewis (2007) in his book, Fundamentals of Project Management, gave a generalised approach to what a project contains. At each relevant step, questions are to be asked by a project manager for them to consider. Lewis gives a brief indication on these steps that are considered for managing a project as illustrated below in Fig.1

Figure 1 above illustrates a general approach to project management which consists of six main areas. The illustration identifies how the project is to be started up, planned, controlled and how the project is to close. On this basis of managing a project can seem simple enough however the accomplishment of each area is a different matter, hence the number of failures within IT. Al Neimat (2005) identifies the reason for failure is due to project management processes and the aligning of IT within the organisational structure. This view is also agreed by (Al-Ahmad et al.,2009) as project management discipline in most organisations are minimal they do not have the infrastructure to provide; education, training, or management disciplines in order to allow projects to achieve successful completion. Both these authors’ views are correct to some extent; this is because the project management processes are not followed exactly. For example, the reasons for failure as previously mentioned by (Computer Weekly, 2010) states project work is commenced too early and highlighting some do not plan the project effectively. Al-Ahmad et al (2009) view is correct to some degree. This is because some companies may not have sufficient resources to provide training and education in project management. However (Archbold, 2008) states that over the past ten years there had been a rise in interest in project management. Archbold (2008) states the reason for the rise in interest is because there are more projects then there were ten years ago. Archbold (2008) goes on to state organisations are becoming more successful and growing very quickly and recognising that staffs are managing projects without having the project manager title.

2.2.2 Project Management Body of Knowledge (PMBOK)

The PMBOK guide provides the fundamental framework which is an industry standard to managing a project. Saladis and Kerzner (2009) state the real use of the PMBOK guide is to provide companies how to manage project irrespective of the characteristics. It provides the minimum knowledge that is required of a manager in order for the manager to be effective. Stackpole (2010) agrees that the PMBOK is a standard but also goes on to say it defines what is to be best practice on most of the project most of the time. The PMBOK guide is created from individuals who are affiliated with the Project Management Institute (PMI). The members of the PMI meet every few years to update and input their intellectual knowledge into the PMBOK Guide. There have been a number of guides produced over the years with the latest version in 2008.

The following sections are a brief description of the two subject areas of PMBOK which are project processes and knowledge areas adapted from (The PMBOK Guide, 2008). This is to provide managers an overview and critical review of these areas;

Project Processes

There are five main processes to the PMBOK that are used to manage projects. In comparison to the general guideline mentioned in 2.2.1 the PMBOK covers five out of the six areas already identified;

Initiating

The initiating process is where the project is defined, project sponsor is on board, project manager, the team and the requirements are identified.

Planning

Times scales are drawn up, scope of the project is defined in detail, risks and resources are also identified.

Executing

The team executes the work that needs to be done in order to achieve its objectives.

The project manager in this process co-ordinate the activities within the project, some of these include managing the resources and contractors.

Monitoring and Controlling

Monitoring the situation and analysing what stage it should be against the project plan. The controlling of the project is achieved by comparing what the project has achieved against what was outlined in the project plan. If it not according to plan then corrective actions is taken to bring it back to target if not going according to plan.

Closing

Ensure all objectives are met and stakeholders are happy with a review for lessons learnt for future projects.

Knowledge Areas

Project managers should also be familiar with the following knowledge areas to be considered as a professional. Each knowledge area contains a set of project management processes (Abdomerovic, 2008). Knowledge Areais aimed at promoting and sharing with some of the best scholarly literature material and available tools in the management, executive education, organizational behaviour and organizational psychology fields (Delegate Management Services, 2010).

Project Integration Management

Integration ensures that the project is planned properly, executed and controlled. The project manager must co-ordinate and integrates each activity in order to achieve the objectives of the project. Saladis and Kerzner (2009) agree with the definition given by (The PMBOK Guide, 2008) but also add the project manager must have overall vision of the project and must understand the technical as well as the human side of planning.

Project Scope Management

Schwalbe (2009) definition of project scope is to define in detail the scope or work required for the project, a view also shared by (Phillips, 2007; Nokes and Kelly, 2007). Phillips (2007) states the project manager and the project team must have clear vision of what is expected from the project. This is where one of the key components of project failure arises when people on the project team are not striving for the same goals, which includes the stakeholders of the project. However Phillips agrees with the PMBOK guide but also adds to create a scope, several inputs are required.

The PMBOK Guide (2008) defines project scope management to include the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Scope management as identified, only focuses on the output of the project and what is required to achieve the project deliverables. It does not have any concerns as to the time it takes to achieve the objectives or how much it costs (Phillips, 2007).

For example, The National Insurance Recording System (NIRS2) was to be developed to replace the previous system in 1997. However one of the underlying problems was as the project commenced it became clear the system size and project scope was bigger and more complex than originally thought. This eventually led to the delay of the system at a cost of £38 million (www.parliament.the-stationery-office.co.uk, 2010).

PMBOK identifies there to be 5 areas of project scope which are: collecting the requirements, defining the scope, creating a Work break-down structure (WBS), verifying the scope and control or monitoring the scope. WBS is the process of subdividing project deliverables and project work into smaller and more manageable tasks (The PMBOK Guide, 2008). Haugan (2002) gives a detailed explanation of WBS as follows;

“A deliverable-orientated grouping of project elements that organises and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work”

WBS allows the project manager to integrate each activity and prioritise certain tasks over others. An example of a WBS is given below in Fig. 2

Project Time Management

A schedule is developed to achieve the objectives, estimating the time for each task, determining the critical path and then controlling the work actually does happen. There are a number of project management tools that could be used to manage time. O’Conchuir (2011) identifies the simplest form of time management would be to use Milestone List which illustrate when each stage is to be completed. O’Conchuir (2011) also identifies that The Gantt Chart to be a widely used tool to display the milestones in a visual format. Figure 3 illustrates a Gantt Chart.

Marmel and Muir (2011) state the Gantt Chart was developed by Henry Gantt in 1910, however (Parviz and Anantatmula,2005; Schwalbe, 2009; www.ganttchartmac.com, 2011) state it was developed in 1917. Chiu (2010) does not specify a specific year, however states that it was developed during the First World War. Therefore it can be assumed it was produced in between the years of 1910 to 1918. The Gantt Chart is easy to understand, modify and is a simple way to depict progress status (Westcott, 2006). However as a planning tool, there are some notable limitations as described by (Springer, 2004). The limitations are that the chart is potentially subjective, interrelationships among the schedule activities are not depicted and no follow-on implications from schedule movement.

Project Cost Management

Schwalbe (2009) states project cost management includes the processes required to ensure that a project team completes a project within an approved budget. Schwalbe (2009) also states it is the project managers’ duty to satisfy stakeholders of the project as well as striving to reduce and control costs. It is here the costing of the project is calculated: this involves estimating the resources needed, staff and materials. As the project is conducted, costs are controlled and kept on track to make sure it is kept under or on budget. There have been many projects that have been completed but failed to meet the budget due to the project spiralling out of control. A notable IT project failure was the Wessex Regional Health Authority’s (WRHA) Regional Information Systems Plan (RSIP) in 1984. This project was an initiative to improve the provision of clinical and health services. It was to cost £25.8 million and be completed in five years. However the project was not even completed and abandoned with the eventual cost rising to £43 million. The reason for this high increase was because of overspending, high cost of implementation and lack of funds (Chua, 2009).

Project Quality Management

Saladis and Kerzner (2009) identifies the main objective of quality management is customer satisfaction. However (Stackpole, 2010) states quality management is applied to the project and product. Although in essence both these authors are correct, as providing quality throughout the project and the products will provide customer satisfaction. Schwalbe (2009) argues project quality management is a difficult knowledge area to define. This is because there are many definitions to quality management and the definitions are still vague. Schwalbe (2009) also identifies some that experts’ base quality on “Conformance to requirements” which means project processes and products meeting written specification. In relation to these views of the authors (The PMBOK Guide, 2008) defines project quality management as the degree to which a set of inherent characteristics fulfil requirements. Below Fig. 4 is the PMBOK guides quality management process.

The PMBOK Guide (2008) identifies managers have to grasp three aspects of quality management which includes processes and activities as shown in Fig. 4;

1) Plan Quality

Schwalbe (2009) states in the planning aspect of quality it involves identifying the standards that are relevant to the projects and how to satisfy these standards. Saladis and Kerzner (2009) agrees and identifies a few standards that can be used;

• ISO 9000/2000: The International Organisation of Standardisation (IOS) this is to provide a framework around which a quality management system can effectively be implemented www.bsi-emea.com, 2011. Saladis and Kerzner (2009) agree and explain adhering to the processes approved by the IOS will produce a consistent output.
• Six Sigma: Pyzdek and Keller (2009) define six sigma as a rigorous, focused, highly effective implementation of proven quality principles and techniques. Its aim is to have virtually error-free business performance. Saladis and Kerzner (2009) state the methodology for meeting these performance levels is to follow a procedure referred to as DMAIC: define, measure, analyse, improve, control.
• Total Quality Management (TQM): a comprehensive and integrated way of managing any organisation to meet the needs of customers consistently and continuous improvement in every aspect of the organisations activities (Evans et al.,1996). It is an approach where everyone is responsible for quality. It is designed to enable an organisation to gain competitive advantage by striving to meet 100% customer satisfaction (Yardley, 2002)

2) Perform Quality Assurance

The PMBOK Guide (2008) defines quality assurance as the process of regularly evaluating the overall performance of the project to ensure the project will satisfy quality standards. Francis and Horine (2003) agree and explain quality assurance involves making sure everything is done correctly and fulfils the requirements of the project.

3) Perform Quality Control

Monitoring and recording the results to see if they meet the requirements (The PMBOK Guide, 2008). This is to be achieved by statistical process control and Pareto analysis as stated by (Barkley and Saylor, 2001) and identify that this an important factor of quality even though these tools are inspection based. For example in 1992 BAE Automated System was awarded a $175.6 million contract by the city of Denver to build an airport with an integrated baggage handling system for the new Denver International Airport (DIA). This system was supposed to route and deliver luggage in the airport using unmanned carts. However it was a catastrophic failure due to the following reasons as stated by (Chua, 2009);

• One of the reasons for failure was the sheer expanse of the DIA it was twice the size of Manhattan, New York.
• Overly ambitious, as it was asked to be built in one year, but was estimated to take four years.
• No experience of dealing with such a large project,
• Conflicts with contractors,
• Poor management of user expectation,
• Continuous changes.

Eventual cost was close to $2 billion over budget and sixteen months behind schedule. This example stipulates the importance of having quality aspects imbedded into the project. The project should have followed some quality guidelines such as TQM where this approach identifies everyone responsible for the quality.

Project Human Resource Management

Identifying the personnel needed to do the job by giving their roles and responsibilities within the team, managing and motivating that team. Also the identification of key stakeholders within the project is made here.

Project Communications Management

Communication is vital to any project; (The PMBOK Guide, 2008) acknowledges that the communication knowledge area involves planning and disseminating information relevant to the project.

Project Risk Management

Kerzner (2009) defines risk management as the act or practise of dealing with risk. This includes planning for risk, identifying potential project risk, analysing and prioritising risk, developing risk response strategies and monitoring and controlling risks to determine how they have changed. Dinsmore et al (2010) agrees and makes a valid point identifying that all projects will have a certain element of risk. This is because no two projects are the same as some are characterized by the following: Uniqueness, Complexity, Change, Assumptions, Constraints, Dependencies and most importantly People.

Project Procurement Management

Determining which goods and services are necessary for the project and how they are to be acquired.

The PMBOK provides a great platform for understand how to manage a project. The PMBOK is a framework that covers proven techniques and practices given by existing project managers. The framework is used in major organisation such as Fujitsu and Boeing Aircraft (Blokdijk, 2008). It is more associated as knowledge based framework as it identifies “What” the project might require rather than “How” to manage a project. It does not show in great detail exactly how to go about managing a project which is why it is mentioned also as a framework and more as a guideline. The reason for identifying the method as knowledge based is because every few years PMI meet to update and input their intellectual knowledge. This can be an advantage as members input the knowledge of successful proven practices needed to manage the life-cycle of a project. For each process it outlines which necessary tools and techniques are needed. The PMBOK however has its disadvantages; PMBOK points out human resource management as important but fails to miss out the need to document the processes. The reason why it is a disadvantage is because by not documenting the process, it fails to provide information for anyone else to come into the project at a later date, or when re-evaluating the project at the end why such action was taken or needs to be taken. Another disadvantage is it provides minimal amount of coverage of various project management techniques such as WBS or Gantt Chart. Managers would therefore need to consult specialised texts to grasp the subject further. It is also complex for smaller projects and has to be adapted specifically to the industry area (www.theprojectmanagement.com, 2008).

2.2.3 PRINCE2 Methodology

Hedeman et al (2010) identifies PRINCE2 as an acronym for PRoject IN Controlled Environments and is a structured method for managing projects. Hedeman et al (2010) also states that PRINCE2 is a de facto standard that is used by the United Kingdom (UK) Government and is widely recognised in the private sector. Van Bon and Verheijen (2006) also agree the PRINCE2 methodology as a de facto standard in the UK and widely used in the Netherlands and Australia. Lock (2007) identifies that the PRINCE2 methodology was at first intended for use on IT projects, however it has since emerged to be effective in any given project. PRINCE2 is a set of activities to achieve its business product with the organisation structure defining responsibilities to manage the project.

PRINCE was established and launched in 1989 and was based on an earlier model called PROMPT; PRINCE took over from PROMT within Government projects. PRINCE2 was published in 1996 and is the trade mark of the Office of Government Commerce (OGC)

PRINCE2 Process Model

In the following section is a brief overview of the process model which has been summarised from the (Managing Successful Project with PRINCE2, Office of Government Commerce, 2002)

The PRINCE2 Process model consists of a number of distinctive management processes. Graham (2010) states most people fall into the trap of following this model exactly as a standard approach. It is therefore in the best interest of the project manager not to blindly follow the exact approach stated in the model. Depending on the experience of the project manager and what the project needs elements of the model can be taken and applied to a particular project. Figure 5 shows the different levels of management;

Directing a Project (DP)

DP is aimed at the Project Board: the board manage and monitor the projects by reports and controls through a number of decision points. Key decision points are initiating the project on the right track, commitment of more resources after checking results and project closure. This process does not cover the day to day activities of the project manager.

Starting up a Project (SU)

A pre-project process designed to ensure the basic elements are in place. In this process the project team is assembled and a project brief is prepared. This process also brings out the Project Mandate which defines the reason for the project and what the outcome is to be.

Initiating a Project (IP)

The team decides whether it is feasible for them to proceed with the project and if feasible then a business Case is produced. Other key activities here are setting up project files, encouraging the Project Board to take ownership of the project, assembling the Project Initiation Document (PID), ensuring the investment and time required is considered wisely.

Portman (2009) identifies different steps to this process in comparison to (Managing Successful Project with PRINCE2, Office of Government Commerce, 2002). Portman (2009) focuses more on the people aspect as it states that all parties are to be aware of the product that is to be delivered, at what time, and quality aspects. Also management and responsibilities are made clear. Both these texts identify valid points which will enable a project manager to clarify what is to happen at this stage. But raises questions as to why the people aspects are not covered or examples given as it only states a large portion of documentation in the Managing Successful Project with PRINCE2. It gives indication that theory and actual practise is different.

Controlling a Stage (CS)

The Project Manager monitors and controls the day to day activities and forms the core role of the Project Manager. Other key activities include authorising, gathering progress information, reviewing stages and reporting.

Managing Product Delivery (MP)

Ensure planned products are created and delivered by the project. The process makes sure that the work is being done, ensuring that products meet quality criteria’s set. It makes sure that the work on products allocated to the team is effectively authorised and agreed. Other key activities include assessing work progress and forecasts regularly, obtaining approval for the completed products.

Managing Stage Boundaries (SB)

This process dictates what should be done towards the end of the stage. The objectives for this process are to assure the Project Board that all deliverables have been completed for the current stage plan, provide information for the Project Board to asses on whether to continue with the project or not, provide enough information to approve the current stage and authorise the start of the next stage and record any lessons to be learned for later projects.

Closing the Project (CP)

Portman (2009) states this process are the activities required to close the project and release the project manager. The project could either be the actual project end or a premature end. Objectives here are to check to see if the PID objectives or aim have been met, confirm acceptance of the product, and make recommendation for future work. Resources are freed up for allocation to other activities and prepare end project report.

Planning (PL)

Planning is a repeatable process and plays an important role in other processes. A few are mentioned below:

• Planning for an Initiation Stage
• Planning for a Project
• Planning a Stage
• Producing an Exception Plan

As previously stated PRINCE2 is the de facto standard for the UK Government and the reason for this is the attention to detail, documentation, business justification and emphasis on dividing the project into manageable and controllable stages (www.prince2.com, 2011). There are many documentation points which enable everyone to know what has happened and how they can improve for the future. Although this methodology may be unsuitable for smaller projects, elements of this methodology can be taken out such as area of control (Bentley, 2005) and implemented into managing a project. However, the question is that if this is such a widely used methodology and is the de facto standard used by the Government, then why are IT projects still failing? And why do IT projects really fail or is it just a widely used perception of IT always failing? These are some of the questions which are going to be explored as the literature review is conducted.

Analysing PRINCE2, it is evident why managers and the UK Government use this methodology. This is because it allows the manager to build on experience and the manager to be proactive and not reactive (Harris, 2010). It ensures the project process is viable to senior management (Yardley, 2002). By identifying early warning signs of potential problems and allowing proactive measures to be taken to help alleviate them. The advantages and disadvantages are identified in Table 2. The key point to consider is some project managers fail to differentiate that this is a methodology and does not need to be followed exactly to each and every point, process or technique. Project managers become too inflexible and fixed on the idea that they have to follow each and every step which can make the project long and with unnecessary processes (Charvat, 2003). Another key point regarding PRINCE2 in comparison to the Project Management Body of Knowledge (PMBOK) is the PRINCE2 misses the importance of the need of soft skills (Charvat, 2003). PRINCE2 also misses out on areas such as human resources, leadership and management techniques, health and safety. This is different to the PMBOK which focuses on soft skills such as people management.

There are numerous benefits for using a structured approach to managing a project. Below are the advantages and disadvantages given by (Office of Government Commerce (OGC), 2002) are;

2.2.4 Waterfall Methodology

The waterfall method was developed by Winston W. Royce in the 1970 and is considered to be a traditional approach. This was one of the first formal approaches for information system analysis and design as stated by (Johns, 2002; Carkenord, 2009). The method is a process followed in a sequence where a task is completed before moving on to the next in a sequential manner.

Figure 6 shows the waterfall methodology, (Rainardi, 2007) illustrates the approach of the waterfall when one task is completed after another.

The advantages and disadvantages to the waterfall methodology according to Charvat (2003) are illustrated in Table 3

Although this is for a software development or information system methodology, the same approach can be applied to a project in completing one section and then moving on to the other. The waterfall however does not always reflect on how a project is undertaken and is rarely done in such a sequential manner. However as (Charvat, 2003) identifies, it does produce a phase by phase checkpoint. This will allow the project to stay on the right track in meeting its objectives.

2.2.5 Structured Systems Analysis and Design Method (SSADM)

SSADM is a structured approach into the analysis and design of developing an