is project success and failure - university of leeds · is project success and failure njaliwe m...

IS Project Success and Failure

Njaliwe M Banda 200229430Information Systems

April 2009

Abstract

I would like to thank my supervisor, Sarah Fores for all her assistance and encouragementthroughout the project.

I would also like to extend my Thanks to Martyn Clark, for his input and constructive criticism.

Contents

1 Introduction 4

1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Minimum Requirements & Deliverables . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Further Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background Reading 6

2.1 Success & Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Project Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2 Project Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 User Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Benefits of User Involvement . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Drawbacks of User Involvement . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Managerial Decision Making . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.1 Project Champion & Decision Making . . . . . . . . . . . . . . . . . . . . 15

2.5.2 Bounded Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Methodology 18

3.1 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1

CONTENTS 2

3.2 Methods of Data Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 Proposed Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.1 Chosen Data Capture Techniques . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2 Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.3 Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.4 Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.5 Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.6 Phase 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4 Initial Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.1 Changes to Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Findings 24

4.1 Hon. Joyce Banda, MP and the Joyce Banda Foundation . . . . . . . . . . . . . 24

4.1.1 Organisational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Systems & Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.1 Current System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 User & Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.1 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.2 User Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.3 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4 Decision Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.5 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.5.1 Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.5.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5.3 Enterprise Resource Planning(ERP) . . . . . . . . . . . . . . . . . . . . . 32

5 Evaluation 34

5.1 Success Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

A Success/Failure Profiles 40

CONTENTS 3

B Change Management Principles[16] 42

C Documents 44

Chapter 1

Introduction

1.1 Problem Statement

There has been extensive research into the causes of project failure and success in InformationSystems, most of which is based on large organisations. The question is whether these doc-umented factors are applicable in considerably smaller organisations, especially those that donot have access to all the necessary resources. This project will investigate whether the successor failure of a project in a small business can be determined accurately. This will be done byevaluating the project undertaken by the Joyce Banda Foundation, which is a primary and sec-ondary school located in Malawi, Africa. The school recently acquired a new financial systemknown as Sage Line 50, which is now commonly known as Sage Accounts 50. The intention ofthe system was to improve the efficiency and effectiveness of the running of certain processes.According to the Managing Director, the system is fulfilling its objectives in some objectivesbut lacking in others. Therefore is the project a success or a failure? Did the Foundation takeinto account all the factors of project success or failure prior to the acquisition of Sage?

1.2 Aim

The aim of this project is to investigate the processes and procedures that were undertakenby the Joyce Banda Foundation prior to the acquisition of Sage Line 50 and to determine thesuccess or failure of the implementation. And based on these findings determine whether it wasa success or failure.

4

CHAPTER 1. INTRODUCTION 5

1.3 Project Objectives

The project objectives of this investigation are to:

• Investigate the system requirements and analysis before Sage was implemented

• Investigate the success or failure of Sage, i.e. did it do all that it was set out to do?

• What could/should have been done differently

• Make a recommendation based on findings

1.4 Minimum Requirements & Deliverables

The minimum requirements of this project are to produce a report detailing my investigationof project success or failure in small businesses.

1.5 Further Enhancements

These minimum requirements could be extended by conducting an in-depth requirements anal-ysis and build a bespoke system that is unique to the Joyce Banda Foundation.

Chapter 2

Background Reading

The following chapter is a literature review to assist in gaining a better understanding of Infor-mation Systems project failure and success, and discusses some of the factors that lead to thissuccess or failure.

2.1 Success & Failure

The Standish Group conducted a survey to identify what major factors cause software projectsto fail and the key elements that can reduce this failure[1]. Their research showed that 31.1%of projects will be cancelled before implementation and 52.7% of projects cost 189% of theiroriginal estimates. Projects were classified into 3 different types[1]:

• Project Success: completed on-time and on budget with all the specified functions andfeatures.

• Project Challenged: completed and operational but over-budget and over time estimateand does not offer all of the specified requirements.

• Project Impaired: cancelled during the development cycle.

Only 16.2% of software projects are successfully completed and most challenged projects are aresult of poor requirements analysis which leads to the frequent change in required features andfunctions[1].

2.1.1 Project Failure

The following section will look at some well known case studies of project failure, discussingwhat the project goal was and highlight some of the factors that caused the project to be

6

CHAPTER 2. BACKGROUND READING 7

challenged or impaired.

Denver Airport Baggage Handling System[2]

The target objectives of the baggage handling system was to improve ground efficiency, reduceclose-out time and decrease time consuming manual sorting and handling[2]. The airport wasscheduled to open on October 31st, 1993 but was delayed 8 times and only opened on February28th, 1995. Initially federal officials authorised $60 million for the construction of the wholeairport, but over the project period the costs began to escalate and the project managementteam was forced to source funds from other sponsors. The initial cost of the project was $186million [3] which then grew at an alarming rate of $1.1 million/day due to failure to produce afully functioning system on-time[3]. Some of the causes of the project failure were[2]:

• Frequent changes in requirements from the different airlines (United Airlines and Conti-nental). During the whole development project the airlines made various changes to theirneeds and requirements which resulted, in some cases, in increased spending. One exam-ple was when Continental requested that the baggage sorting system should be added tothe system, which cost an additional $4.67million[2].

• Poor communication between the City of Denver, BAE systems and the Project Manage-ment Team. In April 1994, the City of Denver invited the reporters to watch the systemin operation without notifying BAE. The system was not ready for public display, theresult was a public disaster when reporters saw piles of clothes and personal items lyingunder the Telecar tracks.

This particular example is a challenged project because the finished product was not what wasinitially specified. Instead of an airport-wide system, three separate systems were implementedwhich cost $5.2billion which was approximately $2 billion over budget[4]. More recently, thebaggage-handling system has been described as a “money-sucking” system that by January2008 had already cost close to $700 million to maintain since implementation[5]. Currently thesystem is being removed from the airport which is costing the City more money to dismantlethe tracks.

London Ambulance Service Computer-Aided Dispatcher(LASCAD)[6]

The London Ambulance Service Computer-Aided Dispatcher(LASCAD) was implemented inOctober 1992 after a 9 month delay[6]. The objective of the system was to “automate thehuman-intensive processes of the dispatch system for ambulance services.”[6]


The system was intended to automate call-taking, resource identification and resource mobilisation[6].British Telecom(BT) would route incoming calls to the LAS headquarters where receivers wouldrecord information about the incident and the patient. The recorded information would thenbe transmitted to an allocator who would determine the patient’s location and find the closestambulances to them. Ambulance dispatchers would be shown the three closest ambulances andthey would send a message to the closest ambulance and would keep sending the message untilit was acknowledged by the ambulance crew[6].

