Project methodologies and frameworks

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;

Advantages	Disadvantages
Method is repeatable and teachable	Various roles and responsibilities involved enabling participants to blame each other.
Builds on experience	A lot of documentation is included which can be unsuitable for small projects.
Ensuring everyone knows what to expect	PRINCE2 does not cover people management.
Early warnings of problems	It does not cover elements of soft skills.
Being proactive not reactive
Structured method providing a standard
Widely recognised

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

Advantages	Disadvantages
Phase by phase checkpoint for the project	nly see the results later in the life cycle
May need to proceed to only the following phase after the previous phase been completed	Minimal feedback between project phases
Ensures reliability	Each phase is tracked with too many deadlines and milestones.

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 information system (Weaver et al.,2002). The approach uses a mixture of texts and diagrams during the whole life cycle of the system design and was developed by the UK Government Office of Government Commerce in the 1980's. Harrison and Petty (2002) state this approach could be applied to all system development projects for the UK Government. Harrison and Petty (2002) further reveal that 70% of British organisations use some form of SSADM. There are three different techniques that are used by SSADM:

• Logical Data Modelling - includes the process of identifying, modelling and documenting data requirements. They are separated into entities and relationships.
• Data Flow Modelling - describes how the data is moved around the company. It looks at how the data is transformed and used from one form to another and where the data is stored.
• Entity Behaviour Modelling - a process that looks at the events that affect each entity and the sequence that they occur.

Each of these techniques provides a different viewpoint of the same system. These three different techniques ensure design and analysis is done accurately. This helps to minimise potential problems that can occur further during the project.

Figure 7 illustrates the SSADM stages during a project life cycle as it shows the several stages within SSADM which are defined in the following section;

Feasibility

• This is a high level analysis where the problems are identified and looked at, whether a new system is technically or economically feasible.
• Helps to answer the question on whether a brand new system is needed or just an upgrade of the current one.

Requirement Analysis

• The analysis of the current system is undertaken.
• The current system is closely scrutinised looking at why problems occur and possible solutions to eliminate the problem.
• Questionnaire, interviews with managers and staff help to understand how the current system works and what flaws there are.

SSADM looks at the data flow of the company, how the data is stored and the processes that occur. Data Flow Diagrams (DFD) and Logical Data Modelling (LDM) are used to produce logical models of the system

The following are example of DFD and LDM in Figure 8 and 9.

Requirement Specification

Weaver et al (2002) identify this stage to be the heart of SSADM. This is where user requirements are transformed and refined into detailed and precise specification of what the system is to do. It is here the detailed functional and non-functional requirements are identified. New techniques are introduced to define the required processing and data structures. The DFD and LDM diagrams are refined and cross validated to produce the specification. Bellgran et al (2009) argue it is important to have continuous focus on requirement specification to achieve a good product and plays a vital role when developing the products.

Logical System Specification

• Technical Systems Options are considered and their Logical Designs are closely analysed.
• Identification of the hardware and software platform that are to be used are specified and what the system has to do.

Physical Design

• Physical database design and a set of program specifications are created using the logical system specification and technical system specification.

SSADM is a comprehensive waterfall-based methodology, which is complex in nature due to the vast documentation and the investment required to train staff to understand this method. It is a methodology that should occur in large-scale software development projects and must be used for any Government system development, project usually alongside PRINCE2 TM (Bocji et al, 2008; Anderson et al, 2004).

The success of SSADM is that it does not rely on one technique but three; Logical data modelling (LDM), Data flow modelling (DFD) and Entity behaviour modelling. Each of these provides a different viewpoint of the same system. The use of DFD and LDM allows users to see the system from a top down approach. It looks more closely at the processes and how they can be improved and refined. PRINCE2 TM is used in conjunction with SSADM to address the broader aspects of project management.

