Module 3: Systems development overview and issues

Overview
In the previous two modules, you learned about the management issues that surround the strategic uses
and planning of information systems. The next three modules deal with delivering on those plans.
In this module, you review the overall concept of systems development and the activities required to
successfully introduce any new system. You look at some of the different methodologies of systems
development, the make or buy decision, and vendor selection. You also study project management, the
issues that lead to the success or failure of IS projects, and the feasibility of developing systems.
Developing an information system is complex and time-consuming. It involves moving from a general
idea, such as we need a new inventory system, through to a clear specification of why the new
inventory system is necessary, what it should do, how it will be developed, and whether and how
external vendors will play a role in the process. Managing such projects is complex, and the failure rates
in organizations are high. But attention to the issues raised in this module will increase the chances of
success.
The core skills and basic understanding of systems projects is the same, but today development projects
deal with more choices than ever before. Not only from how data is entered, stored, and accessed (local,
distributed, web, cloud), but also in the results that users request from the data (static reports, real-time,
cross-platform, linked, customer-integrated, big data). The complexity of choices, added to the rapid
change of technical options, makes it difficult for development projects to be sustainable over the long-
term. In 2002, no one heard of social media. Today you wouldnt design a service application without
considering how to tap into and exploit the best features of social media for your customers, or how to
include mobile apps in the design.
This material will enhance your competence to advise on the design, development, and implementation
of IT projects including specific applications software, and advise on implications of IT acquisitions and
vendor selection. You will also develop your ability to assume leadership at various phases of planning,
implementation, and evaluation.
3.1 Systems development
3.2 Systems development methods and techniques
3.3 Make, buy, or subscribe decisions
3.4 Acquisition of software and hardware
3.5 Vendor selection and contractual issues
3.6 Project management
3.7 Feasibility and cost-benefit analyses
Module summary
Print this module
3.1 Systems development
Learning objectives
Identify and describe the six activities of systems development. (Level 1)
State the factors that influence the success or failure of systems development. (Level 1)
Required reading
Chapter 9, Section 9.2, Overview of Systems Development
Module scenario: Project management on the fly
You have assembled eight of your highest performing systems employees for an impromptu meeting. It
follows another impromptu meeting you finished twenty minutes ago, where you, senior management,
operations, finance and HR discussed a new initiative by your biggest customer. Jerrens wants us to
implement their custom defect collection system, your CEO explained. Its web-based, and it will
communicate directly with their private cloud. The data it collects will help them better monitor all parts
from all suppliers, and be able to flag parts as defective at the source before they reach their assembly
plant. He passed copies of the design to each of us. This is not optional. We have six months to be
compliant. Tomorrow morning I want to know how each of you is going to make this happen. What
challenges you foresee, obstacles, anything. This is priority one, and takes precedence over any other
projects you are currently doing. You recount the meeting to your team. Six months! says Heather,
your lead project manager. I dont see how we can be ready. Its going to take us that long just to work
through the SDLC. Youre right, you say. By following the SDLC process we cannot meet the due
date. Thats why we need to approach this differently. We need to be more agile, more flexible in our
approach quick iterations, multiple smaller deliverables. We have to make good, working software,
built quickly piece-by-piece. This is called agile project management. Now lets talk about how were
going to meet this deadline
LEVEL 1
In the systems development process, there are six broad activities:
Systems analysis (Topics 4.1 to 4.6)
Systems design (Topics 4.1 and 4.7)
Programming (Topic 5.1)
Testing (Topic 5.2)
Conversion (Topic 5.1)
Production and maintenance (Topic 5.4)
(Different methodologies for systems development (waterfall, prototyping, incremental, RAD, extreme,
scrum), some of which you may have learned in previous MIS courses, arrange these activities into
different steps or phases. The precise names of the individual activities are not as important as the
underlying concepts. This module uses the term activities to denote the tasks that must be accomplished
and the term phases to denote the way these activities are organized in different methodologies.)
Six activities in the systems development process
The six activities in the system development life cycle (SDLC) form what is referred to as a waterfall,
where each activity is defined, completed, and signed off before the next phase begins. This way you
ensure continuity in the process and a steady project flow, but not flexibility. There is little iterative
development in the SDLC process, which is one of its greatest drawbacks. Still, the system development
process is the classic method of software development and IS project management, employed across
many system implementations. The number of activities can vary, but these six activities encompass the
scope.
Systems analysis
In systems analysis, the opportunity or problem is defined and causes and solutions are identified. You
establish what information or data is required and choose the process or method that will be used to
acquire it. There is information sharing between departments, and between users and developers. At this
point, the specific plan that is needed is created and the decision on feasibility is made, with the input
from all concerned and beneficial parties.
Systems design
This activity provides details on how the system will achieve the goals set out in the systems analysis
stage. Here, the overall logic for programs, screens, reports, and data is defined. Analysts and key
project team members often take primary roles in this activity.
Programming
The system is translated from the design into the programming language or software that will best meet
the requirements of the system plan. Analysts and programmers are the key players in this activity.
Testing
This is the activity where the new system, including new software and procedures, is tested to see if it
works as planned and to ensure that it meets the system requirements set out in the analysis. Users,
analysts, and programmers are together again to verify the thoroughness of the new system.
Conversion
Conversion means moving from the old system to the new system. There are a number of methods for
accomplishing this (direct, parallel, phased, pilot), and each has a best use or application.
Production and maintenance
Once the system has been adopted and is in use, it is important to ensure that everyone is properly
trained in the new procedures and that the system continues to run smoothly through regular
maintenance and periodic software updates.
Why do systems development projects succeed?
A number of factors contribute to successful systems development projects:
clearly defined goals
excellent communication
management involvement
definitive timelines
strong project management skills
In successful projects, the goals and outcomes are clearly defined and understood, not just from a list of
requirements, but from a clearly expressed business problem that needs to be solved. The expectations
of the system are managed closely by experienced people, so that users and management are realistic
about the results and dont have an inflated sense of the outcomes. This can be achieved by openly
communicating the goals of the project and everyones role in attaining those goals, and constantly
reporting the measurement of success towards those goals. Communication is easier if management
supports the development of the system, and success is highly unlikely if management does not. The
system should align with the goals of management and support the strategy that management,
governance, or the steering committee has expressed.
Successful systems development projects have clear start and end dates with reasonable timelines to
accomplish the goals. Even meeting all of these conditions doesnt guarantee a successful project. The
specific methods and processes that must be used to successfully complete systems development will be
described in Topic 3.6.
Why do systems development projects fail?
Systems development projects often fail because one or more of the six core activities of systems
development are ignored or done poorly. However, there are other reasons why systems development
projects fail, including
Lack of understanding of the desired results (imprecise targets) Development projects, like
business cases, must clearly state who and what will benefit from the effort. If tasks do not
connect to results, or if results are not clearly defined, then it is impossible to know when you
have met your goals. Projects must be planned, and plans must be scrutinized.
Poor estimating techniques for budgeting and scheduling Estimating for budgeting and
scheduling are not mutually exclusive skills. Individually, each can cause a project to fail. You must
be able to estimate resources (who and when) for scheduling, and estimate costs (how many and
how much) for budgeting. Without these skills, a project will never be financially viable.
Small, unadjusted schedule slippage, which cumulatively results in a major delivery delay A
project is more than just a collection of tasks. Many tasks are relative, and some cannot begin
until other tasks complete. A slippage in delivery of a few key tasks can cascade through the
project and cause major completion delays costing the corporation time and money.
Lack of project management skills or leadership Project management is a learned skill and
should not be taken lightly. A great analyst or support person does not automatically make a great
project manager. The skills can be complimentary, but should never be treated as identical. It
takes time and effort to earn trust and become a respected leader.
Poorly trained analysts and programmers An analyst on a development project must be able to
break a large and complex request into programmable sections. They must be trained on different
project methodologies, to know which is best to deploy in a given circumstance. A programmer,
improperly trained on current development techniques will take longer to achieve their results,
potentially impacting project delivery. The work styles of key IS people slow and exacting vs.
fast and iterative must also be considered.
Conflicting goals and objectives among the project team members and users Although the
project may have clear results, individual team members may harbour their own goals not in sync
with the project goals (for example, employees who are poorly motivated shirk responsibilities;
managers who dont take valuable feedback from programmers). The project manager must be
open to feedback from all team members and address any differences before a fracture appears in
the direction of the project.
Use of inappropriate software or hardware tools Flexibility and clear-sightedness are key to
development projects. Some development projects may only require a simple Access
departmentally shared database, as opposed to a fully integrated, web-based, .Net coded XML
schema cloud deployed application. If the only tool you have is a hammer, everything looks like a
nail. This goes back to good analysts.
Coordination of personnel, phases, and tasks is vital to systems development but is not an easy task for
the project manager. A common misconception in IS projects involves using more programmers to
complete a program if delivery time is threatened. Adding more programmers to a job may, in fact, take
more time because more people require more coordination. There is, theoretically, an optimal number of
programmers for any specific activity. Once the optimal number is exceeded, the total output will
decrease rather than increase.
3.2 Systems development methods and techniques
Learning objectives
State the importance of systems development methodologies. (Level 1)
Compare and contrast the waterfall method for developing systems with prototyping, rapid
application development, end-user development, purchased applications, and outsourcing. (Level
1)
Required reading
Chapter 9, Sections 9.3, Alternative Systems-Development Approaches, and 9.4, Application
Development for the Digital Firm
Module Scenario: Methodologies
You have invited Jon Kwon, your senior analyst and development project manager, to a special meeting.
Jon, I want you to lead the Jerrens defect data collection project. You have done a great job on three
past projects, and I need you for this one too. Jon smiles and nods his head. This one is going to be
tough, you say. I think we may need to look at this as a RAD development model but Im not sure
which version. We dont have time to be wrong. You scratch your head. Waterfall will be too slow, too
rigid. And we dont need user involvement with this since the software is coming from Jerrens. They
have as much say as we do. And theres nothing to prototype. We install it, test, work out the integration
issues, train the users, and then we go live. With a grin, Jon says, I think its agile, with a dedicated
cross-functional team and a consultant from Jerrens. You smile. You think? you say as you grab a
sheet of paper to work out the methodology pros and cons as applied to this project.
LEVEL 1
What are systems development methodologies?
Systems development methodologies are a framework to follow when designing and developing a
system. They are a guide, a working structure of all of the activities involved in systems development. For
projects, where teamwork is required, methodologies impose a discipline to ensure that the team works
together properly, and that each member of the team understands what is expected.
A methodology typically specifies
a set of techniques to be used in each phase of the systems development process
a milestone at the end of each phase, along with a description of the management decision that
may be required
a deliverable for each milestone, such as an analysis report, a project status report, or programs
or systems completed
Deliverable is a project term used to describe the often tangible end product of a task. For example, the
deliverable from the task of defining user requirements in the waterfall method is the requirements
statement. In prototyping, the prototype system may be the deliverable from one iteration of analysis,
design, and building. A deliverable could also be an upgraded server. A milestone is a significant event
in the project's life cycle, such as the end of a task. Make sure you can distinguish between milestones
and deliverables. Completing the system proposal, for example, is reaching a milestone, and the actual
system proposal document is a deliverable. Similarly, completing data flow diagrams during analysis is
reaching a milestone, and the data flow diagrams are the deliverables.
Advantages of using methodologies
There are many advantages of using systems development methodologies:
Methodologies impose discipline on the project team, which must perform tasks, comply with
standards, and adhere to a project schedule. This discipline is required for both new and
experienced team members. Projects impose a great stress on the people involved. A methodology
will help keep them focused, and help them see past the unavoidable glitches along the way.
While some methodologies place a greater emphasis on controls and schedules, all provide the
basic discipline needed to complete the complex tasks of systems development.
Methodologies can be used to ensure that the important aspects of a project have been taken into
account. A method prescribes the way to accomplish something. It ensures focus, and adherence
to a processand a way to catch important aspects early on.
Methodologies enable management to coordinate and manage the system development process.
Outlining the activities that occur and the logic governing the process makes it easier to assess
progress.
Disadvantages of using methodologies
The underlying assumption of many methodologies is that a standard can be imposed on the systems
development process. This is true; however, unfortunately, no two projects are alike. Sometimes,
systems analysts may hide behind the systems development methodology as an excuse for thinking in
new directions going through the project in accordance with the steps outlined in the methodology in
"cookbook" fashion. Each time they will bake a cake, when maybe all they needed was a single muffin. If
the only methodology you have is the waterfall method, then every project appears to be a full-blown
development project. This is never the case. Developing systems is a learning process involving learning
about business processes, about key performance drivers, and about the capabilities of the technology to
facilitate those processes.
The most common systems development methodologies are the traditional or waterfall approach,
prototyping, end-user development, and application software packages. However, new versions of the
RAD (rapid application development) methodology like agile, lean and scrum are also gaining acceptance.
Traditional systems development life cycle (SDLC) or waterfall method
A systems development life cycle (SDLC) model is a logical process that describes the major steps
performed by analysts and users to develop an information system. The six activities introduced in the
first part of this module form the structure of the SDLC.
Exhibit 3.2-1 shows the activities in a typical SDLC, which resembles a waterfall.
Exhibit 3.2-1: Systems development life cycle (SDLC)