On the day of implementation, problems began to arise when a large number of 999 callsoverwhelmed the operators, some calls and incidents went missing and lots of automaticallygenerated alerts were falsely generated. The system eventually crashed on the 4th November,1992.

Some of the reasons for failure were[6]:

• Inadequate training

• Users and the System were not ready for full implementation.

• No fall back plan

• Poor-fit between system and organisational structure

• Poor project Management

• Operational procedure over-ambitious scoping and timetable

The system failed due to factors that could have been avoided, but not addressing these factorsprior to implementation led to catastrophic consequences which included the deaths of somepatients. This is a clear indication as to why it is necessary to investigate the causes for failureto avoid similar situations in the future.

2.1.2 Project Success

According to Baccarini (1999 as cited in [7]), project success consists of two components, projectmanagement success and product success. Some believe that one without the other would con-stitute a failure but in truth they are very loosely linked because even if the project managementfails the product could still be a success[7].

Project Management Success & Product Success

Project management success focuses on the effectiveness of the organisations processes thatlead to the implementation of the new IS project[8]. Project Management Success can be bro-


ken down into three components. Firstly, a project must be delivered on-time and on budget.Secondly, the product should have the specified requirements as well as the required qualitystandard[8]. In addition to these factors of success, is the satisfaction of the stakeholders ex-pectation [7].

Product success focuses on the value the delivered system returns to the organisation once it hasbeen implemented. Once deployed there is a period of “slack” time, which is the period betweendeployment and project acceptance. Karl Wiegers(as cited in [8]), presented a graphical view ofproduct success which involves a number of stages as depicted in Figure 2.1; initial state wherethere is a decrease in productivity, process improvement begins, learning curve and improvedfuture state.

Figure 2.1: Productivity Curve[8]

Achieving Success

Research has found various re-occurring factors that cause project failure in challenged or im-paired projects such as lack of user input, incomplete/changing requirements, lack of resourcesand unrealistic expectations[1]. The Standish group investigated and documented the top 10factors of success based on their research over a cross section of businesses, the top five were[1]:

1. User Involvement


2. Executive Management Support

3. Clear Statement of Requirements

4. Proper Planning

5. Realistic Expectations

The complete list can be found in Appendix A along with tables showing what factors causedprojects to be challenged and impaired. The preceding list of success criteria will be usedto evaluate whether this particulr study was a success or a failure and ultimately determinewhether based on the size of the business this criteria is applicable.

2.2 User Involvement

The lack of user involvement has been identified as a factor of project failure by a number ofresearchers, such as The Standish Group[1] and Følstad et al[10]. Therefore there is need toidentify how user involvement affects project success or failure. This section will describe whatuser involvement is, look at ways in which users can be involved as well as the benefits anddrawbacks of user involvement.

User involvement refer to “a series of activities and behaviours performed by potential users ortheir representatives”[9]. Users can fall into 4 distinct groups dependent on how frequently theyuse the system, the type of user will determine their involvement in the Information Systemsdevelopment process[10]:

• Core users - will be the primary users of the system

• Regular users - interact with the system but it is not an essential part of their day-to-daytasks

• Sporadic users - have very little interaction with the system

• Technical users - are responsible for the maintenance and updating of the system.

Research by various individuals has indicated that the inadequate involvement of users is amajor cause of project failure[1],[10]. There are many forms of user involvement from direct orindirect, formal or informal and performed alone or shared[9]. Users can get involved by beingpart of the project management team and being part of reference groups, management teamsand workshops. Damodaran[11] describes 3 forms of user involvement:


• Informative: Users provide and/or is provided with information

• Consultive: Users comment on predefined services or a range of facilities.

• Participative: Users influence decisions relating to the whole system.

The differing forms of user involvement has its benefits as well as its drawbacks which will bedescribed below.

2.2.1 Benefits of User Involvement

The following is a list of benefits of user involvement as described by L.Damodaran [11].

• More accurate user requirements

• Avoid system features that the user does not require

• Greater system acceptance

• Better understanding of the system which will lead to its more efficient use

• Increased participation in decision-making in the organisation.

This shows the importance of user involvement, this is illustrated in the Denver Airport BaggageHandling System case study. One of the reasons of being a challenged project was the constantmodification of requirements. If all airlines were involved in the planning phase, the City ofDenver and BAE Systems would have had more accurate requirements by effective planning.

2.2.2 Drawbacks of User Involvement

The differing forms of user involvement can be viewed as a disadvantage dependent on whichform of user involvement is adopted. User involvement can include anything from informing theproject team to having a user-led design. Users can find themselves in one of 2 situations[11]:

• The Hostage Role: in this situation, user involvement is blocked by the design team wherethere is limited communication between the design team and users and users feel too ill-informed to contribute. In other words the users are included not for their input but as asource of assurance for the designers that there is some sort of user involvement when inactual fact it is merely a delusion of user involvement.


• The Propogandist Role: in this scenario the design team views user involvement as adisruption and tackles the disruption by training the users or user representatives insystem design methods, which then forces users to adopt the designers view on systemdevelopment and not contribute to the users needs.

It is therefore important to include users in the planning and design phases of the project toavoid problems from occuring post implementation which are considerably harder and moreexpensive to rectify.

2.3 Requirements Analysis

Another cause of project failure is the incomplete or changing requirements and specification. Itis therefore necessary to gather and identify all the requirements of the system because the finalproduct is dependent on how effectively these requirements are gathered and documented[12].The requirements are elicited during the Requirements Analysis phase of a methodology todetermine what the expected services of the system are and the constraints that the systemmust be able to handle[13].

Accurately identifying requirements occurs when there is effective communication and collab-oration among all the members of the project team and all the stakeholders to ensure theoptimal performance and efficiency of the product[12]. The are a number of different categoriesof requirements that must be gathered and documented:

• FunctionalFunctional Requirements are those that describe what a system does or is expected to doand has an impact on the business process. These include descriptions of the processingthat the system will be required to carry out, details of the inputs and outputs of thesystem as well as the data that it will hold.[12],[13]

The next category of requirements are non-functional requirements that are concerned withhow well the system provides the functional requirements, including the performance, efficiency,reliability and the expected volume of data.

• TechnicalThese requirements impact the product infrastructure, they identify technical constraintsor define conditions under which the product must perform. These include accessibilityof the system, strategies for data/system protection and disaster recovery.[12],[13]