SSADM has well defined techniques and documentation; the high level of quality information allows cross examination of the system through the different system levels. Although this can be an advantage equally due to the amount of documents produced it can also be a disadvantage as managing these documents can be a problem. Due to the nature and the amount of work involved in SSADM it may not be suitable for some projects. SSADM in conclusion, separates the logical and physical aspects by giving three different viewpoints of the system. Although there are vast documentation stages the biggest downfall would be it will require considerable amount of investment and training in using these techniques. It is also based on a similar methodology System Development Life Cycle which is explained in the following section. As mentioned it will also be ideal to have a methodology overlooking the project management aspects as another weakness to this method is it does not cover the whole project life cycle, such as closing a project.

2.2.6 System Development Life Cycle (SDLC)

The SDLC according to (Shelly et al.,2009; Erasmus et al.,2003) is an information system development methodology which uses a series of phases which are to plan, analyse, design, implement, and support an information system. Isrd (2006) highlights it is important to understand that an information system has a life cycle just as a new product or a living system.

Figure 10 illustrate the key components within each stage. Isrd (2006) explains the various stages of the SDLC which are summarised in the following;

Identification of Users Need

An investigation is carried out to see if there is a problem or an opportunity for a system to be developed. The outcome of this stage is a statement of scope and objectives performance criteria is created.

Feasibility Study

Rob et al (2008) identifies a few questions that are to be asked at this stage such as;

• Should the existing system be used?
• Should the existing system be modified?
• Should the existing system be replaced?

Morley (2009) agrees and also explains the main output from this stage is the feasibility report. This report includes the findings to the questions posed by (Rob el al., 2008). User requirements are also identified and justification is made if the problem is worth solving or if the opportunity is worth grasping.

System Analysis

An evaluation of the existing system is carried out and what must be done to solve the problem. A logical model of the system is created, such as a data flow diagram.

System Design

Detailed design specification is created specifying how the problem is to be solved by detailing the input, output and procedures. Outcomes of this stage will involve implementation specification, schedule and cost estimates.

System Development and Testing

The coding of the system takes place and testing is done. The outcomes of this stage will involve test plans and approval from user.

Implementation

The implementation stage is where the system is phased in, run side by side or a cut of date of the old system is placed and the new system will be used. Dasgupta (2010) identifies one of the advantages of running the old system side by side is to see the results of the new system and make comparison to the old system to see if it has achieved what is was meant to achieve. The users get training to use the system, user-friendly documentation is provided and check for any last minute problems. Periodic evaluation is conducted to make sure the system is running smoothly and effectively.

SDLC as identified, is the overall process of developing an information system through a step by step process. There have been many methodologies created due to the steps and stages involved in system development. Most recognisable are the waterfall method, rapid prototyping and spiral (Simant, 2009). One of the main advantages of using the SDLC method is that it gives a structured approach (White, 2007). Below in Table 4 shows the advantages and disadvantages to the SDLC;

Advantages	Disadvantages
There is a checkpoint for each stage of the project	Inflexible to cope with changing requirements
The project is more manageable due to various stages in the life cycle.	The results can only be seen after the project is completed
Ensures reliability	Each phase is tracked with too many deadlines and milestones.
Each stage depends on the data created in that stage this provides	Not enough interactivity among the phases
Documentation is created at each stage	Possible increase in development time and cost.
Good level of user input	Often too complex and time consuming

The problem with the SDLC is that although it is one of the oldest methodologies, it does not necessarily mean it is the most reliable method in achieving project success. Although it is still being used today, it can be argued that SDLC methodology is too ridged (White, 2007) and can lack inflexibility (Rainer et al., 2008). For this reason there has been development of other methodologies such as spiral and rapid prototyping (Simant, 2009). These were created in order to manage the complexity of projects that were occurring. Another very significant criticism of the SDLC is the inability to cope with changing requirements (Rainer et al., 2008; White, 2007). It discourages changes to user requirements and does not counter the fact that changing requirements can happen at any stage of the project life cycle due to various circumstances (Rainer et al., 2008; Hausman et al., 2010). SDLC works well when quality is more important than meeting the costs (Lewis, 2008). Each stage depends on the other and uses the information created at that stage. This ensures reliability as each stage and is completed fully.

SSADM and SDLC both have strengths and weaknesses and it is up to the project manager to decide which will fit best within the organisational structure and what type of project they are managing.