The traditional approach to developing systems follows these activities sequentially, with signoff at the
end of each phase. The signoff is an important step that identifies the completion of a phase, signalling
the approval to continue to the next phase. There is little, if any, phase overlap.
There are no standard rules for the number of phases in the waterfall model. Different organizations
arrange the tasks differently. Sometimes you will see five phases (analysis, design, construction,
implementation, and maintenance), other times you will see six phases as described here, and still other
times you will see more phases. What is important in the waterfall method is the linear flow from phase
to phase with the clear milestones and signoffs.
The advantage of this approach is tight control over resources and escalating commitment, which allows
explicit opportunities to back out of a process if things are not going well. It provides a formalized
structure to collect information about a project (such as design specifications, budget, actual time, and
cost) in a consistent manner, so that a historical database can be built around the whole project to help
determine estimates for similar new projects. And, with its emphasis on milestones and deliverables, the
waterfall approach works best with large clearly defined developments where management can monitor
progress and control costs in a clear, phase-by-phase approach.
The disadvantage to the waterfall method is that it is a very rigid method, with long periods of time
where there is no involvement (or little involvement) from users. A common user complaint of IS is that
sometimes software is developed without any consultation with the people who will actually use it. This
can lead to systems that end up not meeting the requirements of the users, and being rejected outright
by the people who need it. Not only can this create havoc with a project timeline, it also creates
animosity between departments.
In addition, there is a risk associated with requiring users to sign off on system specifications and commit
to a system design at the end of the requirements phase. Users are often unable to comprehend the
design without actually seeing how the system works. Many users also have difficulty articulating what
they want, partly because of a communication gap between users and analysts, and partly because users
do not know what is possible and therefore cannot specify what they really need. A user will often know
what they want when they see it, but not know how to explain it.
More often than not, after the requirements are completed and the abstract designs agreed, users feel
coerced to sign off on the system design because they cannot effectively criticize it. It is also not unusual
for users to misunderstand the system requirements. In such cases, they feel compelled to accept the
system design because they do not know any better. If users approve the design under either of these
two circumstances, the analysts have a time bomb on their hands. Once the design is converted into
testable programs with input screens, users will rebel with a consistent cry: this is NOT what they asked
for, NOT what they wanted, and is WORSE than what they currently have.
In spite of these disadvantages, the waterfall approach is commonly used by many of the more
structured and disciplined IS development groups, especially for larger projects involving several systems
development staff members.
It is worth noting that in recent years the waterfall method has come under scrutiny. The rigidity of its
approach, once considered its strongest asset for thoroughness, is now considered a detriment to
success. An interesting post by Jeff Gothelf at the Harvard Business Review blog in 2012 tackles the
question of whether there is a better project model than waterfall.
1

Prototyping
Where blocks of modular activities plan-design-code-implement define the waterfall approach,
prototyping is defined by the word iteration. Prototyping is an iterative form of development where users
work alongside the developers and try out different aspects of a planned system, and provide feedback
that is used to improve each version of the proposed system. It is a build-test-improve-test-improve
approach to development that builds the finished product by achieving a working prototype. Prototyping
requires less structure as a method, but more commitment from the users of the new system.
Prototyping works well in situations where it is difficult to articulate or identify the needs and
requirements of the system, where requirements are fuzzy, or not clearly articulated.
Its principal advantages come from the fact that a working system is built in incremental stages that the
users can see and use. In this way, it is often easier to identify requirements accurately, and costly
changes late in the development project such as those that occur in the waterfall approach are
more likely to be avoided. The users know what the system will look like and how it will function because
they are testing the development in increments.
Prototyping has two major weaknesses:
It is difficult to manage on large-scale projects because of the time needed to build each new
version of the prototype.
It is difficult to know when you have achieved the finished system.
You need to know when it is no longer feasible to continue making very minor changes to the system and
accept it as good enough. Figure 9.8 in the textbook shows the activities in a typical prototyping model.
End-user development
An end-user development methodology proposes that there are some systems that do not need the full
support of an IS department to create, but can be accomplished by well-trained users themselves. By
providing tools, training, and access to data, users can create their own applications and systems. Users
are trained, and given access to such fourth-generation development tools (oriented towards users) as
MS-Excel and MS-Access for structure and SAP Crystal Reports for extracting data into reports. Figure 9-3
in the textbook provides more examples.
End-user development takes advantage of the fact that users know their requirements best. This
approach can reduce systems development backlogs by reducing the number of systems development
specialists needed on projects so that they can work on the larger, more complex systems projects.
One of the challenges with end-user development is security, especially in larger enterprises. Security
profiles are often inherited in the application, which leads to the dual issues of: a) compromised security
if the application goes viral in the organization; or b) compromised distribution because security profiles
are violated at another desktop.
The difficulty with end-user development is keeping track and documenting all of the applications and
systems. Because individuals are creating their own unique applications, it becomes harder to enforce
standards and maintain quality assurance. One solution is for IS to enforce minimum programming
standards to ensure that basic programming practices are followed. IS may also insist that end users
justify the project financially, so that end-user development is agreed to be the best method.
However, the more restrictions placed on end-user development, the less likely users will see it as an
option.
Application software packages and outsourcing
One of the oldest questions in IS is do we build or buy the application? In many cases, it makes more
sense to purchase applications that already exist rather than trying to develop a custom approach.
Ongoing costs, customization, upgrade and integration costs all are evaluated to determine which the
most cost-effective solution is. Faced with these costs, many organizations opt to purchase (or subscribe
to a hosted solution). Organizations can benefit from the learning that has gone into developing a
standard system (which is designed with benchmarking and best practice standards), and can often
achieve their business goals for a substantially lower cost with a purchased system rather than a custom
system. Purchasing applications is discussed in greater detail in Topic 3.3.
Outsourcing, by which we refer to the practice of contracting out the activities involved in building a
system, is a further option. Outsourcing firms specialize in applying IT to solving business problems, so
they bring tremendous technological and process expertise to the table. On the other hand, they do not
know the business as well as in-house experts, so there are risks with this approach as well. Today,
services such as cloud computing which includes SaaS (software-as-a-service) and IaaS
(infrastructure-as-a-service) offer new ways to consider outsourcing beyond buy-build or local
consulting. Considerations today also include offshore outsourcing, where the consulting group is not
domestic, but may be located in India or China. In this case the cost for programming hours is far less
than domestic rates. There are hidden costs associated with offshore outsourcing though, and figure 9-9
in the textbook explains what some of these are.
Outsourcing is a major strategy within IS, and it is discussed further in Module 9.
Rapid application development (RAD)
Rapid application development (RAD) grew out of the realization that usually 80% of a system's
functionality was completed in about 20% of the time (the Pareto 80/20 rule). RAD relies heavily on rapid
prototyping with little pre-planning, in an effort to reduce requirements and design costs. The timeframe
for RAD is usually restricted to between 60 to 90 days. To achieve this rapid development, an agreed on
minimum set of requirements is the benchmark of completion (80%), instead of all the requirements of
the system.
RAD uses fourth generation programming tools (database queries, report writers, data manipulation, web
development, and general purpose languages under the development of user menus and buttons) and
standard software to connect to data sources. There is no time to create custom programs or
applications, however some components may be assembled from working versions elsewhere, and
simultaneous development of components is common. There is little planning in the RAD methodology;
you plan as you develop. The challenge of RAD is that the schedule is firm and cannot be changed. Given
that environment, quality, and money will be sacrificed to keep to the schedule, RAD works well for
specialized stand-alone systems where performance is not crucial. It is less appropriate for systems that
will interact with a large number of other systems, or for mission critical applications where quality and
performance is the top priority.
The popularity of RAD has made way for a number of variations including:
Agile a methodology that uses incremental and iterative development to evolve solutions using
dedicated cross-functional teams.
Extreme a methodology where programming is done in pairs, and is adaptive to changing
customer requirements through short development cycles called timeboxes.
Joint application development (JAD) is another iterative development approach that relies on
the decisions communicated through knowledge worker/IT workshops for obtaining requirements
and specifications.
Lean a methodology where Lean techniques of the Toyota production system are applied to
software development, focusing on the elimination of waste (time, money, activity) with fast, lean,
rapid development.
Scrum a methodology within agile development, with a predefined process skeleton of roles and
practices including pig and chicken roles.

1
Jeff Gothelf, 2012, Harvard Business Review, Blog. Accessed February 18, 2013:
http://blogs.hbr.org/cs/2012/07/a_better_project_model_than_the_waterfall.html
3.3 Make, buy, or subscribe decisions
Learning objective
Evaluate the factors to consider when choosing whether to make or buy an information system.
(Level 1)
Required reading
Review Chapter 9, Section 9.3, Alternative Systems Development Approaches, (subsection on
"Application Software Packages and Outsourcing")
LEVEL 1
With any system that you design, there are options to build, buy or subscribe to the software. Building
can be done internally, or by consultants domestic or offshore. Buying software can involve purchasing
a license to install and use software, buying a subscription to use the software hosted by a software
vendor through a SaaS model, or subscribing to an IaaS model where cloud service providers offer
resources such as virtual machines, storage, and firewall services to their customers on a pay-per-use
basis.
Various issues factor into the decision to make or buy software. Customized functionality and control
trade off against cost, speed of implementation, internal politics, developer skills, strategic value, and risk
all these play a factor in the decision. Organizations that have opted to refine their in-house
development according to the principles of a service-oriented architecture (SOA) have the advantage of
reusable code, and may find the build option more feasible. Regardless, integration represents a
challenge if you must link in-house systems to external systems.
Deciding whether to build a custom system (internally or using consultants) or acquire an existing system
(commercial software or a custom system made available to partners) is one of the biggest challenges in
developing new systems. There are advantages and disadvantages to each approach. The trend in
organizations is towards buying (which includes subscribing) instead of building. To make the buy
decision more complicated, organizations also have the option of using open-source software with
customization vs. buy. Despite the complexities of the solutions available, the choice of whether to make
or buy must be made for each new system considered.
Once the design approach (make or buy) has been established, the process of building the software or
selecting a vendor and negotiating the purchase begins.
Why this matters to accountants
With time, money and reputation on the line, the ability to properly cost all the risks and benefits of each
development option is sometimes the only way to decide. As a part of the governance team, or the IT
steering committee, your ability to factor in to gauge the financial soundness of hidden decision costs,
one-time charges, maintenance fees and annual increases will enable you to properly assess the viability
of the decision for the company.
Off-the-shelf software
The term "off-the-shelf" as applied to software today is misleading. Off-the-shelf conjures up images of
going to a store and buying MS Word and then installing it on your PC. It implies a finished, configured
solution that will work in a variety of cases. When buying, rather than building, applications, the reality is
somewhat different.
SAPs Business Suite, Oracles JD Edwards EnterpriseOne, Microsofts Dynamics, and the other large
enterprise systems are off-the-shelf software in a sense. They are purchased rather than custom-built
applications. But they do not come ready to set up and run in an afternoon. The process of customizing
purchased applications is a lengthy one requiring months or even years to complete. It is probably best
to refer to this process as purchasing applications or as buying customizable off-the-shelf (COTS)
solutions. However, because of the long lead times to customize purchased systems, many organizations
opt to leave the system vanilla (unmodified or uncustomized). Adopting the Pareto 80/20 rule,
organizations opt to work with software that covers 80% of their requirements. If modifications are still
required, they are made outside of the original code. This way vendors fixes are easier to apply, updates
can be quickly scheduled and applied, and the update costs to IS are minimal because there are no
modifications to document, track, reapply, and test, after a product update.
Purchased systems can be divided into two categories vertical or horizontal solutions. Vertical
solutions deal with a broad range of functionality within the context of an industry, while horizontal
solutions deal with a specific type of functionality but are applicable to a wide variety of industries.
Exhibit 3.3-1 illustrates these two options.
Exhibit 3.3-1