• OperationalImpacting the operations and support of the system, they define the functions that oc-cur behind the scenes and keep the system operational such as system performance andresponsiveness expectations.[12]

• TransitionalThis category of requirements impacts the implementation of the system, and includerequirements such as expectations for user/technical documentation and support.[12]

• Usability RequirementsThe analysis of this type of requirements will ensure that there is a good match betweenthe system that is developed/acquired and the users and the tasks they perform. Usabil-ity ensures that these tasks are completed effectively, efficiently, comfortable and in anacceptable manner.[13]

In order to achieve this, the analyst needs to collect the following information :

• Characteristics of the users.

• The tasks they will undertake, as well as the goals they are trying to achieve.

• Situational factors that could arise in different situations.

• Acceptance criteria, which will be used to judge the delivered system.

There are various methods of requirements capture such as interviews, observation, and work-shops. Once collected, the data is subjected to analysis to eliminate duplications and contradic-tions. Once this has been completed the requirements are modeled using graphical notations,such as use case diagrams, and defined further in [14]. By collecting the information of thesevarious requirement types and users will ensure that all the benefits of user involvement arerealised.

2.4 Change Management

The introduction or modification of information systems in an organisation changes the waywork is done, where its done and causes changes in communication and collaboration[15]. TheChief Executive Officer’s main concerns are; how the workforce will react to the change, howthey can get the team to work together and how they will be able to lead their employees aswell as preserving the company values and identity and creating a culture of commitment andperformance[16]. Change Management is a technique that tackles these concerns using different


methodologies. One example of a methodology is the People Project which runs along side theIT project and ensures that the users and managers of the system understand the objectivesof the change, get the right level of support throughout the change, know exactly what willbe required of them before, during and after implementation and to lastly have the realisticexpectations of what life with the new system will be like[17]. Each methodology would notyield the same result in different companies, but most of these methodologies incorporate similarprinciples.

Jones et al[16] described the 10 principles of change management, the most relevant of which aredescribed below. The complete list of change management principles can be found in AppendixB:

1. Start at the TopIt is necessary to start at the top so that the leaders of the organisation first embrace andunderstand the changes taking place before attempting to challenge and motivate the restof the company. It is important that all the leaders across the organisation feel the sameabout the change that is to occur but each individuals opinion and reservations shouldbe considered. Once an agreement is reached amongst the leaders, that is the first steptowards a successful project.

2. Make the Formal CaseWithin the organisation there will always be a number of individuals who will question theneed for change and this particular principle allows the leadership to formally articulatethe need. There are 3 steps involved in making a formal case:

(a) Confront reality and articulate a convincing need for change

(b) Demonstrate faith that the company has a viable future and leadership to get there

(c) Provide a road map to guide behaviour and decision making

The message can be customized for various internal departments so that everyone has abetter understanding of how the change will affect them individually or as a department.

3. Create OwnershipLeaders in all areas of control or influence need to take responsibility of the changes theyare advocating, this in essence will place more confidence within the workforce. Ownershipis best created by involving people in determining the problem and designing the solutionwhich can be reinforced by incentives and rewards.

4. Address Culture ExplicitlyOnce identified the leaders need to be explicit about the culture and the underlyingbehaviours that will support the new way of doing business.


5. Prepare for the UnexpectedThere is need for the continual reassessment of the impact of the introduction of informa-tion systems to determine before hand what obstacles the organisation could face.

6. Speak to the IndividualAll individuals need to be informed of how the change will affect the way their work willchange, what is expected of them during and after then change, how they will be assessedand what success or failure will mean for those around them.

2.5 Managerial Decision Making

2.5.1 Project Champion & Decision Making

Research has indicated that one reason for project failure is poor decision making. Dove[18]states that most bad decisions are traced to the failure of value propositioning. A value propo-sition is a statement made by the Project Champion that shows the added value or benefits ofa particular product to the decision maker. A Project champion is assigned from within theorganisation and their primary aim is to win the approval of those in the organisation whocan commit funds and resources. They construct the value proposition using their personalinterpretation of the problem, the Decision Makers context, the competition and the solutionbeing championed[18]. The process of value proposition cannot begin until the decision makerbelieves there is a problem. The decision makers initial perceptions are personal interpretationsof the problem and the decision makers context. The value proposition then adds perceptionsof values, risks and trust. They attempt to show multiple benefits that stem from some featuresin the solution and each promises to add value to the organisation[18]. The decision maker isresponsible for deciding whether the specified use of the resources is justified. Simon(1960 ascited in [19]) describes four stages in the decision making process:

1. IntelligenceThis consists of identifying and understanding what the problems in the organisation are.

2. DesignThe decision maker designs possible solutions to the identified problems.

3. ChoiceThis is the simple step of making a choice between the solutions identified in the previoussection.

4. ImplementationThis is the stage where the decision maker puts the chosen decision into effect and reports


on the progress of the solution.

2.5.2 Bounded Awareness

According to Bazerman and Chugh[20] senior executives are ultimately responsible for whathappens in an organisation, but there are some questions as to the quality of the decisionsthey make. Bounded Awareness is the phenomenon that prevents people from seeing, seekingand sharing information that is relevant and easily accessible information during the decisionmaking process. Bounded awareness can occur at different points in the decision-making processand executives are not aware of how their awareness is limited. This section will look at howexecutives fail to see, seek and share information.

Failure to See Information

A useful technique in decision-making is the ability to focus on one task but this can be adisadvantage because focusing on one task limits our awareness. Executives are required tostay alert and notice all threats and opportunities that the organisation may face and this willcause the inability of the organisation to adapt their strategy or behaviour accordingly. Butpeople are still able to overlook information they are not expecting, in addition to this peopletend to overlook information if it is not a commonality, i.e. ’if something is not seen very often,you often don’t see it’ (Jeremy Wolfe as cited in[20]). Our last situation where people fail to seeinformation is when there is a gradual change occurring. Gradual change over time is harderto detect therefore noticing any irregularities or problems would be harder in this scenario.

Failure to Seek Information

This occurs when decision makers are motivated to favour a particular outcome. An example ofthis is the decision made by George Bush’s administration to invade Iraq, which was a mistake.According to [20] the Bush administration overlooked all the information that was inconsistentwith the preferred outcome. In the case of organisations, Managers make decisions based oninformation presented to them that has been put together by a project champion or an individualwho would prefer one outcome, therefore the information presented is more favourable to thatoutcome. Managers do not usually have enough time to seek further information and basedecisions on what they are presented with[20].


Failure to Use Information

