Module 3: Systems development overview and issues

Transcription

1 file:///f /Courses/ /CGA/MS2/06course/m03intro.htm 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 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. This module will help you develop the following professional competencies: Advise on the design, development, and implementation of IT projects. Consider alternative solutions and shape recommendations. Advise on the financial implications of IT acquisitions and vendor selection. Advise on business decisions in the context of the legal framework. Prepare and advise on contract structure and enforcement. Facilitate resolution between differing viewpoints, in this case, contract negotiation. Identify key steps, milestones, and critical systems that are needed for the success of changes to business activities, processes, and operational plans. Assess the value of a business, in this case, an organization s information system. 3.1 Systems development 3.2 Systems development methods & techniques 3.3 Make or buy 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 file:///f /Courses/ /CGA/MS2/06course/m03intro.htm [20/08/ :04:14 AM]

2 file:///f /Courses/ /CGA/MS2/06course/m03t01.htm 3.1 Systems development Learning objectives Identify and describe the six activities of systems development. (Level 1) Summarize the factors that influence the success or failure of systems development. (Level 1) Required reading Chapter 9, Section 9.2, Overview of Systems Development 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, 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 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. At this point, the specific plan that is needed is created and the decision on feasibility is made. 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. Programming The system is translated from the design into the programming language or software that will best meet the requirements of the system plan. 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. Conversion file:///f /Courses/ /CGA/MS2/06course/m03t01.htm (1 of 2) [20/08/ :04:14 AM]

3 file:///f /Courses/ /CGA/MS2/06course/m03t01.htm Conversion means moving from the old system to the new system. There are a number of methods for accomplishing this. 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 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 In successful projects, the goals and outcomes are clearly defined and understood. The expectations of the system are managed so that users and management are realistic about the results and don t have an inflated sense of the outcomes. This can be achieved by openly communicating the goals of the project and everyone s role in attaining those goals. Communication is easier if management supports the development of the system. The system should align with the goals of management and support the strategy that management 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 doesn t 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) poor estimating techniques for budgeting and scheduling small, unadjusted schedule slippage, which cumulatively results in a major delivery delay lack of project management skills or leadership poorly trained analysts and programmers conflicting goals and objectives among the project team members and users use of inappropriate software or hardware tools Coordination of personnel, phases, and tasks is vital to systems development but is not an easy task for the project manager. Adding more programmers may 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. file:///f /Courses/ /CGA/MS2/06course/m03t01.htm (2 of 2) [20/08/ :04:14 AM]

4 file:///f /Courses/ /CGA/MS2/06course/m03t02.htm 3.2 Systems development methods and techniques Learning objectives Discuss 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 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 to 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 term used to describe the 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 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. 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 all important aspects of a project have been taken into account. 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. Unfortunately, no two projects are alike. Sometimes, systems analysts may hide behind the systems development file:///f /Courses/ /CGA/MS2/06course/m03t02.htm (1 of 4) [20/08/ :04:15 AM]

5 file:///f /Courses/ /CGA/MS2/06course/m03t02.htm methodology going through the project in accordance with the steps outlined in the methodology in "cookbook" fashion. 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. Without clear engagement on the part of both IT and business stakeholders, success is elusive, regardless of the methodology chosen. The most common systems development methodologies are the traditional or waterfall approach, prototyping, end-user development, and application software packages. Traditional systems development life cycle (SDLC) or waterfall method A systems development life cycle (SDLC) is a logical process that describes the major steps performed by analysts and users to develop an information system from inception to its ultimate discontinuance. The six activities introduced in the first part of this module form the SDLC. Exhibit 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. 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 the 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 to help determine estimates for new projects. Moreover, with its emphasis on milestones and deliverables, the waterfall approach is best able to help management monitor progress and control costs. The disadvantage is that it is a very rigid method, with long periods of time where there is no involvement (or little involvement) from users. This can lead to systems that end up not meeting the requirements of the users. 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 determination phase. Users are often unable to comprehend the design without actually seeing how the system file:///f /Courses/ /CGA/MS2/06course/m03t02.htm (2 of 4) [20/08/ :04:15 AM]