2.2.7 Adaptive Project Framework (APF)

APF in comparison to PRINCE2, SDLC, SSADM and Waterfall Methodology is the most agile method (Wysocki, 2010). This is because as the name suggests, the nature of the method is to be adaptive to the ever changing business environments. The diagram below, summarises the methodology adapted from (Wysocki, 2010) and the key processes involved;

Version Scope

In this process the requirements are specified, what is needed and what will be done to meet these requirements. A Work Breakdown Structure (WBS) is created showing all the functions within the project.

Wysocki (2010) identifies in this process a Project Overview Statement (POS) is created which summarises what the problem or the opportunity is, any risks involved and any hindrance for success. Yeung et al (2006) agrees but also explain this can also be referred to as a project proposal. Yeung et al (2006) also states the document summaries the findings for approval by senior management of the organisation. Figure 12 illustrates a template for a POS;

Cycle Plan

The WBS provides the platform to which the project is to be run. From the WBS, extracts are taken that define the functionality of project. This is then broken down to task level and teams are assigned. Each team then develops a micro plan to achieve their objectives which were broken down from the WBS.

Cycle Build

Detailed planning is conducted for developing the functionalities. Cycle work is initiated whilst monitoring and adjustments are being made to the cycle build. The cycle ends when time for that phase has expired. Any functionality that has not been completed is considered for the next cycle. In this process a scope bank is created to record all change requests and improvement ideas. Also an issue log is created to keep track of all problems and track the resolution of the problem.

Customer Checkpoint

A quality review is conducted by the client and the team of the functionality that has been produced. This is compared against the overall goal of the project. Adjustments are made to the plan and the cycle if needed. The whole cycle is repeated until the time and cost budgets for this version have been expended and completed.

Post-Version Review

A review is conducted to see if the business outcomes where achieved and for lessons learned to improve the next version. Kay (2011) agrees what is said by (Wysocki, 2010) in this post-version review. But also states that review should not be just conducted at the end of the project. Kay (2011) identifies that there are two main categories to project reviews which are; ongoing reviews carried out during the life of the project and post project review.

Bolles (2002) also adds a survey should be distributed to project participants to gather their individual evaluation of the project. The survey response is then compiled and summarised in a report that is distributed and reviewed by the project team as it is used to facilitate a discussion by the project. The lessons learnt should be documented and stored on a project knowledge database for easy retrieval for future projects.

The sense of formality within this framework is nonexistent as everything within this framework is a variable. This means every possible process is subject to change due to various circumstances. Although this framework is good for a vigorous changing environment, where requirements are always changing the downfall is that projects can often take a considerable amount of time to complete and sometimes can be hard to keep track of changes. However one of the main advantages is the framework is client-focused and client-driven throughout the process (Parkinson et al, 2009). The APF addresses some of the key failures as to why IT/IS Project fail as shown in Table 5;

1. Executive Management Support

2. User involvement

3. Experienced project manager

4. Clear business objectives

5. Minimise scope

6. Standard infrastructure

7. Firm basic requirements

8. Formal methodology

9. Reliable estimates

10. Skilled staff

The highlighted is where APF addresses the issue of what projects lack. From the list APF seems to cover majority of them. It is a simple framework and shows incremental results early. Overall this framework has certain advantages and can be applied to various projects due to its adaptability and the simplicity involved. Compared to other methodologies such as PRINCE2 and SSADM it shows incremental results and does not involve a vast amount of documentation.

2.2.8 Other methodologies and frameworks

There are a number of other methodologies and framework all of which could not be covered in this project. However below is a brief summary of some of which managers need to be aware off and further investigate;

IT Infrastructure Library (ITIL); is a practical, no-nonsense approach to the identification, planning, delivery and support of IT services to the business (Arraj, 2010). ITIL is a best practise framework that has been drawn from both the public and private industry. It is similar to the PMBOK guide however the ITIL is more specific to the IT sector. It describes how IT resources are to be utilised to deliver business value. Maven (2011) compares PRINCE 2TM with ITIL and points out the difference such as PRINCE2 cannot be used to manage IT services but ITIL cannot be used to run a project. The difference is PRINCE2TM is concerned with managing an isolated change whilst ITIL is concerned with managing a continuous service. ITIL is something to consider as it provides methods to manage IT services.