In some instances, executives have access to valuable information that would assist them inmaking an informed decision, but they choose to disregard the information. Executives also havethe tendency to disregard information about their competitors. According to Don Moore[20],of the Carnegie Mellon University, he found that decision makers are able to focus on how wellto perform a task but forget to see how well their competitors can complete the same task.

Failure to Share Information

It is often seen as an advantage to work in groups made up of individuals that represent differentparts of the organisation. Members of the group discuss information that they are aware of butthey avoid sharing information that is unique because in a group situation people feel morecomfortable to discuss common information because it is received more positively accepted andothers will agree with it.[20]

Decision makers and project have to take all of these factors into account before making adecision to ensure that the best solution is chosen.

Chapter 3

Methodology

The following chapter will describe the methodology and various techniques used to tackle theproblem described in Chapter 1.

3.1 Case Studies

Case studies are a research method that allows researchers to gain a better understanding of aparticular situation, to generate a theory or test some hypotheses[21], [22]. Cases include theretrieval of qualitative or quantitative data using various methods such as interviews, surveysor observations. The collected data is then analysed by the researcher and the results arepresented[22].

The aim of this project is to determine whether IS project success or failure criteria is appli-cable in smaller organisations, a case study is the most appropriate method of completing thisproject. Case studies can either include single case/situation or involve multiple numbers ofcases and a high level of analysis[21]. This particular project focuses on one particular situationwhich can be viewed as a negative factor of case studies because it leads to researchers makinggeneralisations[23]. Because of the time constraints on this particular project, it will only focuson one case.

3.2 Methods of Data Capture

There are a number of different methods for capturing data/information, the following are themost commonly used techniques:

1. Reading Documentation

18

CHAPTER 3. METHODOLOGY 19

This is normally the initial task of the fact finding process which is used to gain anunderstanding of the organisation and its business objectives. This is done by readingdocuments such as company reports, organisational charts, policy manuals and strategicplans[13] [24]. The reading of these documents allows the analyst to prepare for other fact-finding techniques. Unfortunately in most situations, written documents do not matchreality because although they reflect the official policy of the company, processes arecompleted differently[13]. Another disadvantage of document sampling is that there is alarge quantity of documentation and it is often out of date[24].

2. InterviewsThis is the most widely used technique for determining requirements but is possibly theone that requires the most skill and sensitivity[13]. Conducted by the analyst, interviewscan be used to gather information about the main objectives of the organisation fromthe Managers and gather information about the information system from the staff andcustomers. It is necessary for the interviewee to set clear, achievable objectives of whatthey expect from each interview and all interviewees need to be carefully selected to ensurethat the right information is gathered from the right people[14].

3. ObservationThis technique is the observation of the way people carry out their work in a naturalsetting and identifying inefficiencies in the way work is done.[24] This technique is essen-tial for gathering quantitative data and verify or disprove assertions made by interviews.The main advantages of this technique are that it provides the analyst with first handexperience, the data collected is collected in real time and provide baseline data aboutthe performance of the existing system and of the users. In addition to this observa-tion provides a dynamic rather than static view of the business situation. On the otherhand, people tend to behave differently when being observed which could lead to incorrectinformation, this is known as the ’Hawthorne Effect’[24]. Another disadvantage of thistechnique is that ethical problems may arise when employees are dealing with sensitive orprivate data.[13]

4. Sampling of DocumentsDocument sampling can be completed in 2 ways[13]:

• Completed during interviews or observation, when the analyst collects completed orblank documents. This provides the analyst with more information about the dataused, the inputs to and outputs from the tasks they carry out.

• The analyst carries out a statistical analysis of documents in order to find out aboutthe patterns of data. This method is appropriate where large volumes of data arebeing processed.


This technique is used to gather quantitative data and can be used to find error rates inpaper documents. One drawback of this technique is that some documentation may beout of date and may not reflect the appropriate information. The information collectedmay be modeled using Class diagrams and Entity-relationship diagrams[13].

5. QuestionnairesThis research instrument consists of a series of questions to gather information. Question-naires are created with various types of questions[13]:

• Range Questions: Closed questions that give respondents a choice of answers, suchas True/False.

• Multiple Choice Questions: Provides more choices than range questions.

• Scaled Questions: These questions provide the respondents with a scale to answerquestions. For example, providing options from Strongly agree to Strongly disagree.

• Open Questions: These questions are left open when the response involves an ele-ment of subjectivity.

This is an economical way of gathering data and if well designed, could be easily anal-ysed. Unfortunately, good questionnaires are hard to construct and there is no automaticmechanism for follow-up or probing.[13]

These five techniques are the most commonly used methods of requirements capture but morerecently there has been as introduction of modern techniques such as prototyping, brainstorm-ing, and Joint Application Development[14].

3.3 Proposed Methodology

3.3.1 Chosen Data Capture Techniques

The primary fact-finding technique used in this investigation shall be interviews, as mentionedpreviously, interviews are the most-widely used method which requires careful planning andappropriate conduct. When planning for the interview it is important to have a clear objectiveto identify what the interviewer is attempting to achieve at the end of the interview and identifythe topics that are to be covered in the interview. Choosing the appropriate interview subjectsis an important aspect of the planning because by choosing the wrong subjects could lead to theretrieval of inappropriate information. Lastly is it important to plan how the interviews are tobe conducted and the types of questions used. There are two types of interview questions; open


or closed, and the combination of the two ensures that the interview captures the maximuminformation.[24]:

• Closed Questions: This is a useful approach for quantitative analysis and gives the inter-viewee a restricted choice of answers such as yes or no, or scaled questions which allowthe interviewee to give their opinions based on a certain scale (e.g. - ’Strongly Agree’ to’Strongly Disagree’)

• Open Questions: These questions are more appropriate for retrieving qualitative datawhen the interviewee is asked for their opinions or ideas.

The combination of open and closed questions ensures that maximum information is retrieved.During the interview, the interviewer must establish a control framework for the interview. Itis also important that the interviewers are good listeners especially when discussing complexbusiness processes or technologies. There are numerous ways of recording information suchas taking notes, drawing diagrams or tape recording which ensures that no information isoverlooked.

Before conducting the interviews, all participants were to sign a form of consent to ensure thatthe users were aware that all information gathered would be documented and printed, pleasesee Appendix C.

The following sections will be a phase by phase description of the methodology. Most of themethodology involves face-to-face interaction with the users and the system and will requiretraveling to Malawi.

3.3.2 Phase 1