6 file:///f /Courses/ /CGA/MS2/06course/m03t02.htm 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. More often than not, 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. 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, or even dozens of, systems development staff members. Prototyping Prototyping is an iterative form of development in which users try out different aspects of a planned system and provide feedback that is used to improve each version of the proposed system. Prototyping requires less structure 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. 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. 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.7 in the textbook shows the activities in a typical prototyping model. End-user development End-user development emphasizes the users of information systems. By providing tools, training, and access to data, users can create their own applications and systems. End-user development takes advantage of the fact that users know their requirements best. This 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. The difficulty with enduser 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. Application software packages and outsourcing In many cases, it makes more sense to purchase applications that already exist rather than trying to develop a custom approach. Organizations can benefit from the learning that has gone into developing a standard system 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 can, and so there are risks with this approach as well. Outsourcing 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 80/20 rule). The timeframe for developing systems using RAD is usually 60 to 90 days. To achieve this rapid development, an agreed on minimum set of requirements is the benchmark of completion, instead of all the requirements of the system. RAD relies heavily on fourth generation programming tools and uses standard software to connect to data sources. There is no time to create custom programs or applications. The challenge of RAD is that the file:///f /Courses/ /CGA/MS2/06course/m03t02.htm (3 of 4) [20/08/ :04:15 AM]

7 file:///f /Courses/ /CGA/MS2/06course/m03t02.htm 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 when 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. file:///f /Courses/ /CGA/MS2/06course/m03t02.htm (4 of 4) [20/08/ :04:15 AM]

8 file:///f /Courses/ /CGA/MS2/06course/m03t03.htm 3.3 Make or buy 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 or buy the software. Building can be done internally or by consultants. Buying software can involve buying a license to install and use software or buying a subscription to use the software hosted by a vendor. Various issues factor into the decision to make or buy software. Customized functionality and control trade off against cost, speed of implementation, and risk. Integration represents a challenge if you must link in-house systems to external systems. Deciding whether to build a custom system (either internally or using consultants) or acquire an existing system (either commercial software or occasionally 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 acquisition of existing systems, and there are often good off-the-shelf solutions available. Nonetheless, 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. Off-the-shelf software The term "off-the-shelf" as applied to software is a bit 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. SAP and the other large enterprise systems are off-the-shelf software in a sense. They are purchased rather than custombuilt 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. Applications 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 illustrates these two options. Exhibit file:///f /Courses/ /CGA/MS2/06course/m03t03.htm (1 of 4) [20/08/ :04:16 AM]

9 file:///f /Courses/ /CGA/MS2/06course/m03t03.htm For the horizontal application, consider a package such as ACCPAC or QuickBooks. These packages are designed to be used by a broad range of companies, across many industries. These particular examples tend to be targeted at smaller enterprises, but nonetheless show 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 to lab orders and accounting). There are, of course, other solutions. For example, there are packages defined as narrowly as "automotive accounting," designed to fill particular market niches. Regardless of the specific focus of application, it is important to recognize these two broad approaches to software commercialization. Advantages and disadvantages of making and buying 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. 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. 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. Custom software is rarely designed with a broad view to enable file:///f /Courses/ /CGA/MS2/06course/m03t03.htm (2 of 4) [20/08/ :04:16 AM]

10 file:///f /Courses/ /CGA/MS2/06course/m03t03.htm 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. Looking forward, however, 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. 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 of the key advantages 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 would be needed (that is, to link an order in a purchasing system to the accounts payable function in an accounting system). 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 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 and 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. 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 scale economies. 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 scale economies by going with a purchased application. 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. 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 without buying an existing package. 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 downside to purchasing applications. Keep in mind, though, that it is the vendor's business to develop applications that customers will want. If your requirements are common in your industry, there is a greater likelihood that they will be met in the future. file:///f /Courses/ /CGA/MS2/06course/m03t03.htm (3 of 4) [20/08/ :04:16 AM]