Jackson System Development (JSD); is a structured system analysis and design methodology. It is a methodology that is useful in the development of large-scale software based system where the emphasis is on the software rather than the business requirements (Elliott, 2004). There are three generic stages to JSD; modelling stage, network stage and implementation stage. The approach is more process orientated then data orientated. Advantage of using JSD is its attempt to model real-world situations and to achieve this it emphasises on time and scheduling.

Yourdon Systems Method (YSM); is another structured approach which applies a top down approach to system development. There are three main stages to this method; feasibility study, essential model and implementation model. Elliott (2004) identifies emphasis is placed on modelling both the business organisation and the system at the same time. Yourdon also introduced the concept of modelling into the IS environment. This is where the designing of the software is done before coding.

2.3 Review of “Management of risk in information technology projects”

The primary data that was collected was partially based on the risks identified in the article named above which was written by (Baccarini, Salm, Love., 2004). They identified 27 risks which were the likelihood of impacting a project to fail as shown in Table 6;

Commercial and Legal Relationships

Inadequate third party performance

Litigation in protecting intellectual property

Friction between client and contractors

Economic Circumstances

Changing market conditions

Harmful competitive actions

Software no longer needed

Human Behaviour

Personnel shortfalls

Poor quality of staff

Political Circumstances

Corporate culture not supportive

Lack of executive support

Politically-motivated collection of unrelated requirement

Technology and Technical Issues

Inadequate user documentation

Application software not fit for purpose

Poor production system performance

Technical limitations of solution reached or exceeded

Incomplete requirements

Inappropriate user interface

Management Activities and Controls

Unreasonable project schedule and budget

Continuous Change to requirements by clients

Lack of agreed -to-user acceptance testing and signoff criteria

Failure to review daily progress

Lack of single point accountability

Poor leadership

Developing wrong software functionality

Lack of formal change management process

Individual Activities

Gold plating (over specification)

Unrealistic expectations (sales person over sells product)

Table 6 illustrates the risks identified in IT projects, the risks are broken down into seven categories and within these are the main risks. The research methodology used to gain the data were a combination of both purposive and snowball sampling. Both these sampling have their advantages and disadvantages, snowball sampling limitation is mentioned below. Purposive sampling allows the researcher to find suitable respondents to gather the data; these respondents are considered relevant to the research (Stommel & Wills, 2003). This is also known as selective sampling and is one of the most recognisable sampling methods in qualitative research. Babbie (2007) defines snowball sampling as a researcher collecting data on a few members of the target audience and then asks those individuals to provide information needed to locate other members of the target audience who could add value to the research. A similar approach was considered for the research of this project as will be explained in the methodology section.

Advantages

• The article provides a comprehensive list of the potential risks in IT projects.
• The list is also categorised into seven categories, in relevance to the risk which identifies which general theme has the most risks.
• The article also identifies strategies to help manage these risks however this is not in great detail as explained in the limitation.

Limitations to this article

• It provides strategies to manage the risks, however it talks about the top main five risks in IT projects and does not indicate what measures can be undertaken and which methods to adopt to help alleviate the risks. Although each project is unique and the correct measure or method will not fit all projects, it would have given an insight as to which areas to look into to alleviate the risks in IT projects.
• Snowball sampling was used to gather the data for the research. Although using this method can be an advantage, it would bring a better response rate, however it will not necessarily bring in quality data hence it being a limitation. The reason for this is when respondents get asked to recommend others, they may not necessarily tick all the parameters that the researcher would have done in purposive sampling. This could lead to the possibility of not the right respondents answering the research, as the researcher has to rely on others (Dantzker, 2005).
• Although it provides a comprehensive list of IT project risks it does however miss out a few risks such as clear business objectives, appropriate methodology adopted or underestimating the complexity of the project. These are just a few to mention but the list can be huge and more specific. The article however may have generalised some of the risks mentioned such as unreasonable project schedule and budget. This could be interpreted into not having enough resources, time, budget constraints or even loss of sponsor.
• The study was only conducted in Western Australia this is limiting itself to get a wider perception to risks in IT project failure.