Phase 1 was the initial data-gathering stage which included a meeting with the Managing Di-rector,Mr. Roy Kachale, to retrieve background information on the Foundation, the previousand current system. During the meeting the Managing Director provided documentation andsources of information to gain a better understanding of the Foundation. Mr. Kachale brieflydescribed the system that was in place prior to the implementation of Sage and a brief de-scription of why he believes the current system is inadequate. Thereafter determining the mainobjectives of the interviews and the subjects to be interviewed.

The subjects of the interviews were the main users of the system, which does include Mr.Kachale. The interviews main objective was to determine how involved the users were in theproject before and after the implementation and determine how and what decisions were madeprior to implementation.


3.3.3 Phase 2

Phase 2 involved the interviews of the users and the Managing Director. All interviews werestructured similarly but altered during the interview based on the responses to each section.

Interview Structure

All interviews were structured in the same format, the questions were split into 3 different sec-tions, to try and determine to what extent the users were involved with the system, determine ifthe users were involved and whether the system is appropriate or inappropriate. The interviewswere structured in the following way:

• The first set of questions were used to gather some background information about theusers and to verify their role in the organisation and how they interact with the system.

• The next set of questions were used to establish the users involvement in the decisionmaking process and how much training was involved prior to implementation.

• The last set of questions were used to get the users opinion about the current system

Mr. Kachale’s interview did not include the first set of questions because these were questionsthat were to be answered in the initial meeting. The main focus for the interview was todetermine the decision process that led to the procurement of Sage Line 50. Please see AppendixC for a copy of the initial interviews.

3.3.4 Phase 3

This stage of the methodology would involve the observation data capturing technique to viewthe following:

• observing how users interacted with the system when a parent/guardian came to the officeto pay a students tuition

• observing other ways the system was used

• a step-by-step run though of the system from one of the users

3.3.5 Phase 4

The final stage of the methodology is to clarify any points made during the interviews, obser-vations and documents collected during the interviews.


3.3.6 Phase 5

The final stage of the methodology shall include an evaluation of the data collected and deter-mine whether the project was a failure or a success.

3.4 Initial Schedule

The following diagram shows the initial schedule for completing this investigation, where theblack dots refer to project milestones:

Figure 3.1: Initial Project Schedule

3.4.1 Changes to Methodology

Most of the Methodology remained unchanged but in Phase 4, an additional stakeholder wasinterviewed for clarification, the representative and the Chairman of the Board, Chief JusticeBanda, SC. Who was able to clarify some ambiguity from the interviews conducted in Phase 2.

Chapter 4

Findings

4.1 Hon. Joyce Banda, MP and the Joyce Banda Foundation

Hon. Mrs Joyce Banda, MP, is the current Minister of Foreign Affairs and International Cor-poration of Malawi which is a small country in south east Africa. Hon. Banda is a politician,business woman and a community activist whose mission in life is, "To assist women and youthgain social and political empowerment through business and education" [26]. She has achievedthis in a number of ways; one example is the establishment of National Association of BusinessWomen (NABW) which has mobilized 15, 000 women and trained 12, 000 to run their ownbusinesses [27]. Her work has seen her receive national and international recognition[28]. Onesuch award was the prestigious "Africa Prize for Leadership for the Sustainable End of Hunger"from The Hunger Project which she won in 1997. The award "honors a distinguished Africanman or woman who has exhibited exceptional leadership in bringing about the sustainable endof hunger at the national, regional or continent-wide level" [29]. Hon. Banda shared this awardwith then President of Mozambique, His Excellency Joaquim Chissano. The laureates of theaward were awarded $50, 000 each. Hon. Joyce Banda used her winnings to establish the JoyceBanda Foundation (JBF) [30].

The JBF Girls Secondary School was established in 1998. Over the last 10 years, the Foundationhas seen a lot of growth; it is now a co-ed primary and secondary school and has a ruralcentre in Hon. Banda’s hometown which provides free primary and secondary education and anintegrated rural programme that provides training for various activities such as crop farming,carpentry and carpet weaving as a way for the local community to gain economic and socialempowerment.[26]

24

CHAPTER 4. FINDINGS 25

4.1.1 Organisational Structure

The Joyce Banda Foundation is a family run business, the Board of directors is Chaired by theFounders’ husband, Chief Justice R.A Banda, SC and is comprised of 5 of their children with avariety of educational backgrounds. The Managing Director, Mr. Kachale is also a member ofthe Board. Below is a diagram illustrating the organisational structure.

Figure 4.1: Organisational Structure of the Joyce Banda Foundation[26]

4.2 Systems & Technology

4.2.1 Current System

Before the current system was introduced, all of the administration and accounting was paper-based excluding the use of Microsoft Excel for formulas and calculations. The current infor-mation system combines a paper based administration system and a computerised financial


software system. When a student registers a paper based registration form is filled out andfiled away in the administration office. A copy of which can be found in Appendix B. If anystudent information such as medical history and contact details are required, the files have to bemanually searched. This becomes problematic because the information is not easily accessibleand it becomes time consuming to peruse through 700 student files.

Once filed, a few weeks into term the Accounts office will clarify which of the registered studentsare actually attending classes. Once this has been done the Data Entry Clerk enters the requiredaccounting information into Sage.

Figure 4.2: Data Flow Diagram for the Joyce Banda Foundation

Sage

Sage Group Plc is a leading supplier of business software that provides services such as payrollsystems, customer relationship management (CRM) and e-businesses [30]. The Joyce BandaFoundation use Sage Line 50 version 11, which is a financial tool to assist small business ac-counting by managing all processes and provides accurate reports for managerial use[31]. Atthe Joyce Banda Foundation, Sage is also used to keep all budgetary and spending information.

According to the Managing Director , Sage is inadequate in the case of student information andaccounts but adequate in producing financial statements and storing budgetary information. Itonly takes a limited amount of student information, it takes the student as a customer/debtorand the account number is used as a student ID as shown in Figure 4.3.

The inadequacy of the system is based on a number of problems:

• Students are treated as customers/debtors

• Each record has to be manually changed at the start of the year to reflect changes inclass and student type (day, border, sponsored) among other factors. The increase in thenumber of students, has made this task very time-consuming and because of this, therecords remain unchanged.


• According to Mr. Kachale, Sage only stores a limited amount of information and does notstore all student information such as contact details and class performance.

• Sage does not automatically print receipts, therefore receipts have to be hand written, ablank copy of the receipt can be found in appendix B.

This raises the question as to whether the implementation of Sage was the correct choice ofsystem.

Figure 4.3: Sage Interface

Requirements Analysis

Mr. Kachale admitted that there was no requirements analysis done prior to the purchase.When he realised there was a need to move away from the manual system, he recommendedSage based on his own perception of the problem and his accounting educational background.