11 file:///f /Courses/ /CGA/MS2/06course/m03t03.htm 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 A further 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, hosted at the vendor's site and shared with other organizations. These companies, called application service providers (ASPs), 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. (Some ASPs 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. 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. file:///f /Courses/ /CGA/MS2/06course/m03t03.htm (4 of 4) [20/08/ :04:16 AM]

12 file:///f /Courses/ /CGA/MS2/06course/m03t04.htm 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 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 (what it should do). 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? 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. 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. 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 file:///f /Courses/ /CGA/MS2/06course/m03t04.htm (1 of 6) [20/08/ :04:17 AM]

13 file:///f /Courses/ /CGA/MS2/06course/m03t04.htm price and terms. 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. 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. 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), it would be a waste of time for both you and the vendor. 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 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 file:///f /Courses/ /CGA/MS2/06course/m03t04.htm (2 of 6) [20/08/ :04:17 AM]

14 file:///f /Courses/ /CGA/MS2/06course/m03t04.htm 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 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. 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. 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. 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. file:///f /Courses/ /CGA/MS2/06course/m03t04.htm (3 of 6) [20/08/ :04:17 AM]

15 file:///f /Courses/ /CGA/MS2/06course/m03t04.htm 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 (desirable 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. 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 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 shows a partial example of such a process. Based on the total weighted score, Vendor C's proposal should be investigated in detail. Exhibit 3.4-1: file:///f /Courses/ /CGA/MS2/06course/m03t04.htm (4 of 6) [20/08/ :04:17 AM]

16 file:///f /Courses/ /CGA/MS2/06course/m03t04.htm 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. Finally, when ranking potential vendors, you should consider ethical issues, especially conflicts of interest. Example 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-1, 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 a high speed personal computer 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 computer to Alliance. Henri reasons that (a) his decision was objective, and (b) Alliance is getting the best system at the best price. Henri is violating the ethical principle to place his client first. The CGA-Canada Code of Ethical Principles and Rules of Conduct, Section 2, "Trusts and Duties," states: "Members shall act in the interest of their clients and shall not use their privileged position without their principal's knowledge and consent." Specifically, Rule 204 (b) states When recommending a service or product, a member shall clearly disclose in writing to the client any conflict of interest the member may have, or any fees or commissions the member may receive regarding the service or product recommended. It is easy to deceive oneself about objectivity in the face of substantial "gifts" for procurement. Henri should disclose the offer of the computer to Alliance. 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. file:///f /Courses/ /CGA/MS2/06course/m03t04.htm (5 of 6) [20/08/ :04:17 AM]

17 file:///f /Courses/ /CGA/MS2/06course/m03t04.htm 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 vendor s 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. 6. Establish integration requirements The final activity in the selection process is to establish 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. file:///f /Courses/ /CGA/MS2/06course/m03t04.htm (6 of 6) [20/08/ :04:17 AM]

18 file:///f /Courses/ /CGA/MS2/06course/m03t05.htm 3.5 Vendor selection and contractual issues Learning objectives Evaluate 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 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 licence. Checklist 12 has not been included in the reading. 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. 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. file:///f /Courses/ /CGA/MS2/06course/m03t05.htm (1 of 4) [20/08/ :04:17 AM]

19 file:///f /Courses/ /CGA/MS2/06course/m03t05.htm 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 pressured to use higher ranking personnel in the negotiation process. Negotiating with low-level personnel often leads to delays. However, contract negotiations with high-ranking managers 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. 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 the 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 vendor s hardware or software. This clause file:///f /Courses/ /CGA/MS2/06course/m03t05.htm (2 of 4) [20/08/ :04:17 AM]

20 file:///f /Courses/ /CGA/MS2/06course/m03t05.htm 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 vendor s 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 will 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. 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 company s 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 custommade 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 file:///f /Courses/ /CGA/MS2/06course/m03t05.htm (3 of 4) [20/08/ :04:17 AM]