Although there are a few limitations to this article, the reason why it was used to acquire primary data is because it identified 27 risks in IT projects. This as mentioned above was gathered from their literature review that the authors had researched. How these risks will be used for this research will be explained in the methodology.

2.4 Review of The Standish Group Report - CHAOS

There has been a lot of research carried out over the years analysing the reasons why IT fails. However the most important study conducted was The Standish Group Report - CHAOS, Standish Group (1995) with the latest revision of the study in 2009. The reason for the importance of the 1995 study was the scale of the study and the results that the report provided. It is also widely cited by many authors to demonstrate the problems with IT projects such as (Glass, 2005; Al Neimat, 2005; Al-Ahmed et al.,2009)

Methodology

• Respondents targeted were IT executive managers
• Sample included small, medium, large companies across major industry segments.
• Total sample size was 365 respondents and represented 8,380 applications.
• Personnel interview and focus groups were conducted to obtain qualitative data.

Definition of criteria

• Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified.
• Resolution Type 2, or project challenged: The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.
• Resolution Type 3, or project impaired: The project is cancelled at some point during the development cycle
• verall Findings
• 16% of projects were successful.
• 52.7% of projects were challenged.
• 31.1% of projects were impaired (cancelled)
• These were the overall findings which were further segmented into relevant areas.

These findings were published in 1994 and represented a view of how IT/IS project were failing. Since then, writers (Al-Ahmad et al., 2009; Al Neimat, 2005; El Enam et al., 2008; Glass, 2005; Fowler & Horan, 2007; Kappelman et al., 2006) have cited The Standish Group Report in their articles. Since 1994 The Standish Group has produced the CHOAS report every two years except for 2009 where it took three years as shown below in Table 7;

	1994	1996	1998	2000	2002	2004	2006	2009
Successful	16%	27%	26%	28%	34%	29%	35%	32%
Challenged	53%	33%	46%	49%	51%	53%	46%	44%
Failed	31%	40%	28%	23%	15%	18%	19%	24%

The figures illustrated here show that projects have improved by 16% since 1994 and projects challenged have decreased by 9% and overall failure of projects have decreased by 7%. There are variations with the findings within the years, with the lowest failure rate in 2002 with 15%. The reason to some success in some years could be due to the possible rise in interest in project management over the past ten years. Archbold (2008) states the reason for this rise is because there are more projects then there were ten years ago. Managers are becoming learned students of project management and acquiring accreditations such as PRINCE2 Practitioner or Managing Successful Programmes (MSP) as well as others.

Advantages

• It provides a strong platform regarding to the failure within IT.
• Studies are conducted on a 2 year period where information is gathered, which enables to show trends within the findings.
• Extensive amount of IT Executives are identified to provide findings.
• Large scale research
• Widely accepted as an important finding due to the results found as cited by many authors.

Criticism

The most fundamental criticism of the report is how The Standish Group defined the definitions. The definitions of criteria given by the Standish Group as explained previously do not seem to cover all possible scenarios. An example of a possible scenario would be if the project was completed on time and within budget, but had less functionalities then what was hoped to be achieved, where would this project be placed? Would it be failure, because it did not meet all objectives or success because what was produced was acceptable? The hardest aspect when defining projects is the current perception of project success and failure which will be further elaborated in the discussion section.

The data given in the report is not very clear and the figures can be misinterpreted. Analysing the report, it provided a daunting task with so many numbers and figures, therefore it is not hard to believe it could be misinterpreted. Glass (2005) stated that most cited the 1994 figures, which said that 31% of the project was cancelled, 53% were challenged and 16% were successful. What most people were doing was adding 31% and 53% equalling to 84% were deeply troubled.