“...As the school grew, it was no longer practical to use the manual accounting


system. I was educated in America and was very familiar with the Sage accountingpackage and therefore recommended it” - Roy Kachale

The system appears to have dealt with the accounting problem but not the student informationwhen Mr. Kachale was interviewed he admitted that at the time his main focus was to dealwith the accounting department and not the ’big picture’.

4.3 User & Training

4.3.1 Users

The main users of the system are and are all core users of the system because they are theprimary users of the system:

• Managing Director - Mr. Roy KachaleMr. Kachale has worked for the JBF for 5 years when he returned from the USA andtook over as the Managing Director. His main interaction with the system is to monitorexpenses and produce financial statements for the Board of Directors.

• Accountant - Mr. David KapakasaMr. Kapakasa has been an employee at the Foundation for over a year, he was hired be-cause of his experience with the system. His main duties include verifying updated recordsentered by his colleagues, monitoring expenses and advising Management of departuresfrom the budget.

• Assistant Accountant - Mr. Kondwani KabowaMr. Kabowa has worked for the foundation for 3 years and was initially hired as a bursarand now works under Mr. Kapakasa as his assistant. He handles all the cash - recievingpayments, banking, as well as entering data into the system.

• Data Entry Clerk - Mr. P MtengoMr. Mtengo has been at the JBF for 7 years and started as an office assistant and is nowthe data entry clerk assisting his colleagues entering data into Sage and completing anyother tasks that he is delegated.

4.3.2 User Involvement

It was concluded that the users were not involved in any kind involvement and most decisionswere made by Management and did not involve, Mr, Kapakasa, Mr, Kabowa and Mr. Mtengo.


4.3.3 Training

Of the 4 users, Mr. Kabowa and Mr. Mtengo were not as technologically conversant and hadno prior experience with any computerised accounting systems. Mr. Kachale was trained bya local Malawian company known as Globe Computer Solutions Ltd. Mr. Kachale paid K10,000 (K=Kwacha - the local currency), which is equivalent to approximately £40 for a two-day training session. Thereafter, with Mr. Kachale’s acquired knowledge and Mr. Kapakasa’sexperience they were able to train the other users to use the system. Both Mr. Kabowa and Mr.Mtengo said they felt the training they received was adequate and they learnt all the techniquesrequired for them to complete their tasks.

“After I was trained by the Managing Director, I found it simple to use and enjoyusing it” - Kondwani Kabowa

“Once we were trained, it was very easy to use” - Patrick Mtengo

4.4 Decision Process

This section will discuss what the decision process was prior to acquiring the system. When Mr.Kachale took over as the Managing Director, he realised that the manual system was no longerappropriate because there were too many transactions as the number of students had increased.He became the Project Champion, and created the value proposition highlighting the benefitsof using Sage and presented his recommendation for the system to the Board. There was noformal decision process followed.

The decision process was clouded by bounded awareness in a number of ways. Firstly, priorto purchasing Sage, The Managing Director was aware that other local institutions were usingQuickbooks, which is a similar accounting system and none of them were using Sage at the time.But the Managing Director failed to seek and use available information about the either systemto determine which was the better option because of his preference was to acquire Sage. TheManaging Director failed to see that the system would only solve the problem in the accountsdepartment. And lastly, according to the Chairman of the Board, the Board was presented withinformation about Sage and were not provided with information about any alternatives so theBoard were unable to make an objective decision.


4.5 Recommendations

The following section will describe some tasks that could have been completed to ensure asuccessful project.

4.5.1 Methodologies

It is apparent from this investigation there was no formal procedure that was followed. Thefollowing section describes some popular Information System project methodologies that couldhave been conducted by the Foundation to determine the most appropriate solution.

• Systems Development Life Cycle(SDLC)The Systems Development Life Cycle (SDLC) is also referred to as, ’traditional systemsanalysis’, ’conventional systems analysis’ or the ’waterfall model’ which is a term usedin the United States of America[11]. There are many variants of the methodology butthe basic approach involves six stages:- Feasibility Study, System Investigation, SystemsAnalysis,Systems Design, Implementation and Review and Maintenance. According toCadle[14] the approach is not very effective because of the lack of user involvement anduses a text-based approach in documenting all the findings, as opposed to a diagrammaticone.

• Soft Systems Method (SSM)This approach is technically outside the scope of information systems development but isimportant because it looks at the cultural, human and organisational dimensions which canbe useful to the project manager [14]. SSM identifies real-world situations and proceedsto identify the problems and suitable solutions.

– The ’Problem situation’ is stated

– Root definitions are collected and explored to find out what people believe aboutthe system

– Conceptual models are built showing what a human activity system would look likeif built from each model.

– Conceptual models are compared and discussed until one model is agreed on.

– Real world constraints such as time and cost are considered to see what changes aredesirable and feasible.

– Actions are implemented to generate change


This is a great approach to use in the early stages of the projects when the requirementsare not clear. This would be an ideal methodology to get an understanding of the JoyceBanda Foundation and the problems it is facing.

Structured Systems Analysis and Design Method (SSADM)SSADM is a data-driven methodology and concentrates on data modeling. It is a 5 phasemethodology that has its own set of plans, timescales, controls and monitoring procedures andcan be broken down into a number of stages[11]. SSADM is an intensive and complicatedmethodology. It requires a substantial amount of learning and a small team of leaders todistribute the work and keep track of all the processes and documentation. This approachwould be more affective in a larger organisation, the Joyce Banda Foundation project is a smallproject that is influenced by only a small number of users.**

4.5.2 Options

Bespoke vs Off-The-Shelf

Determining which is better; bespoke systems or off-the-shelf software is an important aspectof information systems development that should be considered once the requirements have beendetermined. This section will look at the two systems objectively by looking at the advantagesand disadvantages of each.

• Off-The-ShelfOff-the-shelf systems are produced to meet the perceived needs of a particular marketor sector[32]. They have a set of generic features that can be used across the sector forexample, Microsoft Office, which can be used over a number of different sectors/markets.

Off-the-shelf systems are relatively cheap, but these low prices are possible because the costof development can be spread over the large user base. The availability of the software at alow price is the result of mass-marketing and the large user base in certain markets/sectorshaving access to the same software. Because of this reason, service providers cannot chargeexcessive amounts for the software and there is no competitive advantage for having thesoftware. It is a sophisticated, complex piece of software that is built on the knowledgeof many users which could be problematic because of the difficulty of understanding allthe functional processes provided. There is a high availability of support and literatureavailable but the system provider is not as concerned with dealing with specific problemsthat a customer may face, and any requests made by such customers will not carry much