For the horizontal application, consider a package such as Intuits QuickBooks. This package is designed
to be used by a broad range of companies, across many industries. The target market tends to be smaller
enterprises, but nonetheless Quickbooks shows a high degree of breadth.
Vertical solutions in health care, including software such as Meditech and Cerner, provide functionality to
support a range of hospital activities (from emergency room triage and reporting to medical image
distribution, through to lab orders and accounting).
These packaged solutions all share tasks that are categorized as back-office applications, which are used
in the day-to-day running of the company. Front-office solutions like e-mail applications and office
productivity suites are also packaged solutions, but with a twist.
Historically, Microsoft has dominated the business-user desktop with both Windows and MS-Office. More
recently, new hosted solutions are challenging that position. Since 2006 Google has offered users a
choice with Google Docs (integrated with Google Apps), a cloud-based series of office applications
(spreadsheet, word processor, presentation, e-mail, calendar, form, drawing), with minimum storage
capabilities and free use. Googles incursion into this predominantly Microsoft market has changed how
organizations look at software licensing costs vs. value. Google is not the only vendor threatening
Microsofts desktop dominion: Oracle offers the OpenOffice.org suite, and Zoho Corporation offers Zoho
office suite, which are free for basic use but SaaS for more extensive features. Excluding OpenOffice.org,
all these solutions are browser-based with no special software to be downloaded or installed. For IS
departments, this offers many advantages:
No licensing costs or hardware purchases
No support costs community supported with help centers and user documents
No software fixes since the connectivity tool is a browser
Storage of files is on Googles cloud drive no cost to the organization
Realizing the competition for the desktop, Microsoft introduced Office365, a cloud-based suite of their
famous office applications, offered on a SaaS model.
The other side of off-the-shelf is open-source software. Although there are still arguments against
running Linux on the desktops of corporations, open-source application solutions have matured to the
point of serious consideration. Cost is often an enticement to open source since many apps are free, or
require a minimal investment, and open source delivers the source code with the application so that in-
house developers can customize the code to their own specifications. This option, however, is based on
the property rights of the software. Some open-source software allows for developers to freely
incorporate their enhancements for proprietary purposes, while others adopt a share-alike principle that
states enhancements must be freely shared with the public.
Advantages and disadvantages of making and buying
The governance team or IT Steering Committee must, with the support of the business, make a decision
on which development option to support and arrive at a decision that is financially supported. It is
possible to evaluate the make and buy options using several criteria functionality, integration, cost,
speed of implementation, risk, and control.
Functionality
In terms of functionality, there is an advantage to building your own system in that you can design it to
meet your organization's precise needs. However, when you buy an existing system, even one that is
customizable, you will not get exactly the features you want. SAP has approximately 3,000 tables to allow
customization of its application; yet almost every organization that implements SAP finds there are some
features that they want but cannot seem to achieve.
Many managers are concerned that buying software forces them to adapt their business to the
technology. This seems to them like putting the cart before the horse after all, if technology is there to
support the business, shouldn't software be customized to meet the needs of the business?
This is true, but the issue is determining the true needs of the business. There are many organizations
where the "needs" of a system are driven by "how we have always done things." But these traditions are
often rooted in the constraints of old technology or business conditions, and they keep being applied long
after the original conditions that made them useful have ceased to exist. Enterprise systems are not just
software anymore. The logic behind the software and the principles and practices that have driven the
application development are core to understanding the relationship between software design and
competitive advantage.
Todays system software is based on industry best practices and benchmarks. Learning and using the
software as it was designed will often put your business ahead of custom-built software, which must
determine for itself how to find and integrate those same practices.
Integration
Information systems today rarely operate in isolation. Accounts payable arise from orders placed to
suppliers for parts or services, thus linking accounting software to purchasing. Similarly, payroll systems
that must compute commissions have to be linked to sales information systems.
In addition to analyzing the functionality of a software package as a stand-alone unit, you must assess
the ease with which the software can be integrated into your organization. For an organization with a lot
of custom-designed software, integration issues will often drive you toward building a custom system,
and eventually changing the architecture of component development to SOA. Custom software is rarely
designed with a broad view to enable integration with other systems, certainly not to the degree that
commercial software is. It may be difficult to integrate a new application package with your existing suite
of systems, especially if they are legacy custom-built applications.
Improving integration can be a powerful force for deciding to use purchased applications. Because these
systems are often designed to be applied by a range of users in a range of applications, vendors need to
think through areas where integration with other commercial systems would be necessary. Integration is
built into the design, modules connect to modules, and a core set of master tables work to eliminate
redundancy and sloppy design. Compare this to many IS departments today, where a mish-mash of
middleware and other integrated applications serve to connect systems that were never meant to connect
together, yet do so in such a complex way that in some cases software is frozen in its current working
state.
Commercial packages vary in their ease of integration and flexibility. Some vendors maintain proprietary
infrastructures that are hard to link with other systems, while others pursue flexibility and ease of
integration as an explicit goal. The move toward open-source software relates to this topic as well. If
your vendor's source code is open to the world, it is easier for vendors of other applications to build
software to link to it. This is one key advantage of the open-source model.
Other ways of achieving integration are possible. The use of standard application programming interfaces
(APIs) provides a way of defining the key points at which integration could be made (that is, to link an
order in a purchasing system to the accounts payable function in an accounting system, for example).
APIs also provide a way of building routines to allow other software packages to link into the application
at these points.
Think of APIs as analogous to the built-in functions in Excel. Each function (like SUM or PV (present
value)) represents a block, or module, of programming code that has been created to do a particular
task. This module has been designed in such a way that a user who knows the key inputs to the function
(list of numbers for the SUM function; an interest rate, future value, number of periods, and payment
amount for the present value function) can use the function without knowing anything about how it is
designed internally. APIs, however, work between two applications, rather than within an application, and
thus allow for integration. They can be language dependent or language independent, and are available
in applications across the web and back-office ERP Suites.
Integration is also a key issue in adapting to new technologies such as big data. Traditional database
management systems are not designed to handle the size and complexity of big data sets, so new
methods must be created. Solution providers such as IBM, Oracle, SAP, and many others are all working
to identify big data opportunities and solutions. Google has already created a structure to help analyze
big data called BigQuery, a SQL-based web service designed to use a small number of very large,
append-only tables.1 What big data offers is insight into web-based data sets collected through such
means as social media and web searches, with the value being in the details, properly analyzed and
categorized, to provide a company with competitive value on consumer decision-making practices.
Cost
Cost issues, aside from the preceding issue of integration costs, favour buying applications. While buying
is not cheaper than building in every case, there is a basic economic principle that tends to drive the
costs down for purchased applications. When you build a custom application, you have only one company
across which to spread the development costs. But when you build for many companies, you can spread
the costs over many firms. This is essentially an argument for economies of scale.
Of course, designing for many companies requires the creation of a more complex system, which tends
to drive the need for functionality and security up, and increases cost. On average, however, across a
wide range of applications, you can obtain economies of scale by going with a purchased application.
Purchasing costs are further complicated by the buy or subscribe model. Whether the software is hosted
in a private or public cloud, or hosted in a SaaS scenario, user or subscription costs offer a new approach
to buying software. Although no organization actually buys software with the intent to own it (you license
it from the vendor over a certain period), the subscription or on-demand model has its own cost
structure, and must be carefully scrutinized over time to ensure economic feasibility. Current estimates
for SaaS cost models indicate that although SaaS licensing is less expensive in upfront costs, over time
the total software cost is more expensive. However, other costs such as hardware and personnel must
also be considered, as SaaS reduces these costs.
Speed
Speed of implementation also favours buying an application. Building systems from scratch takes a lot of
time, and if you can find a way to buy work that has already been done and meets your needs, you can
be up and running much more quickly. This has to be considered within the context of integration issues,
because the time to integrate incompatible systems may outweigh any other speed advantages.
Risk
Minimizing risk is one of the biggest reasons to go with a purchased solution. The cost of the application
and its functionality can be examined beforehand to see whether it meets the organization's needs at a
reasonable cost, and installed and run in preliminary test/pilot environments prior to purchase.
This is not to say that purchased applications are "risk free." Enterprise system (ES) implementations, for
example, are fraught with huge risks, and there are many failures to attest to this. The key is to compare
the purchased approach with what would have been. As risky as ES implementations are, they pale in
comparison to the risk of trying to build equivalent functionality from the ground up.
Control
When you buy an application, you lose some control over how it will be upgraded and with what features.
You become dependent on the vendor to continually enhance the software and to add features that your
organization will value. This loss of control is a potential downside to purchasing applications.
Keep in mind, though, that it is the vendor's business to develop applications that customers will want,
and keep pace with new business trends and directions. If your requirements are common in your
industry, there is a greater likelihood that they will be met in the future.
The flip side to this issue is responsibility. If you build your own applications, you are committing yourself
and your organization to a lifetime of upgrades in order to keep enhancing the functionality. This
commitment increases the need for a large number of IT specialists who can do this development. Also,
given the need to make trade-offs in organizations, it probably means some other things will not get
done. For many organizations, the trade-off is not worthwhile.
Hosted solution
As mentioned, another option that has become more popular recently is to lease access to a system
following the software as a service model described in Module 2. A number of vendors offer subscription
licences that allow you to use an application (from SAP to Oracle and beyond), hosted at the vendor's site
and shared with other organizations. These companies, originally called application service providers
(ASPs) but now SaaS providers, offer a cost-effective solution for many situations. Typically, the
applications are not customized to the firm, but represent fairly generic solutions. They require little time
to implement because they are remotely accessed, typically through a browser. (Some SaaS providers
claim you can be up and running with enterprise class software in about four weeks). As a result, they
appeal most strongly to start-up firms with fast growth and limited resources to invest in developing
technology.
After SaaS, the second-most subscribed service is IaaS or infrastructure-as-a-service. In this cloud model,
subscribers aim to extend traditional infrastructure resources such as storage, virtual servers, firewalls,
and software images cross an enterprise on a pay-as-you-use model. Many companies offer this service
today, including Amazon.com with its EC2, Microsofts Windows Azure Oracles Infrastructure as a
Service, and Googles Compute Engine.
The issues involved in selecting and managing this type of relationship will be addressed in Topic 9.1. For
now, you should recognize it as a related option to purchasing software licenses.