Eveleens & Verhoef (2010) produced an article; The Rise and Fall of the Chaos Report Figures. In this article they argue the failure rates are unrealistic, not accurate and had meaningless figures. The authors provide justification as to why they came to such conclusions having conducted lengthy research themselves and comparing it to the CHAOS report. Oram et al (2010) also agrees and identifies according to (Moløkken-Østvold et al., 2004; Moløkken-Østvold and Jørgensen 2003) that three industrial surveys were conducted before the CHAOS report. The results they found in comparison to the figures of the CHAOS report to be high. For example, Moløkken-Østvold and Jørgensen ran their own calculation and they found out that overruns of projects should have been close to 89% not 189% as the CHAOS reports suggests. They concluded that the repost could not be trusted due to what they had found.

The Standish Group will also not disclose their data to be verified and validated further being subject to criticism (Aidane, 2010)

The overall assumption of this article is that it provides a platform to the failure within IT. Although the figures provided are debateable, one aspect which is true compared to other research studies mentioned in the introduction, is that IT projects do fail and fail in abundance.

2.5 Risk Management

Risk management is integral to managing a project; (The PMBOK Guide, 2008) defines project risk management as;

“The processes concerned with conducting risk management planning, identification, analysis, responses, and monitoring and control on a project”

Another definition given by (Australia/New Zealand Standard for Risk Management, 2004)

“The chance of something happening that will have an impact on the

Objectives. The cultures, processes and structures that are directed

towards realizing potential opportunities whilst managing adverse

effects”

The above definition gives an insight into the aspects of risk management. The PMBOK definition explains the process of what risk management is. However the Australia/NZ Standard defines risk management as the risk that impacts the project from meeting its objectives. Both these give different meanings, however they are both valid. This is because the PMBOK explains the process within the risk management whereas Australia/NZ Standard looks at it from a different perspective and notes risk as an opportunity or an effect and how external risk can affect the project. Wallace et al (2004) however argues that the definition of risk from theory and reality is different. In decision theory a risk may lead to either positive or negative consequences as Australia/New Zealand Standard defines. However managers define risk as only the negative outcome, therefore they aim to control this negative outcome. The definitions given and how risk management is practised in reality, seem to differ. Therefore in the questionnaire for this research, questions will be posed to IT managers regarding risk management and what is practised.

2.5.1 Understanding why we need to manage risks in project

Hilson (2009) states there are three distinct reasons as to why the need to manage risks in a project successfully, as the following briefly summarises;

1. Common characteristics

All projects share a range of features which introduces uncertainty. This view is agreed by (The PMBOK Guide, 2009; Dinsmore et al.,2010) as they state that there are certain similarities between projects regardless of size, complexity or industry. A number of characteristic found in all projects make them risky as shown in the following;

• Uniqueness - every project will have some elements that has not been done before
• Complexity - projects are complex in a variety of ways which includes technical, commercial, interfaces or relational.
• Assumptions and constraints - project scoping brings a range of guesses for the future.
• People - different kinds of people are involved in a project from the clients to the team members which introduce uncertainty in a project as the project is achieved by them.
• Stakeholders - Schwalbe (2009) identifies project stakeholders can be internal to the organisation, external to the organisation, directly involved in the project or simply affected by the project. They impose requirements which sometimes can be conflicting, overlapping and varying.
• Change - moving from the known present to the unknown future brings a certain uncertainty.

2. Deliberate design

Companies use projects to deliver competitive advantage over their competitors which brings a certain risk as the business exposes itself to a range of uncertainties which could affect the company. How quickly it wishes to achieve its desired aim can be done in two ways;

• To take incremental changes and seek continuous improvements. This strategy is less risky and delivers a smaller advantage at each increment.
• Alternate to this is to take a revolutionary step for innovation and make change. This strategy is more risky but potential gains are more, as the aims could be achieved more quickly.

3. External environment

The external environments pose a range of challenges and constraints to a project and have to be managed accordingly. Projects have a fixed scope which requires them to deliver the desired objectives within the ever changing environment. The factors which can introduce risk to a project can include;

• Competitor action
• Client organisational changes
• Internal organisational changes
• Political, Economical, Social, Technological, Legal, Environmental (PESTLE) factors.

2.5.2 PESTLE