weight when there are a very large number of users[33].

Bray[32] also indicates that off-the-shelf systems can be limited in terms of performance,some businesses may find themselves working around the system to accommodate all theirbusiness processes instead of the software working around them. In addition to this mostoff-the-shelf systems are not used to their full capacity because each company will onlyuse some of the functions provided[33].

• BespokeBespoke systems are tailor-made applications that are tailored to the exact requirementsof the company providing a fully integrated system that meets the company’s key busi-ness objectives[32]. An advantage of using a Bespoke system is the scalability of it, itaccommodates growth and contract of business as it evolves[32].

Users usually find it is easier to use a bespoke system because it does not contain all theunnecessary facilities and has better support because it is easier to communicate with thedeveloper of the system. Off-the-shelf systems are developed by large corporations thatare not urgently concerned with a specific problem a user may have.

The main reason companies do not choose a Bespoke system is because the cost of thesoftware is much higher than packaged software[33]. This is because they require moreresources to develop these systems and require more manpower and time. Lastly, thedeveloper can only match the requirements of the customer to the extent that the customercan define them and be understood by the developer[32]. It is therefore very importantto have a detailed requirements specification before a decision is made.

4.5.3 Enterprise Resource Planning(ERP)

Enterprise Resource Planning is a software solution that, “integrates the complete range ofbusiness’s processes and function in order to present a holistic view of the business from a singleinformation and IT architecture”[?]. It can be viewed from a variety of perspectives:

• As a commodity/product in the form of computer software

• As a development objective of mapping all processes and data of an enterprise into acomprehensive integrative structure

• A key element of an infrastructure that delivers a solution to business


Although there have been differing opinions on the nature and definition of ERP. ERP is a costeffective and competitive necessity that has been adopted by large organisations and more smalland medium sized organisations are following suit.

In order for software to be considered as a ERP, it must provide an organisation with function-ality for two or more systems. There are 3 forms of ERP programs:

• Generic: targets a range of industries and must be configured before it can be used.

• Pre-Configured Templates: templates that are tailored towards specific industry sectorsor companies of a certain size.

• Operational Installation: this occurs when the generic or pre-configured package has beenindividualised according to the particular firm’s requirements on site.

There are a number of advantages and disadvantages of using ERP some of which will be listedbelow:

Advantages

• A totally integrated system

• The ability to streamline different processes and workflow

• The ability to easily share data across various departments in an organisation

• Improved efficiency and productivity levels

• Better tracking and forecasting

• Lower costs

• Improved customer service

Disadvantages

• Customization in many situations islimited

• The need to reengineer business processes

• ERP systems can be cost prohibitive to install and run

• Technical support can be choddy

• ERP’s may be too rigid for specific organisations that are either new or want to move ina new direction in the near future.

Chapter 5

Evaluation

The following chapter will evaluate whether the IS project undertaken by the Joyce BandaFoundation was a success or failure beased on project success criteria published by the StandishGroup in the Chaos report[1].

The Chaos report was published in January 1995 and later that year, the Standish Groupinvited 60 IT professionals for a 3 day conference to break down their success criteria into morelevels of detail[34]. Each criterion was given was given five factors as to why it is important,thereafter it was converted into question form and the answers ’yes’ and ’no’ were awarded adifferent score. Once each factor has been evaluated, a score between 0-100 will be producedand would determine the project’s potential for success.

5.1 Success Criteria

The following chapter will evaluate whether the project was a success or failure based on the suc-cess criteria documented by The Standish Group [1],[34]. Describing the 5 factors for potentialsuccess and determine whether the Foundation followed the issues raised.

1. User Involvement

• Find the right users

• Involve the users early and often

• Establish a relationship with the user by keeping a line of communication throughoutthe project.

• Make it easy for them to be involved

34

CHAPTER 5. EVALUATION 35

• Talk to the users and ind out what they need

2. Executive Management Support

• Find a key executive with a vested interest in the successful outcome of the project

• The key executive must have a bottom line responsibility to his/her career

• The consequence of Failure is acceptable

• Show the key executives a well defined plan

• Show the project team has a stake in project success

3. Clear Statement of Requirements

• Write a concise definition of the vision in the short, mid and long term

• Write a functional cross-section analysis and allow re-iteration

• Develop a functional risk assessment and management document

• Develop a business case statement outlining return on investment

• Define metrics, measurements, and milestones to determine success and/or comple-tion of the project

4. Proper Planning

• Develop a brief formal problem or concept statement that describes the problem andresulting benefit to the organisation.

• Write a requirements definition or concept solution document

• Identify the proper personnel

• Develop a firm functional specification that allows for changing business require-ments

• Develop a project plan with attainable goals

5. Realistic Expectations

• Write a firm and clear specification document

• Prioritise project needs

CHAPTER 5. EVALUATION 36

• Develop smaller project milestones

• Provide for change and manage the change

• Prototype the project

Below is a table that summarises all the factors, along with the maximum scores and how theJoyce Banda Foundation scored.

5.2 Conclusion

The preceding criteria has shown that the project was a failure, but one could be critical andsay that some of the criteria for each factor of success were irrelevant to the particular projectbecause of the size of the company. The project was challened but not a complete failure becausethe business did have a working system at the end of the project although it was not what wasintended.

But there are still questions about whether this is a fair method of evaluation. There is a needfor further research in determining how the success or failure of small businesses such as theJoyce Banda Foundation could be determined. This project has shown that success and failureshould be evaluated in relation to its size and availability of resources and not use generalcriteria such as The Standish Group’s top 10.

Bibliography

[1] The Standish Group, (1995). Chaos Report,[Online]http://net.educause.edu/ir/library/pdf/NCP08083B.pdf

[2] Donaldson, A.J.M (2000) A Case Narrative of the Project Problems with the DenverAirport Baggage Handling System (DABHS). Software Forensics Centre Technical ReportTR 2002-01. Middlesex University, School of Computer Science.

[3] Denver International Airport, [Online] http://www.absoluteastronomy.com/topics/Denver_International_Airport.

[4] Montealegre, R. & Keil, M. De-escalating Information Technology Projects: Lessons fromthe Denver International Airport MIS Quarterly, Vol 24, No.3, Sept 2000, pp.417-447

[5] Walsh, C. (2008) DIA’s Baggage System Strikes Again [Online]http://www.rockymountainnews.com/news/2008/jan/12/dias-baggage-system-strikes-again, January 12th, 2008.