1
Scott Matteson,2012, TechRepublic, Blog. Access February 19, 2013:
http://www.techrepublic.com/blog/google-in-the-enterprise/googles-approach-to-big-data-is-
bigquery/1660
3.4 Acquisition of software and hardware
Learning objective
Prepare a basic request for quotations and a basic request for proposal, and evaluate vendor
proposals. (Level 1)
No required reading
Module scenario: Time for decisions that a minute will reverse
Your sister division has made a decision to buy rather than build a new ERP system. This is big news, and
everyone is excited, as this will be their first purchase of integrated applications away from the
homegrown collection of spreadsheets, databases, and manual reports that makes up their current
system. You have been asked to help them with the next phase: how to decide which vendor offers the
best software solution for their own particular needs. You meet with the decision team of five people.
First thing we need to do, you say after introductions, is to review the system requirements documents
that you based your buy-versus-build decision on. These are key to helping us know what you need the
new system to do, based upon the comparison and gap analysis to your current system. All five decision
team members stare at you. The controller, Mary, speaks, We didnt do up that document. We started,
but our division manager told us to stop wasting time, go and buy a new system, and get it in and
working. You text message your spouse about starting dinner without you, for at least the next month.
LEVEL 1
The process of selecting hardware and software starts with the identification of requirements and ends
with the purchase and installation of the selected hardware and software. Every step in the process is
important to ensure the selection of technologies that are both cost-effective and appropriate.
A critical skill for managers is to be able to manage the acquisition process. Whether you are buying
hardware or software, it is important to follow a comprehensive and fair process to ensure that you get
the functionality you require at the right cost from a vendor you can work with. While no simple formula
will guarantee success in every case, following the process outlined here minimizes the risks of failure.
Selecting information technology
There are six activities in the acquisition of information technology:
1. Research technical criteria and options.
2. Solicit quotations or proposals from vendors.
3. Validate vendor claims and performance.
4. Evaluate and rank vendor proposals.
5. Award contracts and debrief losing vendors.
6. Establish integration requirements.
1. Research technical criteria and options
The first phase represents a link back to systems analysis and to the overall design strategy. In systems
analysis, the functional requirements of the system are established (the requirements of what the system
should do and what business problem it should solve). In the early part of the design phase, further
decisions are made about this functionality. Will the solution try to achieve the minimum acceptable
features only, or will it be a high functionality solution? Which hypothesis best describes the possible
solution?
These questions go back to the trade-offs that must be made between time, cost, and scope in any
systems project. Based on these decisions, the criteria on which vendors will be judged can be
established. Some of these criteria relate to more technical aspects of functionality. For example, the
transaction volumes that must be handled by a system, the required database size, and access time are
all criteria that might be specified as technical requirements of a system. All these technical aspects, as
well as the more visible components as screen designs and ease of use, must all be taken into account.
Only that way can you measure the fit of vendor software to your own particular case.
2. Solicit quotations or proposals from vendors
After technical requirements have been identified, evaluated for technical feasibility, and approved by
management, the next step is to obtain technical specifications and cost information from vendors.
Depending on the complexity of the identified requirements, this step is usually performed using one of
two methods: request for quotation or request for proposal. There are many software applications to
assist in the design of the documents for this process. Depending on the complexity of your proposal,
these can be a tremendous help. Many vendors also just use Word to create the document and Excel to
weight and tally the responses.
Request for quotation (RFQ)
The simplest RFQ is a letter listing the hardware and/or software required and asking for a price
quotation. A more elaborate RFQ may be a document several pages long. Usually, an RFQ is quite
specific about the hardware and software required and requests only a price quotation and terms of sale.
For example, you may specify a brand of computer that is appropriate for the new system. You then send
out an RFQ to several vendors who can supply this make of hardware for the best possible price and
terms. The aim of an RFQ is singular. Vendors return quotes on the same hardware specification, and
usually the least expensive wins the bid.
An RFQ works reasonably well in such cases, provided that the specific hardware and/or software have
been identified. You may often identify hardware or software features, but not the specific hardware or
software products, because you may not be knowledgeable about the available products. In this case, a
request for proposal is used.
Request for proposal (RFP)
In an RFP, the hardware and/or software requirements are specified, and vendors are requested to
propose appropriate system components, terms and conditions, and support for maintenance. Once
proposals are received, they are evaluated according to certain established criteria. To respond to an RFP
properly, a vendor may have to expend considerable effort analyzing the specifications and designing a
proposed solution. Therefore, vendors do not usually respond to an RFP unless there is a reasonable
chance of making a significant sale.
Completing an RFP can take weeks. Many vendors are suspicious of the process and want to know the
seriousness of the request and as much about their competition as possible. A good analogy is that of an
Olympic bid. Teams spend months putting one together, sinking valuable time into the process, with no
guarantee that their response will be chosen. However, for companies seeking answers about software
and not just demonstrations, RFPs are an invaluable way to get them.
There are several reasons for using an RFP:
The process of specifying system requirements usually eliminates unnecessary features and
promotes more rigorous analysis.
With an RFP, each vendor receives the same information and the same set of specifications; all
vendors are on equal footing, making the proposals comparable.
Vendors understand the strengths and weaknesses of their products; an RFP gives them the
flexibility to recommend their best solutions.
The evaluation of vendor proposals using established criteria promotes objective selection.
Issuing an RFP tells the vendors that more than one vendor is being considered, thereby giving
you more negotiating leverage.
Vendors are given the opportunity to propose solutions of which you may not be aware.
Who should receive the RFP?
You should send the RFP to a carefully selected list of vendors. If you send it to too many vendors, an
excessive amount of information must be analyzed, and this could push the decision phase out by
months. Also, if the RFP is sent to vendors whose products are incompatible with either the new system
or existing equipment (which forms part of the new system), then it would be a waste of time for both
you and the vendor.
Although efforts are made to be open and fair in the requirements statement of the RFP, companies need
to have arbitrary readers review the document to make sure that questions do not unnecessarily favour
one vendor over another. Sometimes this happens purely by chance; sometimes team members have a
vested interest in choosing one vendor over another, before the selection process has been properly
validated. Favouritism in the RFP bidding process is unethical.
It is important for managers to maintain only work relationships with vendors and not personal
connections. For example, consider a vendor who has kept in touch with a department manager for years
and taken the manager out for lunch and to after-hours events. When the vendor finally gets a chance to
bid on software, there is a possibility that the manager in question could feel obligated to that vendor,
and consciously or unconsciously weigh the requirements in their favour. Companies need to ensure
proper guidelines and policies such as the review of purchasing recommendations by an independent and
knowledgeable third party are in place to prevent unethical behaviour.
Communicating requirements in an RFP
Although each RFP is unique in specifying the requirements of a particular system, all RFPs should
contain at least the following information:
brief description of the organization issuing the RFP, background information on why the RFP is
issued, and a summary of the requirements
description of the selection process you will be using to determine the successful bidder, including
schedule and selection criteria which helps prevent favouritism
instructions to the vendor, including due dates, the form of response required, where to send the
response, and the name and phone number of the person the vendors can contact for clarification
of the RFP
detailed description of mandatory requirements, grouped in some logical manner (such as
hardware, software, warranty, and support)
detailed description of critical requirements, grouped in the same manner as the mandatory
requirements
description of optional requirements, grouped in the same manner as the mandatory requirements
list of performance criteria, including processing speed, throughput, capacity, security, and
reliability
delivery and training requirements
target price range or budget information
detailed technical hardware questionnaire covering aspects such as the make of CPUs, type and
number of services, system configuration, processing speed, memory capacity, expansion
capability, storage capacity, access speed, communication capabilities, types and maximum
number of terminals or client PCs supported, processing speed of specific types of transactions,
backup and recovery capabilities, and so on
detailed technical software questionnaire, covering aspects such as programming languages used,
size of programs, availability and ownership of source code, error detection and correction
capabilities, file structures, access control and security, types of transactions handled, functions
provided, and so on
detailed systems software questionnaire covering communications, database management,
network management, and so on
detailed expectations of the vendor and how a successful partnership will be established between
the vendor and the organization to ensure that vendor remuneration is tied to the success of the
project implementation
It is important to request that each vendor supply information on its financial resources, technical
expertise, and performance ratings. An RFP should also require a list of references from the vendor.
Regardless of how superior the vendor's product may be, for long-term support and maintenance
reasons, you should make sure that the vendor is economically viable and technically competent.
Whether to use an RFP or RFQ
If the dollar amount in question is only a couple of thousand dollars and off-the-shelf software and
hardware are adequate, an RFQ can be issued instead of a detailed RFP. Few vendors are willing to
respond to a detailed RFP if the dollar amount is small; it simply is not profitable.
However, if a great deal of money is involved (tens or hundreds of thousands of dollars) and software
customization may be required, it is appropriate to use an RFP, particularly if the requirements are
unusual. An RFP can also be effective when many computers of the same type are to be purchased.
3. Validate vendor claims and performance
Once proposals have been received, their claims must be validated. You should check that the vendor
meets all the mandatory requirements using existing software products. Often, vendors will propose to
provide a solution that will use software that is not yet available, or is in the development phase. Ideally,
these vendors should be eliminated, because it is possible the software will not be released on schedule
and it is not available to assess whether it will truly meet your needs. Avoiding this unnecessary risk is
advisable.
At this stage, your goal is not to compare vendor proposals. You should focus instead on validating the
claims made by the vendors in their proposals. After the vendors' claims are validated, you can evaluate
and rank the vendor proposals (Activity 4). At this point, you can compare the remaining vendors'
proposals.
4. Evaluate and rank vendor proposals
You can evaluate and rank vendor proposals using different methods. Whichever method is employed,
the goal is to findthrough a series of weighted responseswhich vendor is closest to meeting your
system requirements.
Vendor responses to mandatory requirements
The simplest method is to create a table of all the mandatory requirements and then place the responses
from each vendor in this table. If this process eliminates all vendors, you may need to carefully review all
the mandatory requirements and ascertain that they are indeed mandatory. If no vendor can meet all the
mandatory requirements, it may mean that the required system is technically unfeasible.
The value of the gap analysis in the RFP cannot be overstated. It forms the basis of the requirements of
the new system, and helps both the vendor and the customer reflect on these requirements on equal
terms. Without the gap analysis as the core document an RFP will not be a proper reflection of all the
weighted demands the new system must fulfill.
Here is a simplified example, accessing the system requirements for a new training application. Required
functions for the gap analysis have been included in the RFP and vendor responses tabulated based on
function priority and weighting. The vendor with the highest score becomes the top candidate.
Exhibit 3.4-1

If more than one vendor meets all the mandatory requirements and there are no substantial price
differences, the selection of a vendor may depend on the responses to the optional requirements.
This raises an important consideration for developing an RFP: the more mandatory features you include
in your requirements, the smaller the set of vendors who will be able to respond. If mandatory
requirements are over-specified, it is easy to conclude that there is no system that will satisfy the
requirement.
A mandatory requirement is a threshold requirement. Any vendor that cannot satisfy this requirement
(directly or indirectly) should not be considered, no matter how good their application is on other
dimensions. Many organizations find that requirements initially thought of as mandatory are, in fact,
optional. That is, they can be traded off against other sorts of functions. It is important to think through
this distinction between the mandatory (must have) and optional (good to have) features before
completing the RFP in order to provide the greatest possible number of solutions.
Vendor comparison
Another method to compare the proposals that are retained is to create two comparison tables. In one
table, list the mandatory and optional requirements in the first column. Assign each of the other columns
the name of a vendor. Then, going down the column of requirements, write a summary of the vendor's
response under the vendor's name. In the other table, place the selection criteria in the first column and
your evaluation of how each vendor meets each of the criteria under the vendor's name horizontally. By
examining these two tables, you can quickly rank the vendors. The fairest method is that each selection
team member ranks the vendors individually, and then the rankings are averaged. If the team has 10
members with 10 rankings, you could also reject the highest and lowest ranks, as a way to make sure
that a high or low outlier doesnt skew the average.
Ranking qualified vendors
Any process to rank several qualified vendors should be unbiased and fair. The weighted evaluation
matrix is one of the techniques to rank vendor proposals.
1. Assign a numeric weight to each selection criterion, representing its importance. For example, a
critical feature may be assigned a weight of 100, while a considerably less important one would be
assigned a weight of 10.
2. Evaluate each vendor's proposal against the selection criteria, and assign a numeric score based
on how well the vendor's solution satisfies the criteria. For example, vendor A may receive a score
of 10 for meeting all the requirements of a particular criterion perfectly, while vendor B may
receive a score of only 3 for not meeting the same criterion.
3. Multiply each score by the numeric weight assigned to each of the corresponding criteria, resulting
in a weighted score.
4. Add all the weighted scores together for each of the vendor proposals. The vendor proposal with
the highest total weighted score is selected for detailed investigation and contract negotiation.
Exhibit 3.4-2 shows another example of such a process. Based on the total weighted score, Vendor C's
proposal should be investigated in detail.
Exhibit 3.4-2