According to (Basu, 2008) PESTLE is an acronym for political, economical, social, technological, legal and environmental. Basu (2008) identifies it was known as PEST analysis but some analysts added legal and environmental factors to the analysis. Canwell et al (2005) states an organisation needs to consider the following factors in Table 8, which can have an impact on their organisation or operation.

Political	To what extent does a Government intervenes in the economy. Various political factors such as tax policy and trade restrictions.
Economic	Economic factors that affect the purchasing power of the consumer and the firms cost of capital. E.g. economic growth, interest rates, exchange and inflation rates.
Social	Demographic and cultural aspects of the external macro-environment. E.g. Health consciousness, population growth rate and age distribution
Technological	Technological factors can affect the barriers to entry, outsourcing and technological shifts which can affect costs.
Legal	These factors include employment laws, antitrust law and health and safety law.
Environmental	Factors include such as weather, climate change and the growing awareness of this can affect how a company operates.

PESTLE explores the environment in which a company operates in and what different macro-environmental factors can affect the company. All these factors bring an element of risk into a project and a project manager must be aware of these factors in order to deal with them. Turner (2008) states these factors should be considered from the outset. Hopkins (2010) states the advantages and disadvantages of using PESTLE below;

Advantages

• Simple framework
• Facilitates an understanding of the wider business environment
• Encourages the development of external and strategic thinking.
• Enables the organisation to anticipate future business threats/risks and take action to avoid or minimise their impact.
• Enables an organisation to spot business opportunities and exploit them fully.

Disadvantages

• Some users over-simplify the amount of data used for decisions.
• Needs to be undertaken on a regular basis for it to be effective.
• Access to quality external data sources can be time consuming and costly.
• Pace of change makes it increasingly difficult to anticipate developments that may affect an organisation in the future.

As PESTLE identifies the potential risks externally, it is best assumed to be done in the project initiation phase and identify potential risks before the project is started. As mentioned by (Turner, 2008) identifies PESTLE factors should be considered from the outset. However as (Hopkins, 2010) states, a disadvantage is that the analysis needs to be done on a regular basis for it to be effective. This would indicate that it needs to be done at least a few times during the stages of a project. It could be costly and time consuming as it would require people from the project team identifying these risks. Hopkins (2010) also states that the PESTLE approach may be most applicable in the public sector. This is because the external factors analysed by the PESTLE approach are particularly relevant.

Hilson (2009) gave three distinct reason why risk needs to be managed; Common characteristics, Deliberate design and External environment. The most critical reason out of the three mentioned would be the deliberate design. This is because it brings a certain amount of uncertainty as to which method is chosen. However it also depends on the type of company and how the company wants to go about achieving its desired objectives. They can be bold and courageous and take great risk which could provide more gain quickly or take a cautious approach and look to a continuous improvement method with incremental changes which brings less risk to the company. This is where the problem with risk is, the relationship between risk and reward are interrelated. The more risk the company takes the more reward it is likely to achieve such as first mover advantage over its competitors, however the company is at more risk of the project failing. The three distinct reasons provide a good understanding to what risk management involves and how at each stage there are risks to be identified. As the common characteristics section provided, each project is unique in its own right and every project will have risks.

Hilson (2009) also states risk management is an important part to project management and successful projects are the ones that are managed properly. Therefore risk and projects go hand in hand however (Tesch et al., 2007) identified that most project managers perceive risk management processes and its activities as creating extra work and expense. Tesch et al (2007) identifies that risk management is the least practiced project management discipline. This is possibly one of the main reasons to project failure due to the inability of performing risk analysis to prevent project failure. Whittaker (1999) found that the main reason to IT project failure was inadequate risk management and weak project plan. The (Office of Government Commerce, 2005) also indicated that there is a lack of skills and proven approach to risk management. Wallace et al (2004) also identifies that managers fail to understand, identify and manage risk and is often cited as a major cause for IS project problems.

Reviewing the number of articles related to risk management there is a notable flaw in how risk management is undertaken, if they do so at all. The writers in this subject area seem to cite that risk management is one of the main reasons for IT failure. Due to this, primary research is to be conducted in this area of risk management, to identify why and if risk management is conducted and to what exactly is done to identify the risk.