[6] Beynon-Davies, P., (1995), Information systems ’failure’: the case of the London Ambu-lance Service’s Computer-Aided Despatch Project European Journal of Information Sys-tems(1995)4, pp. 171-184.

[7] Van der Westhuizen, D., Defining and Measuring Success [Online]http://eprints.usq.edu.au/346/1/DependentVariableArticleV8.pdf Department of IS,University of Southern Queensland.

[8] Hastie, S., (2006) What Makes Information Systems Projects Successful? [Online]http://www.softed.com/Resources/Docs/SuccessfulProjects.pdf Software Education As-sociates Ltd.

[9] Bakri, H. & Hartwick, J.(1994)Measuring User Participation, User Involvement, and UserAttitude MIS Quarterly, Vol. 18, No. 1 (Mar., 1994), pp. 59-82. Management InformationSystems Research Center, University of Minnesota.

37

BIBLIOGRAPHY 38

[10] Følstad,A., Jørgensen, H.D., & Krogstie, J. (2004) User involvement in e-governmentdevelopment projects presented at Proceedings of the 3rd Nordic conference on Human-computer interaction, Tampere, Finland, 2004.

[11] Damodaran, L. (1996). User involvement in the systems design process a practical guidefor users. Behaviour and Information Technology,Vol 15,pp. 262-377.

[12] Requirements Analysis.[Online] http://www.nd.gov/epm/resources/doc/requirements-analysis.pdf New York State Office for Technology, Copyright 2001.

[13] Bennet, S., McRobb, S., Farmer, R., (2006). Object-Oriented Analysis and Design usingUML 3rd ed. Berkshire, England: McGraw-Hill Education.

[14] Maciaszek, L.A., (2005)Requirements Analysis and Systems Design 2nd ed. Essex, Eng-land: Pearson Education Ltd.

[15] Pearlson, K.E. & Saunders C.S., (2004) Managing and Using Information Systems - AStrategic Approach. John Wiley & Sons, Inc. New York, NY, USA.

[16] Jones, J., Aguirre, D., Calderone, M. (2004) The 10 Principles of Change ManagementStrategy and Business,- Allen & Hamilton.

[17] Yeates, D., Wakefield, T. (2004).Systems Analysis and Design. 2nd ed. Essex, England:Pearson Education Ltd.

[18] Dove, R., (2004). Decision Making, Value Propositioning, and Project Failures - Real-ity and Responsibility. In Proceedings of International Council On Systems Engineering(INCOSE) Region II Conference, Sept, 2004.

[19] Laudon, K.C.& Laudon, J.P.(1996) Management Information Systems: Organization andTechnology. Prentice-Hall; Englewood Cliffs, NJ, USA.

[20] Bazerman, M.H. & Chugh, D (2006) Decisions Without Blinders. In Harvard BusinessReview. January 2006, pp 88-97

[21] Eisenhardt, K.M (1989) Building Theories from Case Study Research. The Academy ofManagement Review, Vol. 14, No. 4 (Oct., 1989), pp. 532-550

[22] Wikipedia(2009) Case Study http://en.wikipedia.org/wiki/Case_study

[23] Stake, R.E. (1995) The Art of Case Study Research Sage Publications.

[24] Bocĳ, P., Chaffey, D., Greasley, A., Hickie, S.(2006) Business Information Systems: Tech-nology Development for the E-Business.

BIBLIOGRAPHY 39

[25] Avison, D., Fitzgerald, G. (2003). Information Systems Design 3rd ed. Berkshire, England:McGraw-Hill Education.

[26] Joyce Banda Foundation, (2006).The Joyce Banda Foundation: Developing LeadershipToday For a Better Tomorrow. Lilongwe, Malawi: Mercantile International.

[27] The Hunger Project (1997).Joyce Banda [Online] www.thp.org/what_we_do/key_initiatives/honoring_africa_leadership/laureate_list/joyce_banda

[28] I am Because We Are (2008) About the Interviewees [Online] www.iambecauseweare.com

[29] The Hunger Project (2008). About the Prize [Online]www.thp.org/what_we_do/key_initiatives/honoring_africa_leadership/about_the_prize2

[30] Sage (2009).About Us [Online] http://www.sage.co.uk/about_us.aspx

[31] Kinspeed (2009). Sage Line 50 [Online] http://www.kinspeed.com/sageline50

[32] Bray, M. (2009). Bespoke vs Off-the-Shelf Software [Online] British Computer Society.http://www.bcs.org/server.php?show=ConWebDoc.2767

[33] a troubled Halved Ltd (2009). Bespoke vs. Off-the Shelf [Online]http://www.athdesign.co.uk/tech_showcase/ATH_bespoke.swf

[34] The Standish Group,(1995). COMPASS Report [Online]http://ecee.colorado.edu/ swengctf/standalone/handouts/UnfinishedVoyagesRTF.rtf

Appendix A

Success/Failure Profiles

Figure A.1: Project Success Factors

Figure A.2: Project Challenged Factors

40

APPENDIX A. SUCCESS/FAILURE PROFILES 41

Figure A.3: Project Impaired Factors

Appendix B

Change Management Principles[16]

1. Start at the top

2. Make the Formal Case

3. Create Ownership

4. Address Culture Explicitly

5. Prepare for the Unexpected

6. Speak to the individual

7. Address the ’human side’ SystematicallyAddressing the human side systematically provides a formal approach to managing thechange. It is important to begin with the leadership and engage the key stakeholders andleaders. This demands as much data collection, analysis, planning and implementation asthe redesign of the strategy, systems or processes. It is necessary to integrate the changemanagement into the the product design and decision making.

8. Involve Every LevelAs the transformation of change starts to progress, it begins to affect different levels ofthe organisation. It is important that at each level a leader is identified and is trainedand equipped with their specific mission, which they then push through their department.This results in the change ’cascading’ through the organisation.

9. Communicate the MessageThe best change programs are those that reinforce the core messages or reasons for changethrough regular advice that is inspirational to the employees. Communication flow runsfrom the top of the organisation to the bottom but seeks the input and feedback ofemployees down the organisational structure.

42

APPENDIX B. CHANGE MANAGEMENT PRINCIPLES[16] 43

10. Assess the Cultural LandscapeBy assessing the cultural landscape the project managers are able to determine the organ-isations readiness to change and tackle any problems that may surface. This diagnosis ofthe cultural landscape identifies the core values, beliefs, behaviours and perceptions thatmust be taken into account for successful change to occur.

Appendix C

Documents

- Consent Form - Initial Interview Structure - Registration Form - Receipt

44