Before making a final decision, it is important to conduct hands-on testing of the selected vendor's
proposed solution configuration. The vendor must demonstrate that the system components can in fact
perform what is claimed in the proposal. A demo of the application in action is one way; a trial period
with the application installed in a test environment is another.
Finally, when ranking potential vendors, you should consider ethical issues, especially conflicts of interest.
Example 3.4-1 illustrates such a scenario.
Example 3.4-1: Conflict of interest
Henri, a CGA, has been hired as a consultant to acquire a new inventory system for Alliance Chemicals.
There are three main vendors, as indicated in Exhibit 3.4-2, with the same evaluation criteria. Clearly,
Vendor C appears to be the best supplier.
Henri has another reason for choosing Vendor C. Vendor C has offered Henri an expensive new laptop for
his own use if it is selected for the contract. Since he will be working extensively with both the vendor
and the acquiring firm, he feels that the PC is necessary to the project. Henri is quite convinced that his
choice of vendors has been totally objective and he hasn't been influenced by Vendor C's offer of the
computer. He decides to recommend that Alliance purchase the system from Vendor C.
He also decides not to mention Vendor C's offer of the laptop to Alliance. Henri reasons that (a) his
decision was objective, and (b) Alliance is getting the best system at the best price.
Henri has put his own interests ahead of his clients. In doing so, he is in violation of the Trust and Duties
principle in CGA-Canadas Code of Ethical Principles and Rules of Conduct which states: "Members shall
act in the interest of their clients, employers, and interested third parties, and shall be prepared to
sacrifice their self-interest to do so. Members shall honour the trust bestowed on them by others, and
shall not use their privileged position without their principals knowledge and consent. Members shall
strive to be independent of mind and in appearance." See Rule 202.3 (a) for specific guidance on this
ethical issue as it relates to Henri. It is easy to deceive oneself about objectivity in the face of substantial
"gifts" for procurement. Henri should disclose, in writing, the offer of the laptop to Alliance, and excuse
himself from the ranking process.
5. Award contract and debrief losing vendors
Once a successful vendor has been chosen, the process of awarding the contract must be undertaken
with care. Most standard contracts from vendors favour the vendor, so if they are accepted without
amendment, the purchaser may be at a disadvantage.
To ensure that the vendor delivers the components specified in the proposal, either the vendor's proposal
should be included as part of the legal contract or the major items of the proposal should be included in
the legal contract, to ensure that the vendors promises become binding. Consider negotiating a contract
that places the onus on the vendor to deliver what is promised in the RFP. After all, obtaining the right
solution for the right amount of money is why you sent out the RFP in the first place. You will study
contract negotiation in more detail in Topic 3.5.
After awarding the contract to the successful vendor, notify those vendors who were not successful. A
debriefing session with each unsuccessful vendor can also be conducted. Unsuccessful vendors deserve
to receive proper notification of the RFP results because they probably spent just as much time and effort
responding to the RFP as the successful vendor did. Remember that you may be dealing with these
vendors in the future for other projects. Good business practices dictate appreciation to vendors for
taking the time to submit, and an explanation for why their bid did not win. This doesnt mean you share
with them the details of your ranking processthis is not an opportunity for them to challenge your
numbers. You acknowledge their effort and the time it took to submit.
6. Establish integration requirements
The final activity in the selection process is to review the integration requirements. Once a vendor is
selected, it is possible to consider the new solution as it relates to existing systems and clarify precisely
how they are to be integrated. This step represents a further assessment of feasibility and provides a
chance to revise the budget for the project. Note that integration requirements would have been included
as part of the initial RFP.
3.5 Vendor selection and contractual issues
Learning objectives
Determine the challenges in selecting vendors for information systems and approaches to
minimizing problems in vendor relationships. (Level 2)
Plan the contract negotiation process, and explain the key clauses in a hardware or software
contract. (Level 2)
Required reading
Reading 3-1: Contracting for Computers
LEVEL 2
One of the activities of the acquisition phase is the successful completion of hardware and software
contracts. Regardless of how carefully you have made the selection, if the contracts are not carefully
worded, the project may still be unsuccessful. Although you should always consult legal counsel before
completing contract negotiations, a basic understanding of typical clauses used in hardware and software
contracts is helpful.
Reading 3-1 provides two useful checklists: one for hardware purchases, the other for a software license.
Another reading, Checklist 12, has not been included in Reading 3-1. Here is a summary of the contents
of Checklist 12:
Use an RFP/RFQ for all acquisitions, regardless of size.
Check out suppliers and check references.
Choose a supplier.
Use a letter of intent if necessary to arrive at terms and conditions prior to contracting. Ensure
that the letter of intent does not bind either party and that all deposits are refundable.
Determine an appropriate form of agreement. Where standard form agreements are used,
inappropriate clauses should be amended or deleted.
Read through Reading 3-1 before continuing with this topic.
The negotiation and preparation of a contract after a proposal has been selected must be handled with
great care. Different jurisdictions have different laws governing contracts. The information provided here
is general and should be used in conjunction with applicable laws and statutes.
Contract negotiation
Contract negotiation starts with the selection of a vendor at the end of the RFQ/RFP process. It is
preferable to draft a contract that is specific to the circumstances rather than use a standard contract
supplied by the vendor. However, if the vendor has a corporate policy of using its standard contract,
negotiate an addendum to the standard contract to suit your requirements. Remember, for both parties,
the contract is a negotiation. Never accept a contract out of hand.
Who handles the contract negotiation?
A number of people can be involved in contract negotiation. For contracts involving relatively small
amounts (that criterion depends on the size of the company), one of the senior analysts or the project
manager can handle the negotiations. If the contract involves large sums, or has strategic importance to
the company, a senior manager may handle the negotiations. Usually, the corporate lawyer is involved
near the end of negotiations to make sure that the final contract wording is appropriate and the interests
of the company are well protected.
Negotiating a contract through high-ranking managers is usually beneficial because it indicates to the
vendor the importance of the contract to the organization. The vendor is then pressured to use higher
ranking personnel in the negotiation process also. Negotiating with low-level personnel often leads to
delays. However, contract negotiations with high-ranking managers alone sometimes turn out poorly
because this level of management may not appreciate the technical nuances of the contract. For this
reason, some organizations use a negotiating team or consulting resources.
Approach to contract negotiation
Many contract negotiation techniques are adversarial. Although the adversarial approach may work in
some cases, it is not necessarily the right approach particularly if the negotiation team includes
individuals that your organization will be working with on the project. In many instances, if both sides to
the contract negotiation reach a mutually beneficial agreement, the chance of satisfactory performance
by both sides is much better. However, if the vendor takes an adversarial approach, it may be necessary
to adopt a similar stance to protect the interests of your company. Both sides should approach the
contract as an exercise in negotiating a win-win scenario. Bad feelings toward each other at this stage
can cause animosity, which makes it difficult to work together on a project that may take months or
years to complete. Contract negotiations highlight why more than one vendor solution must be assessed:
the right solution may not include the right people, so there should always be another vendor to consider
if contract talks reach an impasse.
Letter of intent
Because the actual contract negotiations may take some time to complete, it is common to sign a letter
of intent as a signal that both parties are willing to enter into an agreement. A letter of intent is not
legally binding, but it sets out the general terms and conditions for the contract to be negotiated.
Identify key areas in the contract
Before you embark on the negotiation process, identify the major items that must be included in the
contract, including the purpose of the contract, substantive performance criteria, and any extraordinary
conditions that must be included. You should also identify areas that you may be able to concede if
necessary to reach an agreement. Finally, identify areas that you believe the vendor may be able to
concede and that are advantageous to your company.
Maintaining control in the negotiation process
It is important to maintain firm control of the negotiation process. From an adversarial standpoint, no
concession should be made without some compensating concession from the other party. It is always
good practice, even if you have full authority to negotiate, to defer to some higher authority during the
negotiation process. There are two benefits:
Deferring a decision to a higher authority provides time to think through the implications of a
particular clause without having to make a rash decision during negotiation.
It provides a means to save face and modify the clause under negotiation should modification be
necessary.
Although it involves more work, it is generally better to draft the contract clauses as agreements are
reached. Generally, the party who drafts the clauses has more control over the actual wording of the
contract.
Contract clauses
Hardware and software contracts are drawn up to completely reflect the agreements reached by both
parties. However, most hardware and software contracts contain certain clauses that are specific to such
types of contracts, such as intellectual protection, warranty, and escrow of source code. There are also a
number of standard administrative clauses usually found in such contracts. These are not considered
here.
The following are specific clauses typically found in hardware and software contracts.
Intellectual property
This type of clause deals with patents, copyrights, trade secrets, and other proprietary rights. Vendors
always insist on a clause that protects their interests in the intellectual property contained in their
hardware or software.
Indemnity
This clause should specify that the vendor will hold your company harmless (that is, free from
responsibility) against any and all infringement of patents, trademarks, or copyrights that may be caused
by the vendors hardware or software. This clause should also state that the vendor will pay for (or
indemnify) your company for any legal action arising from such infringement.
In simple terms, this clause should specify that if there is any lawsuit arising from any claim that patents,
trademarks, or copyrights have been violated, the developer will hold your company harmless against any
and all claims. Without such a clause, your company could be liable for any patents, trademarks, or
copyright infringements arising from any of the programs written by the developer.
The scope of indemnity should cover all damages, expenses, and settlement costs, including reasonable
legal fees, and not just damages finally awarded by a court.
Denial of liability and fitness for purpose
Most standard hardware and software contracts contain some form of denial or limitation of vendors
liability and fitness for purpose. That is, the vendor typically wants to have no responsibility for its
hardware or software being suitable for your particular use. Such clauses may have to be modified to fit
the particular circumstance. For example, it is probably acceptable for general-purpose computer
hardware and software contracts to contain such a clause. However, if a particular piece of hardware or
software is described by the vendor to perform a specific task, such denial or limitation must either be
removed from the contract or the extent of limitation of liability clearly stated.
Warranties
Most vendors try to limit their warranties. The warranty clause must be carefully worded to clearly state
the extent and the length of the warranty.
Maintenance
This clause should specify how the system would be maintained or supported after the hardware or
software warranty period, and at what cost. This clause ensures that the system will be supported and
also keeps support costs to agreed limits.
Survival beyond term
Contracts usually have specific terms with starting and ending dates. However, it is advisable to insist
that all clauses that deal with performance representations survive in perpetuity (that is, extend beyond
the life of the contract). Similarly, vendors usually insist that terms dealing with intellectual property
protection, confidentiality, and liabilities extend beyond the term of the contract.
Arbitration
A clause referring disputes to binding arbitration is desirable. This clause should specify the exact
mechanics of the arbitration process and should include a specific reference to the applicable arbitration
rules. An arbitration clause can prevent unnecessary litigation arising from contract disputes. There are
many forms of arbitration clauses, ranging from clauses that deal with disputes under a certain dollar
amount to disputes involving non-urgent items. Without an agreed form of arbitration, implementation
projects can stall, resulting with timelines, deliverables, and financial benefits being shattered.
Bankruptcy and sale of business
A clause should be included to specify the remedies in case the vendor decides to sell the business or is
forced into bankruptcy. Remedies range from termination of the contract at your companys option to
rights and title transfer of software and hardware from the vendor to your company.
Escrow of source code
This applies to a software contract that does not provide you with access to the source code for software
that is custom-made for your company. It is important to include a clause that requires the vendor to
place the most current copy of the source code with an independent escrow agent, who will release the
source code upon bankruptcy of the vendor. This way, your interest in the software is protected.
Most favoured nation
It is important to include a clause in which the vendor agrees to pass on to your company the best terms
offered to other customers. This type of clause is called a "most favoured nation" clause. Generally,
vendors are unwilling to include such a clause in a contract, citing undue restriction of their future
business transactions as their reason.
Termination
A clause that allows either party to elect to terminate the contract if the other party fails to perform
should be included. The conditions under which such a termination clause can take effect must be
specified in detail.
Force majeure
This clause deals with events beyond the control of either party. Events cited usually include natural
calamities, strikes, civil disorders, riots, wars, and acts of God. Such a clause exempts either party from
the performance requirements of the contract during such events. That is, non-performance during such
events does not constitute a violation of the terms and conditions of the contract.
3.6 Project management
Learning objectives
Evaluate the issues and challenges in managing IS projects. (Level 1)
Compare the techniques of PERT and Gantt charts and define their role in project management.
(Level 1)
Design simple PERT and Gantt charts. (Level 1)
Required reading
Chapter 10, Sections 10.2, The Importance of Project Management, and 10.5, Managing Project
Risk
LEVEL 1
The successful management of every aspect of a project depends on proper project management.
Successfully managed projects have the following characteristics:
careful estimating realistic timelines, achievable milestones
close monitoring knowing the status of every task in the project, and the impact of a constraint
before it hits the project
flexibility in dealing with problems the ability to modify the project to accommodate unforeseen
obstacles, yet keeping a positive attitude that pushes the project forward
Project uncertainties
One of the most daunting problems of systems development is the high level of uncertainty associated
with systems design and programming activities. During the initial phases of a project, the project
manager has little idea of the cost or time required to complete the project. An experienced project
manager draws on past project experience and develops a feel for the scope and complexity of the
current project. This experience will help more with similarities than with differences.
To fully commit to a timetable and budget at the systems analysis phase of a project is nearly impossible.
There are simply too many uncertainties in the development of a system. For example, it is difficult to
estimate the total time required for systems analysis because so much depends on the problems
uncovered. Also, the goal of the project must be phrased in terms of a business case, with a real problem
to solve. This way, the project will develop into more than just a series of requirements it will present
a hypothesis from which to build a solution, by testing it through specific, iterative, development cycles.
The design phase is no more precise. Again, the time and cost required depend on the problems
encountered. Given a systems design, programmers must interpret the specifications and write the
programs to fit them. It is almost impossible to forecast the time required to write and debug a program,
which depends on many things, including the ability of the programmer and the clarity of the
specifications. Unexpected programming issues will always arise, and must dealt with as they are
identified.
The project manager's task, then, is to reduce all these uncertainties and attempt to meet some targeted
deadlines and budgets. The safest course of action from this perspective is to delay committing to
deadlines and budgets as long as possible, or at least until realistic parameters for the project have been
set. However, as a project manager, you may not be given this option.
Management (or users) must know the time and cost of the project as early as possible. Many
management techniques have been used to reconcile these two extreme positions. These techniques are
covered next.
Keeping the project on track
The cost of an information system is one of the largest commitments a company can make. When
revisions or replacements to the system are necessary, an organization wants to place the best people
they have to manage and monitor the progress. IS departments have recognized the need for skilled
project managers, and like other departments have adopted certifications as PMP (project management
professional) to their own needs. Along with the more traditional IS skills, project management skills are
also seen as a must.
As a project manager, you can use a number of different methods to keep a project on track.
Impose timetables and budgets
Management may choose to impose timetables and budgets, but this method has never had much
success. In some cases, applying this technique only leads to disaster. Given management-imposed
deadlines, project managers, analysts, and programmers cut corners, resulting in systems that are
riddled with problems and difficult to maintain. In many cases, management discovers that it has traded
short-term gain for long-term pain that never lessens. When management imposes deadlines and
budgets, particularly if they are unrealistic, analysts and programmers often feel no responsibility for the
resulting inadequate system.
Negotiate deadlines and budgets
More enlightened managers negotiate deadlines and budgets with their project managers. This method,
though superior to the preceding one, is still not perfect. It is difficult for management to negotiate on
things of which it has little understanding.
For example, if a programmer estimates that a particular computer program takes four weeks to develop
and test, how can a manager without any IS experience challenge that estimate? If the programmer's
performance is measured by how well program development deadlines are met, there is an incentive for
the programmer to overestimate. After all, if a program is finished early, there is always room to polish
the program until the allotted time is used up. This is why most IS project managers come from the rank
of systems analysts, so that knowledge of development comes with them.
Senior management, in negotiating with project managers, is often at a disadvantage. It is the project
manager's responsibility to meet the negotiated target deadline and budget as closely as possible.
However, many project managers either under- or overestimate the scope of the project. Either can have
a significant economic impact on the value of the project. Systems development is notorious for cost
overruns and delays.
Creeping commitment
The creeping commitment approach is part of many systems development methodologies. It is often
called a stage and gate process. The principle behind this method is sound enough. The scope of a
project can be compared with walking toward an object that is far away. During the initial stages, the
object is just a speck on the horizon. The traveller can map out no more than a day or so of the journey
and can barely describe the target object. By moving forward in the direction of the object, a clearer
picture emerges. The traveller is better able to visualize the size and shape of the object, to estimate the
time required to reach the object, and to determine the best approach.
Instead of committing to a fixed delivery time and budget at the initial phases, you would estimate the
total time required and costs to be incurred. At each phase of the project, you commit to delivery of the
next phase and revise the estimate for the total time and budget. Management can decide to continue or
discontinue the project at any milestone (phase), after re-examining the projects feasibility.
The challenge with the creeping commitment method is senior management's uncertainty about the full
scope of any project. But if uncertainty is the cost of a higher degree of success, it may be worth the
discomfort.
Appoint key users as project managers
Some organizations appoint key users to manage systems development projects, with the project
manager appointed from the ranks of user departments. This method is meant to provide users with
more control over systems development. Because most users do not have detailed technical knowledge,
the project manager is usually assisted by a senior analyst to assess progress and manage the project.
A user, as project manager, still exercises a certain amount of control over the project. For example, the
user is apprised of milestones and progress. Where there are difficulties in meeting deadlines, the user
project manager can assist in identifying or allocating additional resources to the project.
User-managed projects have not met with much success, primarily because it is difficult for non-technical
users to challenge the project information provided by technical systems staff. Users are better on the
team than as project managers. Project management is a skill, not just a title.
Evaluate productivity of analysts and programmers
To keep projects on track, a project manager must allocate tasks to analysts and programmers, but this
cannot be done accurately without some means of assessing the team members productivity. This may
prove difficult at times. Many management techniques have been tried, including tangible measures such
as the number of pages of design documents written, the number of data flow diagrams drawn, and the
number of lines of code written per day. Intangible measures include user satisfaction and maintainable
code. These measures are hard to quantify and even more difficult to evaluate. And they dont equate to
a magic number that equals success.
The performance of individuals also varies greatly. Some programmers are very quick, and some are very
accurate. Some produce simple code, while others use complicated logic to achieve the same result.
Without previous programming experience, there is no means for a project manager to estimate how
much time a particular program will take to produce. A good project manager usually has a feel for the
productivity and style of each team member and factors these considerations into the project schedule.
Also, a good project manager realizes when there are enough programmers dedicated to the project it is
a fallacy that more programmers equals faster, better results. Too many programmers can lead to more
time spent coordinating code rather than writing it.
Factors for success
Ultimately, the project manager must depend on the cooperation of the technical staff. The critical
management issue of project management is not the development of Gantt or PERT charts. Rather, it is
the motivation and management of people. A major soft skill is communicating with all team members
every step of the project, and in multiple ways. Here are a few factors known to promote IT project
success:
Analysts and programmers must be motivated to estimate as accurately as possible. Errors in
estimates, made in good faith, should not be punished but revised.
Technical staff must be included in planning; they must understand the need for tracking the
milestones of a project and agree with the method used.
Teamwork must be encouraged and be integrated into the day-to-day activities of all staff.
When a schedule is not met, the project team should be consulted on remedial action before it is
taken.
Target completion dates must be realistic and mutually agreed on with the technical staff.
The cooperation of users is critical to the success of a project. Regardless of how well planned a
project is, without user involvement and support, the development of a new information system
will be difficult and may fail.
Factors for failure
In spite of applying various techniques and controls, projects do fail, and often. Common characteristics
of failed projects are:
unfulfilled or unidentified requirements and needs
cost overruns
late delivery
project distortions: personal agendas, bad decisions
lack of action on initial trouble warning signs
lack of management support
poor communications
Often the problems of a failed project can be traced back to the start of the project when the
requirements should have been sufficiently established. Projects with imprecise and unrealistic
requirements will not achieve the goals that were originally defined. Resolving missed requirements leads
to cost overruns and missed schedules. Bad estimating on either the cost or schedule or both will also
lead to project failure.
Another common pitfall is the so-called creeping requirement syndrome (or "scope creep"). This may not
be the fault of the users. It is not unusual for users to discover new requirements and features as the
analysis proceeds. The only way to deal with creeping requirements is to immediately document the
impact of these changes to the scope of the project. Here, a project repository, a central location
where all documentation pertaining to the system is maintained, is indispensable. Having a central
location for documentation makes it easier to track the impact of proposed changes.
In addition, project management software has matured to more than simple task tracking. Portfolio
management, linking projects to strategic requirements through cost and build, and project/document
repositories are now common features of many project software solutions. The project manager should
determine which software provides the best tracking, reporting, and integration features, and to select
the software accordingly.
Depending on the importance of the project to the business, a failed project could result in more than
cost overruns or late delivery. It could result in shattered careers or complete business failure! It is
therefore important to understand why projects fail and take appropriate action to prevent failure in
future. Exhibit 3.6-1 represents the relationship between time, cost, and quality or scope.
Exhibit 3.6-1:

A change in one of the factors means a change in the others. For example, if you want to finish a month
sooner, you will need to reduce the scope of the project or increase the budget, sometimes both. This is
an important diagram to keep on hand for all projects, and it is critical to understand that the centre of
the triangle relates to the quality of the delivered project solution. Understanding the relationship
between time, cost and quality or scope, and the trade-offs required to balance these successfully, is an
important skill for a project manager.
Project management tools and techniques
One of the most critical factors in managing projects is timekeeping. It is very common for information
systems projects to be significantly overschedule. Various tools and techniques exist for documenting the
project activities and their timeframes. Such tools are used to describe the tasks in the project, clarify the
dependencies between tasks, provide additional information to support resource allocation decisions, and
monitor and manage the overall schedule. The two most common techniques used by project managers
to plan, monitor, and control projects are PERT charts and Gantt charts. There are many software tools
that help in the creation and support of these charts. Microsoft Project is only one choice. There are
hosted versions like Clarizen, AtTask, Basecamp, and Huddle, and open-source versions such as
Endeavour or Codendi (originally Xerox). Wikipedia offers a consolidated page of project management
software.
PERT chart
PERT charts are graphical tools that show the activities that make up a project, the dependencies
between activities, and the times required to complete the activities. They allow you to determine the
critical path the sequence of activities that must each be completed on time in order for the project as
a whole to be completed on time. Knowing which activities are on the critical path allows the project
manager to focus on the critical activities. Because any delay in completing these activities will result in
project delay, critical activities may be allocated more resources than activities that have some slack in
their deadlines.
Activities in a PERT chart
A PERT chart shows the project manager the organization and coordination of tasks in a project.
Activities are represented by arrows, and the events that mark the completion of activities are
represented by numbered circles called nodes. Generally, adding up the times on the arrows tells you
how long you are expected to take to complete the sequence of activities, although software does this
automatically. Project management software also shows the tasks as rectangles, with the following
attributes Task name, sequence number, days required to complete the task, and the task scheduled
start and end date. Arrows connect the tasks to one another in sequence, and the critical path is often
represented in red.
When you develop systems, however, there are activities that can be done in parallel. For example,
system testing can often be done in parallel with the development of training materials, and installation
and training are often done concurrently. But the tasks that happen in parallel don't necessarily take the
same amount of time. Slack then exists on the path between shorter duration activities. Drawing PERT
charts is a good way to see which activities are critical to project completion because they have no slack,
and which have less impact on the overall schedule. Figure 3-8 on page 333 in the textbook shows an
example of a PERT chart.
How to construct a PERT chart
Most software today has the ability to create PERT charts. However, creating a PERT chart by hand will
give you a better understanding of how software does the same task. There are six steps to constructing
a PERT chart:
1. Break the project into individual activities. The activities should be listed as a step-by-step series,
with an identification number and a description for each. When determining the activities, you
must decide the appropriate level of detail to use. For example, test the system might be one
activity, or it could be broken down further into test the hardware, test the software, and test
the database three individual activities. The results of this step, and the following two steps,
are normally presented in a table.
2. Determine precedence relationships. For each activity, you need to determine which activities must
precede it and which can be done simultaneously.
3. Estimate the duration of each activity. Often this is simply the project manager's best estimate of
the duration of each activity. It may, however, be done with more precision by identifying the
most likely duration, an optimistic estimate, and a pessimistic estimate. Then determine the
expected duration using a formula that weighs the most likely estimate more heavily than the
other two.
4. Draw the PERT chart.
5. Derive the earliest completion time (ECT) and latest completion time (LCT) for each event. The
earliest completion time is the earliest time that the event can be completed, given the precedence
relationships and expected time durations of all activities leading up to that event. The latest
completion time is the latest time that the event can be completed without delaying the
completion time of the project as a whole.
6. Determine the total estimated time for the project and the critical path. These elements can be
determined through analysis of the finished PERT chart.
Gantt chart
Like the PERT chart, a Gantt chart is also a graphical tool, but it shows the activities in a project as a
series of horizontal bars. Gantt charts help project managers see dependencies and relationships between
activities. The length of the bar depicts the amount of time the task is expected to take. Its location
illustrates the expected start and end dates of each task. The key to a Gantt chart is the activities. A
project manager must be able to identify all activities that relate to a specific task. Without this, you
cannot properly estimate the length of a project or determine its true cost. Gantt charts are popular
because they are easy to prepare and interpret.
There are five steps to constructing a Gantt chart:
1. Break the project into individual activities.
2. Estimate the duration of each activity.
3. List the activities down the left side of the chart.
4. Set up the horizontal axis of the chart as a calendar timeline.
5. Draw horizontal bars to represent the activities. For each activity, the length of the bar represents
the estimated duration and the end points of the bar correspond to the activity's start and
completion dates.
Notation is often added to Gantt charts to show who is responsible for the activity. A completed Gantt
chart illustrating these features is shown as Figure 10.7 on page 332 of the textbook. Notice in the text
figure that Gantt charts clearly show overlapping tasks those tasks that can be performed
concurrently. By referencing the current date on the horizontal axis of the Gantt chart, you can easily see
which activities are ahead of or behind schedule.
A variation of the Gantt chart is the milestone chart. In a Gantt chart, individual tasks are indicated within
the framework of a time schedule. In a milestone chart, only the important events (milestones) are
indicated within a time schedule. The milestone chart enables the project manager to focus on the major
events rather than the actual tasks. Sometimes a milestone chart is overlaid on a Gantt chart to provide
information on both the tasks and the major events. Again, most project software allows multiple views
of the project, including PERT, Gantt, milestone, resource, and many others.
Comparing PERT and Gantt charts
PERT charts and Gantt charts are not mutually exclusive. Usually, PERT charts are used to plan the
project, while Gantt charts are used to monitor progress. Because Gantt charts provide an easy-to-grasp
visual image, they are often used in reporting progress to senior management. However, Gantt charts are
more suited to smaller projects than large. The larger a project is with more dependencies, the more
complex it becomes to interpret and track using a Gantt chart.
PERT charts are better in the planning stages because they do a better job of representing the
relationships between activities that are critical to the project schedule. However, PERT charts alone can
underestimate the actual risks in the project.
It is always important that more than one tool be used to monitor the progress and status of a project.
3.7 Feasibility and cost-benefit analyses
Learning objective
Support a decision to continue or abandon a project using feasibility and cost-benefit analysis.
(Level 1)
No required reading
LEVEL 1
Feasibility and cost-benefit analyses are integral to systems development. You should ensure that there
are feasibility checkpoints throughout the systems development life cycle. As the project proceeds,
feasibility and cost-benefit analyses can be done with greater precision to reduce uncertainty. Also, at
various checkpoints, the project can be cancelled if the analysis becomes unfavourable.
Feasibility analysis
Feasibility analysis is concerned with the likelihood that a system will be completed in a way that will be
valuable to the firm. It includes an assessment of technical feasibility, organizational feasibility, financial
feasibility (or cost-benefit), and schedule feasibility as the main areas. Alternate feasibility studies can
also include legal feasibility, resource feasibility, and market feasibility (where applicable).
Feasibility analysis is generally considered to be part of the systems analysis phase (or an initial
investigation phase). It is the first analysis that says whether a project should be undertaken. But
feasibility assessment should not stop there. Periodic reassessments should be undertaken at each major
systems development milestone to ensure that the project has not become infeasible in a particular
measure, as it progresses.
The concept of sunk costs, which is taught in management accounting courses, is relevant to the periodic
reassessment of major systems development projects. If a project is deemed infeasible at any point in
the process, it is best to halt development rather than continue work, regardless of the resources that
have been expended on the development effort so far. At this stage, the existing deliverables and
components of the discontinued project should be examined to see which might be used toward
continuing or future projects. Often, an un-biased third party is the best person to assist an organization
in halting an infeasible project because they have no vested interest in the outcome, and can properly
assess the investment without emotional ties.
Technical feasibility
Technical feasibility considers whether the system's goals can be achieved with currently available
technology. It is based on the system requirements, and its goal is to determine that the company has
the capability (resources, software, hardware) to complete the project. For example, suppose you are
designing an e-commerce application for customer service that includes real-time video as an essential
element of the system. But customers are largely in rural areas and the required bandwidth to provide
real-time video over the Internet to these users is not available to make this application workable at the
present time. As a result, this project would be considered infeasible from a technical perspective.
Organizational feasibility
Organizational feasibility considers the capabilities of the company that is adopting the new system and
whether it is possible for the company to do so.
As another example, consider a company that has never used personal computers (PCs) on the shop floor
before. While it may be surprising, there are many organizations today that still do not have 1:1 ratios of
staff to PCs. Staff have limited capabilities with respect to using computers and lack sophistication in the
application of IT to organizational needs. This was the situation facing Rich-Con Steel, a family-owned
steel company in Kansas City.
1
Recognizing the need for better management information, the company
embarked on a project to implement a material requirements planning (MRP) system. But the staff, long-
serving employees with limited formal education and no previous exposure to computers at work, were
unable to cope with the changes brought about by the new system. Ultimately, the system was a failure.
Failure to consider organizational feasibility was one of the problems that led to this failure. However, the
conclusion should not be that you don't introduce new systems into such an organization. Rather, it
suggests that when you identify a problem with organizational feasibility, you should take steps to
overcome the issues.
Rich-Con could have introduced PCs into the workplace before the new system was introduced. The
company could have made the computers available to staff on lunchtimes and coffee breaks for games,
e-mail, web surfing, and other applications of personal interest. It could have provided training to staff on
how to use this technology for these purposes, which would have made it easier later on to introduce the
new MRP system.
Economic feasibility
Economic feasibility considers whether the project is cost-effective.
At the beginning of most major projects, the costs are relatively difficult to estimate with any accuracy.
As the project progresses, however, the project manager and the project team are better able to put
dollar values on specific system requirements. These values must be weighed against the perceived
benefits of the requirements. This process is also known as cost-benefit analysis, which compares
development and operational costs against the proposed benefits.
Schedule feasibility
Schedule feasibility considers whether the system can be completed in the amount of time available.
Every project has a payback period, a timeframe in which the project must be completed for it to be
useful. This was a critical consideration for companies in dealing with the Y2K problem. In these projects,
the deadline was absolutely immovable. Some possible options for system redesign would have been
rejected if they did not meet the necessary schedule. Other examples include times when systems need
to be redesigned to comply with new regulations or legislation effective on a certain date (legal
feasibility). Another time-based study to consider is when the future value of the project investment is
measured against the time required to complete the project.
Why this matters to accountants
Feasibility studies are about more than just costs. Often accountants are only involved in the financial
aspects of feasibility, but it is beneficial to understand that a balance between costs, organization,
technical, legal, and resources are all required to test the likelihood of a projects potential success.
Feasibility is a continuous assessment of constraints on a projects success. A focus only on costs can
result in failed implementations. The people side of the feasibility must be represented at least equally.
No matter how great the potential savings or profit from the investment, if the idea isnt feasible, in all
senses of the word, then project success is doomed.
Cost-benefit analysis
Cost-benefit analysis involves an assessment of the economic feasibility of the system. Is the system
worth the costs that will be required to develop it? Section 10.4 in the textbook in (required reading for
Topic 2.4), describes different ways of assessing financial feasibility for IS projects. You may want to
review this reading now.
As you learned in Module 2, the most troublesome aspect of cost-benefit analysis is measuring the
intangible benefits of computer systems. One way to measure intangible benefits is to express them in
monetary terms. This technique is not always satisfactory because monetary values assigned to
intangible benefits can be arbitrary, and these measurements can make a significant difference between
accepting and rejecting a system proposal.
Another approach is to use a tangible benefit as a substitute for the intangible benefit. For example, if
one of the benefits of a new system is improved staff morale which is hard to quantify the number
of casual sick days might be used. (Casual sick days are the one or two occasional sick days taken by
employees, which require no doctor's note.) The implied association is that if staff morale is high, there
will be less absenteeism. This is a good example of validating intangible benefits. Although the reduction
in the number of casual sick days is an estimate, the dollar value for each casual sick day can be
calculated with accuracy.
CIO magazine published a 2003 article entitled Intangible Benefits Can Play Key Role in Business Case,
available for review online.

1
McAfee, A., "Rich-Con Steel," Harvard Business School Case 9-699-133, January 27, 1999.
Module 3 self-test
1. Briefly describe waterfall and iterative (prototyping) systems development methodologies. When is
it most appropriate to use each one?

Solution
2. It has been said that most systems fail because system developers ignore organizational behaviour
problems. Why might this be so?

Source: Kenneth C. Laudon, Jane P. Laudon, and Mary Elizabeth Brabston, Management
Information Systems: Managing the Digital Firm, Fifth Canadian Edition (Toronto: Pearson Canada,
2011), page 338. Reproduced with permission from Pearson Canada.

Solution
3. Explain how project management software tools contribute to successful project management.

Source: Kenneth C. Laudon, Jane P. Laudon, and Mary Elizabeth Brabston, Management
Information Systems: Managing the Digital Firm, Fifth Canadian Edition (Toronto: Pearson Canada,
2011), page 338. Reproduced with permission from Pearson Canada.

Solution
4. Identify the activities that take place for each step in SDLC: systems analysis, systems design,
programming, testing, conversion, and production and maintenance.

Solution
5. Read the case, "Canadian Gun Registry: A Boondoggle or Simply a Complex Project?," pages 340-
341 in the textbook, and answer questions 2 to 5 posed at the end.

Solution
Module 3 self-test solution
Question 1 solution
The traditional systems development life cycle (SDLC) or waterfall method is a very rigidly structured
method of systems development in which the project is broken down into distinct and discrete steps. You
can only advance to the next step once the previous step has been completed.
The waterfall method ensures tight control and identifiable milestones and deliverables.
The waterfall method is time consuming and is not very flexible.
Prototyping is an iterative form of systems development in which users try out different versions of the
system and the developers use the feedback to improve the system through revisions. It has less
structure than a traditional SDLC and is more responsive to changing conditions and to user demands
and needs.
It is harder to manage, especially for large scale projects. It is difficult to define the finished stage
because all systems could be just a little bit better.
Systems development
methodology
Waterfall Prototyping

With unclear user requirements: Poor Excellent
With unfamiliar technology: Poor Better
With projects that are complex: Good Good
With technology that is reliable (or
familiar):
Good Better
With a short time schedule: Poor Good

Module 3 self-test solution
Question 2 solution
System building efforts often fail because there is too much emphasis on the technology and not enough
attention to changes in organizational structure, job design, workflows, and reporting relationships.
Inattention to these issues often breeds resistance to a new system and may also produce a system that
is incompatible with the organization. Conflicts between the technical orientation of system designers and
the business orientation of end users must also be resolved for successful implementation of systems.
The success or failure of organizational change can be determined by how well information systems
specialists, end users, and decision makers deal with key issues at various stages of implementation.
Source: Adapted from Dale Foster, Instructor's Manual to accompany Management Information
Systems: Managing the Digital Firm, Fifth Canadian edition, Pearson Canada, 2001, Chapter 10, page
386. Reproduced with the permission of Pearson Canada.
Module 3 self-test solution
Question 3 solution
You can use special tools to help you manage the implementation of a new information system (internal
integration tools). The software features these capabilities:
Define and order tasks
Assign resources to tasks
Establish starting and ending dates to tasks
Track progress
Facilitate modifications to tasks and resources
Automate the creation of Gantt and PERT charts
Track the way changes in one aspect of a project affect others
These special tools will also help you communicate with everyone on the implementation team and in the
organization as a whole.
Source: Adapted from Dale Foster, Instructor's Manual to accompany Management Information
Systems: Managing the Digital Firm, Fifth Canadian edition, Pearson Canada, 2001, Chapter 10, page
385. Reproduced with the permission of Pearson Canada.
Module 3 self-test solution
Question 4 solution
Systems analysis:
o Your IT/IS strategy should align with the organizations goals.
o Planning and feasibility decisions are made.
o System requirements are set out.
Systems design
o This details how the system will work and identifies the needed components of the system.
Programming
o The system design is translated into a specific programming language.
Testing
o Does the new system meet the requirements that were set out in the systems analysis
phase?
Conversion
o Decide the best method for replacement.
o Replace the old system with the new system.
Production and maintenance
o Ensure that the new system is adopted, that the proper training has occurred, and provide
regular and ongoing maintenance and updates.
Module 3 self-test solution
Question 5 solution
2. Evaluate the risks of the registry project and its key risk factors.
Risks include:
Data integrity (is it accurate? is it complete?)
Cost (who should pay? Does it provide return on investment)
Benefits (how to measure? Can they be quantified?)
Security (can it be accessed improperly?)
Political (will it be supported regardless of government in power)
Key risks are those that relate to public safety (data integrity and security).
3. Classify and describe the problems the CFP faced in implementing its new registry system.
What management, organization, and technology factors caused these problems?
Problems included:
Incorrect (low) cost estimates
No champion
Technical issues (decision to develop software was costly)
Incorrect data submitted by registrants
No means to check accuracy of data
Complex user interface (forms) drove users (registrants) away and created
dissatisfaction
Change in management (government)
No clear benefits were demonstrated
Management: no clear champion; no oversight of project
Organization: change in management/government was disruptive
Technology: no security, poor user interface, no data integrity, complex software development
4. Describe the steps you would have taken to control the risk in this project.
Project was large (costly, impacted many people: high risk): Use formal planning and control tools such
as Gantt charts, and MS-Project.
Project was loosely structured (requirements not clear, no management oversight: high risk): Have
mechanisms to support external integration (high user involvement, from all user groups government,
law enforcement, community advocates, gun owners, lobbyists)
Technology experience (they used unfamiliar, custom software: high risk): use high internal integration
tools such as having good project leaders who also understand technology)
5. If you were in charge of managing this project, what else would you have done differently
to increase chances for success?
Keep strict control over budget
Use existing database software
Look at other countries successes/failures
Break project down into smaller modules
Have users involved in all stages, including testing/security
And, use tools described in question 4.
Source: Adapted from Dale Foster, Instructors Manual to accompany Management Information Systems:
Managing the Digital Firm, Fifth Canadian edition, Pearson Canada, 2011, Chapter 10, pages 391-392.
Reproduced with the permission of Pearson Canada.
Module 3 summary
Systems development overview and issues
Identify and describe the six activities of systems development.
Systems analysis:
o Make planning and feasibility decisions.
o Set out system requirements.
Systems design:
o Detail how the system will work and the needed components of the system.
Programming:
o Translate the system design into a specific programming language.
Testing:
o Confirm that the new system meets the requirements that were set out in the systems
analysis phase.
Conversion:
o Decide the best method for replacement.
o Replace the old system with the new system.
Production and maintenance:
o Ensure that the new system is adopted, that the proper training has occurred, and provide
regular and ongoing maintenance and updates.
State the factors that influence the success or failure of systems development.
Successful systems development projects include clearly defined goals, excellent communication,
management involvement, and definitive timelines.
Most systems development projects fail because one or more of the six steps are done poorly or
not at all.
Systems development projects also fail because there may be
o lack of understanding of the desired results (imprecise targets)
o poor estimating techniques for budgeting and scheduling
o small, unadjusted schedule slippage that cumulatively results in a major delivery delay
o lack of project management skills or leadership
o poorly trained analysts and programmers
o conflicting goals and objectives among the project team members and users
o use of inappropriate software or hardware tools
State the importance of systems development methodologies.
Systems development methodologies are frameworks that will place structure on the activities of
designing and developing systems.
They typically specify the techniques used in each phase of the systems development process.
A systems development methodology will have some sort of milestone with a clearly defined
deliverable for each milestone.
Systems development methodologies help to manage and coordinate the systems development
process.
Systems development methodologies have a number of disadvantages, including adding more
administration and bureaucracy and possibly applying the wrong methodology to a project.
Compare and contrast the waterfall method for developing systems with prototyping, rapid application
development, end-user development, purchased applications, and outsourcing.
The traditional systems development life cycle (SDLC) or waterfall method is a very structured
method of systems development in which the project is broken down into distinct and discrete
steps. You can only advance to the next step once the previous step has been completed, and
signed off.
o The waterfall method ensures tight control and identifiable milestones and deliverables.
o The waterfall method is time consuming and is not very flexible.
o The waterfall method takes a non-iterative approach to development because coding is
based on clear designs, as agreed an interpreted from the system requirements.
Prototyping is an iterative form of systems development in which users try out different versions of
the system and the developers use the feedback to improve the system through multiple revisions.
o Prototyping has less structure than a traditional SDLC and is more responsive to changing
conditions and to user demands and needs.
o Prototyping is harder to manage, especially for large scale projects. It is difficult to define
the finished stage because all systems could be just a little bit better.
End-user development provides the software tools and training so that users can develop their
own information systems.
o End users know their requirements best and dont need to use the full resources of the IS
development staff.
o End-user development can lead to poorly documented systems and a collection of unique
and one-off systems that no longer meet the standards set out it the IS plan.
Rapid application development (RAD) is an attempt to harness the realization that 80% of a
systems functionality is accomplished in about 20% of the time. It uses a very short time frame
(60-90 days) and an agreed to set of minimum requirements.
o RAD uses specific programming tools and standard software to achieve its goals.
o RAD is very useful in specialized stand-alone systems, where performance isnt key.
o RAD doesnt work as well in large systems or mission critical applications.
o RAD has versions including agile, extreme, lean, joint and scrum.
Purchased applications and outsourcing are often faster than building internally, and the end
product can often be better. But they can also be more difficult to integrate with existing systems
and may not meet all of a businesss specific needs.
Evaluate the factors to consider when choosing whether to make or buy an information system.
In systems development you must choose between creating your own custom solution and buying
or subscribing to an existing solution.
In making the decision you must balance the level of functionality required against cost, ease of
implementation, risk, and integration.
The goal of a custom information system is to meet the precise needs of the organization.
o Generating a custom solution may take longer to develop but you will have greater control
over the development process.
o Purchasing a system may reduce cost and risk but it may also have either too little or too
much functionality (that is, it may not be easily integrated with other parts of the
organization or suppliers and customers).
A purchased system gives you less control over future development.
Many purchased and hosted systems have adopted SOA as a way to provide better integration
capabilities with customers.
Prepare a basic request for quotations and a basic request for proposal, and evaluate vendor proposals.
In the process of acquiring and selecting information technology there are six activities that take
place:
1. Research technical criteria and options.
This activity links back to the systems analysis stage and identifies the functionality that you
require.

2. Solicit proposals (or quotes) from vendors.
Request for quotation (RFQ) is a request for pricing on specific hardware and software.
Request for proposal (RFP) is usually wider ranging in scope and in addition to hardware
and software can include development, maintenance, and support.
The vendor usually offers a solution to the systems requirements.

3. Validate vendor claims and performance.
Once all of the proposals are received you must ensure that the vendors meet the minimum
requirements and flag vendors whose proposals hinge on solutions that are not available
yet.

4. Evaluate and rank vendor proposals.
Select a method for ranking and comparing the vendors. These rankings should include
things like cost, functionality, time, and reputation.
Tables work well in this stage.
Be sure to apply the same criteria for all vendors.

5. Award contracts and debrief losing vendors.
Unsuccessful vendors need to receive proper notification that includes a debriefing.

6. Establish integration requirements.
Once the contract has been awarded, be sure to establish any requirements around
integration with existing systems.
Determine the challenges in selecting vendors for information systems and approaches to minimizing problems in
vendor relationships.
Selecting vendors is challenging, since there is rarely a perfect fit between the organizations
needs and the vendors product capabilities.
Regardless of the vendor selected and the care taken in specifying requirements in either the RFP
or RFQ, there are likely to be changes after the contract is awarded.
There is too much complexity involved in integrating systems into an organization to be able to
expect perfect prediction at the outset.
o Finding the vendor whose product is the best fit is only part of the task.
o Finding the vendor who will be able to work with you as the process unfolds is also critical.
Plan the contract negotiation process, and explain the key clauses in a hardware or software contract.
Multiple parties need to be involved in contract negotiation:
o senior management
o legal counsel
o IT management
A collaborative, rather than adversarial, approach is more likely to be successful in the long run.
Key clauses relate to
o intellectual property
o indemnity
o denial of liability and fitness for purpose
o warranties
o maintenance
o survival beyond term
o arbitration
o bankruptcy and sale of business
o escrow of source code
o most favoured nation pricing
o termination
o force majeure
Evaluate the issues and challenges in managing IS projects.
One of the major challenges of managing IS projects is keeping the project on track. Project
managers have a number of methods to keep projects on track:
o imposing deadlines
o negotiating deadlines
o minimizing scope creep
o making sure that the system requirements have been defined
o not allowing additional requirements to be added after they have been defined
o balancing time, cost, and quality of a project (Adding time to a project will increase the cost
of project but may not affect the quality.)
Compare the techniques of PERT and Gantt charts and define their role in project management.
A PERT chart uses a series of arrows that represent the flow of activities or stages of a project.
o This allows for the identification of dependencies in the project and the critical path that
must be completed on time in order to deliver the project in the expected time frame.
o PERT charts are used to plan the project.
A Gantt chart consists of a series of horizontal bars.
o Each bar represents a task. The length of the bar is the time required to complete the task.
o Gantt charts usually include the personnel and resources needed to complete the task.
o Gantt charts are used to monitor the progress of the project.
PERT and Gantt charts are not mutually exclusive and are usually used together to manage the
project.
Design simple PERT and Gantt charts.
Broadly speaking, PERT and Gantt charts are created by first identifying the project activities, then
identifying their relationships, and then diagramming the activities and their relationships using the
specific style of the tool. Topic 3.6 outlines the steps in constructing each of these charts. Most
project software includes PERT and Gantt charts in their offerings.
Support a decision to continue or abandon a project using feasibility and cost-benefit analysis.
There are four main components to feasibility analysis:
1. Technical feasibility: Can the goals of the system be achieved with currently available
technology?
2. Organizational feasibility: Is the organization able to adapt to the new technology or
system?
3. Economic feasibility: Is the project cost effective? How much will it cost to implement and
develop the new system?
4. Schedule feasibility: Can the new system be complete in the available time or in a timely
manner so that it is useful?