CIS 5800 Final B

An uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective

• 1. The volatile nature of technology (being subject to constant updates, sometimes in the middle of projects) creates special pressures in information systems projects. Technical changes need to be constantly monitored and considered as the information systems project develops.
• 2. Technology may also influence project risk by giving the project manager new tools to assess risk. Many technological aids now available are used by project managers in risk planning and risk identification, as well as in the analysis of risk.
• 3. Although technology may help the project manager in assessing risks, it may also create risk. If any of the information entered into the system is unreliable or incorrect, the project manager's decision making may be adversely affected. It's the assumptions computer-generated output (from PM tools) always correct.
• 4. From a teamwork perspective, the entire project team may be involved in planning, assessing, measuring, or controlling risk. As a result, all of the teamwork and communication issues will come into play as risk is managed. Additionally, forming teams during projects incorporates risk. Hiring is also risky.

• 1. Initiation: Risk most often occurs in the project selection stage. During this process, top management must make project selection decisions based on the information provided to them. Identification and selection of specific projects (inside or outside of organization’s core competencies). If the company is following a certain strategy such as diversification, project risks may increase as it pursues projects outside its core competency.
• 2. Planning: Risk associated with procurement planning is one example of potential risk during an IS development projects. The instability of new technologies used during an IS project may result in unreliable estimated delivery dates from vendors trying to win project contracts. Another risk during project planning is associated with developing the project schedule(s) which are built around the WBS that are generally based on previous project information or on expert knowledge. Neither of these techniques is completely foolproof.
• 3. Execution: Managers may find themselves faced with many decisions involving risk. For example, a vendor may inform a manager that a critical project component is in danger of not meeting the scheduled delivery date. Another risk involves technology upgrades, problems associated with the new version's functionality and cost (if any).
• 4. Closing: One major risk involves the acceptance of the project as finished. This can be especially risky if major contracts are involved because the acceptance of the project may trigger significant closing payments to project contractors. Once the contracts have been signed off as met, it may become more difficult to get vendors to return and fix any problems without additional charges.
• 5. Control: Used to monitor and react to project risk. Implementation of risk plan; modification of project schedule.

• In that survey, project managers were asked how their respective organizations approached risk management:
• 1. 38% stated that their organizations approached risk management in terms of consequences and likelihood of their occurrence - this view is consistent with the risk management planning processes, specifically probability/impact analyses
• 2. 28% reported that their companies used systematic and organized assessments and control processes to deal with threats to projects and, therefore, to manage risk - such techniques are part of the processes of risk identification, risk monitoring, and risk control
• 3. 25% reported that their organizations approached risk management in terms of both positive and negative variations to the project plan - this view is consistent with our definition of project risk, which includes negative and positive effects on project outcomes
• 4. 9% reported that their organizations approached risk management as the difference between means and ends

In the separate survey conducted by Business Improvements Architects (BIA), managers were asked to identify the biggest challenges facing their organizations. Prominently noted among them was project risk. 38% of the managers reported the biggest challenge was improper assessment or management of project risk.

• Organizations need to find a balance between risk and opportunities
• Organization have different levels of risk tolerance: (1) Risk-averse, (2) Risk-neutral, (3) Risk-seeking
• Known risks have been identified and analyzed
• Unknown risks have not been identified and analyzed, cannot be managed

• New or different project management methodologies
• Different: (1) Cultures, (2) Organization structures, (3) Human resources

• 1. Constant flux of technology in today's business environment: ongoing changes in technology have a variety of effects on project teams such as (1) in some cases software updates may enable changes in project scope, also, it is possible that new development tools will become available in the middle of a development project such as Microsoft's shift to the .NET development environment, and (2) changes in the firm's information infrastructure
• 2. Locating, hiring, and retaining competent IS personnel: acquisition and use of skilled personnel, getting the right people can mean the difference between success and failure
• 3. User acceptance: gaining it, project managers must be sure that any new system will meet the needs of a diverse set of users, adding risk to the project; further, end-users often think requests to change system requirements will be easier to implement than they really are; small changes in scope - such as a request for an additional piece of information to be displayed on a customer support screen - may dramatically change the design of an underlying database
• 4. Numerous methodologies available during systems development: not only it is difficult to fully understand and support the growing number of systems development methodologies and environments, it is also difficult to make the appropriate choice; each methodology has its advantages and disadvantages, and the choice of methodology may change project risk

• 3 For/advocate outsourcing:
• 1. Results in significant cost reduction, given that it provides access to advanced capabilities
• 2. Cheaper labor
• 3. Reduced requirements to support an additional organizational function outside of one's core competency

• 2 Against/opponents outsourcing concerning risks:
• 1. Internal resistance: managers, project managers, developers, and other personnel in a company may feel threatened because they fear that there will be shifts in responsibilities and power or, possibly, layoffs. For those reasons, affected individuals may act to sabotage an offshore project throughout the life cycle of the project. Four of the ways to deal with internal resistance include (1) ensuring strong support from upper management, (2) picking the right people to be on the team, (3) getting managers involved early in the outsourcing process, and (4) appropriately reassuring employees regarding the goals of the outsourcing effort and how it it will affect the company and project team members.
• 2. Security and privacy: some American companies fear that their data or proprietary processes might fall into the wrong hands. Because of weak intellectual property laws and inefficient enforcement, the probability of intellectual property theft may be more pronounced in other countries. To ensure security and privacy, American countries have been demanding that these countries put security measures in place which includes (1) physical security measures such as electric fencing around buildings, (2) the use of card keys and biometric authentication devices to gain access to facilities, and (3) closed-circuit TVs for surveillance. Companies also want their data and information systems to be protected through (1) the use of event logging and monitoring tools, (2) intrusion-detection systems, (3) firewalls, and (4) encryption hardware/software technologies.

• 9.1 Risk Management Planning
• .1 Inputs
• .1 Enterprise environmental factors
• .2 Organizational process assets
• .3 Project scope statement
• .4 Project management plan
• .2 Tools and Techniques
• .1 Planning meetings and analysis
• .3 Outputs
• .1 Risk management plan

• 9.2 Risk Identification
• .1 Inputs
• .1 Enterprise environmental factors
• .2 Organizational process assets
• .3 Project scope statement
• .4 Risk management plan
• .5 Project management plan
• .2 Tools and Techniques
• .1 Documentation reviews
• .2 Information gathering techniques
• .3 Checklist analysis
• .4 Assumptions analysis
• .5 Diagramming techniques
• .3 Outputs
• .1 Risk register

• 9.3 Qualitative Risk Analysis
• .1 Inputs
• .1 Organizational process assets
• .2 Project scope statement
• .3 Risk management plan
• .4 Risk register
• .2 Tools and Techniques
• .1 Risk probability and impact assessment
• .2 Probability and impact matrix
• .3 Risk data quality assessment
• .4 Risk categorization
• .5 Risk urgency assessment
• .3 Outputs
• .1 Risk register (updates)

• 9.4 Quantitative Risk Analysis
• .1 Inputs
• .1 Organizational process assets
• .2 Project scope statement
• .3 Risk management plan
• .4 Risk register
• .5 Project management plan - a) Project schedule management plan; b) Project cost management plan
• .2 Tools and Techniques
• .1 Data gathering and representation techniques
• .2 Quantitative risk analysis and modeling techniques
• .3 Outputs
• .1 Risk register (updates)

• 9.5 Risk Response Planning
• .1 Inputs
• .1 Risk management plan
• .2 Risk register
• .2 Tools and Techniques
• .1 Strategies for negative risk or threats
• .2 Strategies for positive risks or opportunities
• .3 Strategy for both threats and opportunities
• .4 Contigent response strategy
• .3 Outputs
• .1 Risk register (updates)
• .2 Project management plan (updates)
• .3 Risk-related contractual agreements

• 9.6 Risk Monitoring and Control
• .1 Inputs
• .1 Risk management plan
• .2 Risk register
• .3 Approved change requests
• .4 Work performance information
• .5 Performance reports
• .2 Tools and Techniques
• .1 Risk reassessment
• .2 Risk audits
• .3 Variance and trend analysis
• .4 Technical performance measurement
• .5 Reserve analysis
• .6 Status meetings
• .3 Outputs
• .1 Risk register (updates)
• .2 Requested changes
• .3 Recommended corrective actions
• .4 Recommended preventive actions
• .5 Organizational process assets (updates)
• .6 Project management plan (updates)

• A systematic approach to planning the risk management activities of a given project
• .1 Inputs
• .1 Enterprise environmental factors: Attitudes toward risk and risk tolerance.
• .2 Organizational process assets/outputs: The organizational processes put in place to handle risk.
• .3 Project scope statement: Defining the project.
• .4 Project management plan: Summary document for the project.

• .2 Tools and Techniques
• .1 Planning meetings and analysis: Should be attended by senior managers, project team leaders, stakeholders, and project members who have decision-making responsibilities. During such meetings a variety of risk-related issues are discussed and decided, including determining the plans for conducting all risk management activities, as well as risk-related elements to be included in the budget and schedule. Further, responsibilities for dealing with risk are assigned. All of these factors are assembled into the output of the risk management planning process, specifically the risk management plan. Meetings also allow for the development of templates for defining and categorizing risk types, impacts, and probabilities; templates provide organizational standards for Project Risk Management.

• .3 Outputs
• **.1 Risk management plan: An overall plan used to outline risks and the strategies used to manage them. Eight potential components - (1) Methodology, (2) Roles and responsibilities, (3) Budgeting, (4) Timing, (5) Scoring and interpretation, (6) Thresholds, (7) Reporting formats, and (8) Tracking.

• The process of identifying and documenting a project's potential risks
• This process should be performed by project managers, project teams, the risk management team, experts, customers, end users, outside experts, and additional stakeholders
• .1 Inputs
• .1 Enterprise environmental factors: Attitudes toward risk and risk tolerance.
• .2 Organizational process assets/outputs: The organizational processes put in place to handle risk.
• .3 Project scope statement: Defining the project.
• **.4 Risk management plan: Output of the risk management planning process.
• .5 Project management plan: Summary document for the project.

• .2 Tools and Techniques
• .1 Documentation reviews: The reviews of organizational information to aid during risk identification. Involve reviewing existing project documentation, which may include project plans and assumptions. Historical information is useful in developing the risk register and comprises any Project Risk Management information collected during the course of previous projects. Specific sources of historical information may include - (1) Project files, which include previous risk management plans, project reports, and lessons learned; (2) Published information, which is often in public databases, published reports, academic studies, and through published benchmarking information.
• **.2 Information gathering techniques: Techniques such as (1) brainstorming, (2) Dephi surveys/technique, (3) inteviewing, or (4) SWOT analyses used to identify project risk.
• .3 Checklist analysis: Tools that enable risks for a project to be listed and checked off. They are especially useful for projects that are similar to past projects. Their limitation, however, is that it is often not feasible to develop a comprehensive list of potential project risks.
• .4 Assumptions analysis
• .5 Diagramming techniques: Diagramming tools, such as (1) cause-and-effect diagrams, (2) flow charts, or (3) influence diagrams, used to help identify project risk.

• .3 Outputs
• **.1 Risk register: A formal record listing all project risks, explaining the nature of the risk and management of the risk. Risk categories can be helpful when developing the risk register which include (1) Technical, quality, or performance risks, (2) Project management risks, (3) Organizational risks, and (4) External risks. The risk register includes a detailed list of identified risks and possible risk triggers (i.e., events that serve as early warnings of risk), potential responses to those risks, the root causes of the risk, and an updated list of risk categories (based on any new risks being identified that were not in the prior list of risk categories).

• The establishment of probabilities regarding both the impact and likelihood of specific risk occurrence
• .1 Inputs
• .1 Organizational process assets
• .2 Project scope statement
• .3 Risk management plan
• .4 Risk register
• .2 Tools and Techniques
• .1 Risk probability and impact assessment: Risk probability is concerned with the likelihood that a certain risk will occur and can be measured on a scale from very low to very high. Risk impact, or the consequences associated with the occurrence of a given risk, is concerned with the impact on project outcomes if the risk event occurs.
• **.2 Probability/impact (risk rating) matrix: A technique used to analyze project risk in terms of its probability of occurrence and its impact on project outcomes. Probability scales are generally measured on a 0 to 1 scale, where 0 represents no chance that the event will occur and 1 represents the certainty of its occurrence. Probability scores are most often determined through expert judgment and are, therefore, susceptible to human error. Scores can be attributed on an ordinal scale, such as not at all likely to very likely, or by assigning specific values, such as 0.1, 0.2, 0.3, and so on. Impact scales represent the magnitude of the effect the risk occurrence may have on the project objective. Impact scores can be ordinal, as for probability scales, or cardinal, in which specific values are assigned to potential impacts. Importantly, both measures and their associated scales should be developed independently by organizations to reflect their risk analysis preferences.
• 

• .3 Risk data quality assessment: Simply an assessment of the quality of the data used to assess risk. This might include project assumption testing, a tool used to further test the assumptions embedded in risk identification. Data precision ranking can be used for risk data quality assessments. The following dimensions are considered in such a ranking: (1) The extent to which a risk is understood; (2) Available risk data; (3) Data quality; and (4) Data integrity and reliability.
• .4 Risk categorization: Can help to determine which part of the project may be most susceptible to risk. For example, a risk breakdown structure can be used to identify the risks organized by project component.
• .5 Risk urgency assessment: Requires the project team to determine the priority of various risks (e.g., in terms of risk rating) to help decide which risks need to be dealt with on a priority basis.

• .3 Outputs
• .1 Risk register (updates)

• The analysis of the probability of occurrence and the impact of risk on project objectives using numerical techniques
• Can be performed separately or with qualitative analysis
• .1 Inputs
• .1 Organizational process assets
• .2 Project scope statement
• .3 Risk management plan
• .4 Risk register
• .5 Project management plan - a) Project schedule management plan; b) Project cost management plan

• .2 Tools and Techniques
• .1 Data gathering and representation techniques: Through interviewing techniques which are instrumental during the quantitative risk analysis process because interviews with project experts and other stakeholders can assist in quantifying risk probabilities and consequences. Besides interviewing, techniques include sensitivity analysis, decision-tree analysis, and simulation. Probability distributions can be applied to represent data gathered during interviews or through other data gathering techniques. Such probability distributions can illustrate the probability of something's occurring or, in some cases, more general results such as optimistic, most likely, and pessimistic scenarios.
• .2 Quantitative risk analysis and modeling techniques: Include the use of sensitivity analysis, decision tree analysis, expected monetary value analysis (EMV), and simulation.

• .3 Outputs
• .1 Risk register (updates)

• The process of developing methods for responding to project risks
• .1 Inputs
• **.1 Risk management plan: Both risk management plan and risk register are influenced by the risk threshold of the organization, a list of potential responses, risk owners, common risk causes, trends identified during the qualitative and quantitative risk analysis processes, the list of prioritized risks, the risk ranking of the project, the prioritized list of quantified risks, probabilitistic analysis of the project, and the probability of achieving the cost and time objectives.
• **.2 Risk register: Outputs from preceding risk processes.

• .2 Tools and Techniques
• .1 Strategies for negative risk or threats
• .2 Strategies for positive risks or opportunities
• .3 Strategy for both threats and opportunities
• .4 Contigent response strategy

• .3 Outputs
• .1 Risk register (updates)
• .2 Project management plan (updates): Contains the risk management plan, a subcomponent of which is a risk response plan.
• **.3 Risk-related contractual agreements: Any contracts for the purpose of risk transference during the project. During an IS development project, they could include a transfer of responsibility for systems implementation or some other phase of systems development. Contingency reserve (a provision held in reserve by the project sponsor to meet unanticipated changes in factors like project scope) amounts needed should be estimated based upon risk information generated during risk management. Inputs to other processes, as with other risk management activities, represent another important output to be considered during response planning. For example, identified risks and their assigned response strategies may provide information for other project management processes. These risk response planning outputs serve as inputs to the project plan so that the risk response activities can be incorporated into the project schedule.

• The process of monitoring identified risks for change and controlling those changes
• Generally takes place over the entire life of the project
• Purpose is to identify, analyze, and plan for newly arising risks; to watch existent risks (on the watch list); to monitor conditions that would trigger risk responses; and finally, to determine if such responses are working
• Workaround: an unplanned response to a risk event when you do not have a contingency plan in place
• .1 Inputs
• .1 Risk management plan
• .2 Risk register
• .3 Approved change requests
• .4 Work performance information
• .5 Performance reports

• .2 Tools and Techniques
• .1 Risk reassessment: Periodic project risk reviews; Reviews designed to review existing risk activities and to monitor any changes to the project.
• .2 Risk (response) audits: Audits designed to evaluate the effectiveness of risk response strategies and risk owners.
• .3 Variance and trend analysis: Using performance data.
• .4 Technical performance measurement: An important tool used to determine whether important technical milestones are being met.
• .5 Reserve analysis
• .6 Status meetings

• .3 Outputs
• .1 Risk register (updates)
• .2 Requested changes
• .3 Recommended corrective actions
• .4 Recommended preventive actions
• .5 Organizational process assets (updates)
• .6 Project management plan (updates)

• 1. Lack of top management commitment to the project
• 2. Failure to gain user commitment
• 3. Misunderstanding the requirements
• 4. Lack of adequate user involvement
• 5. Failure to manage end user expectations
• 6. Changing scope/objectives
• 7. Lack of required knowledge/skills in the project personnel
• 8. Lack of frozen requirements
• 9. Introduction of new technology
• 10. Insufficient/inappropriate staffing
• 11. Conflict between user departments

• Practices
• 

• 1. The process for identifying, analyzing, and managing initial and continuing project risks
• 2. The frequency, process, and personnel involved in reviewing risks
• 3. Designation of the risk management team and their roles
• 4. The determination of how risks will be reported
• 5. An initial list of project risks, including their current importance, likelihood, mitigation strategy, and personnel in charge of dealing with the risks; this list may later be included as an Appendix in the risk register

• 1. Methodology: The methodology should discuss the approach to the management of risk during the project
• 2. Roles and responsibilities: This component of the risk management plan should establish project members' roles and responsibilities for the risk activities identified in the risk management plan
• 3. Budgeting: This is simply the preparation of a risk-management budget for the project
• 4. Timing: This section of the risk management should outline how the risk management activities will fit within the project life cycle
• 5. Scoring and interpretation: This section describes the scoring parameters and their associated interpretation from the qualitative and quantitative risk analyses to be performed during the project
• 6. Thresholds: This component of the risk management plan determines the criteria according to which risks will be acted upon; it is consistent with the tolerance-for-risk section that serves as an input to risk management planning
• 7. Reporting formats: This section outlines the format for the risk response plan and describes how risk management processes will be documented and communicated during the project
• 8. Tracking: Project risk planning activities should be tracked, documented, and archived for use during future projects

• Risk management template
• 

• 1. Technical, quality, or performance risks: The first of these, technical risk, is especially significant during IS development. As has been continually reiterated throughout the previous chapters, reliance on new, unproven or unreliable technology is one of the many challenges faced by IS development project managers. Quality and performance risk categories include performance goals that cannot easily be met and changing industry standards.
• 2. Project management risks: This category includes risks associated with project management, including risks associated with poor project planning, and poor use of recognized project management processes.
• 3. Organizational risks: This category includes risks that are organizationally driven; it can include inconsistent goals, lack of funding, and conflicting priorities, among others.
• 4. External risks: A category that can be easily overlooked, external risks include legal events, environmental concerns and natural disasters such as earthquakes and floods

• 1. Brainstorming: Often used technique for gathering information. In this case, brainstorming sessions are conducted to identify potential risks. Once a list of potential risks has been generated, discussions are conducted to categorize them for further analysis.
• 2. Delphi technique: Involves an iterative process of information gathering. This technique begins with the administration of an initial questionnaire to a group of experts designed to elicit a list of potential risks. These lists are then combined according to priority, as based upon the number of similar responses. This new list is then resubmitted to the original group of experts, who then rerank the identified risks. This process continues until a consensus is reached. Avoid possible bias of oral panel deliberations.
• 3. Interviewing: Experts and project managers can be interviewed as a means for identifying potential risks to the project. To facilitate this process, these individuals may be provided with relevant project information, such as the work breakdown structure (WBS) and list of project assumptions.
• 4. Strengths, weaknesses, opportunities, and threats (SWOT): Can be used to increase the reach within which risks will be considered.

• 1. Cause-and-effect diagrams: Also known as fishbone diagram, cause-and-effect diagrams were introduced in the chapter on managing project quality and will be discussed in more detail in the chapter on managing project control. These diagrams are useful during risk identification because they allow managers to identify potential risks and trace them back to their root causes.
• 2. System or process flow charts: Flow charts depict the interrelations among project activities and can be used to help managers determine the risks associated with those interrelations.
• 3. Influence diagrams: These diagrams graphically represent potential problems while accounting for causal influences, time, and other relationships between project activities and outcomes.

Events that serve as early warnings of risk

A technique used during qualitative risk analysis to test the assumptions made during risk identification

• 1. Sensitivity analysis: A technique used to examine the potential impact of specific risks to a project; determine which risks have the largest potential impact on a project. One example of a sensitivity analysis is the tornado analysis, which graphically shows, in descending order, which risks can cause the greatest variability in some outcome.
• **2. Decision tree analysis: A diagramming technique used to evaluate courses of action in terms of their potential cost and benefits relative to other courses of action.
• 
• 3. Expected monetary value analysis (EMV): A statistical technique that captures the average value of potential projects by analyzing the likelihood of possible project outcomes as well as each outcome's financial consequences. A graphical depiction of EMV can be captured in a decision tree analysis.
• 4. Simulation: A technique, such as Monte Carlo analysis, used to perform what-if analyses to determine the impact of a given situation (differing input variables) on a project objective. It's the most recognized form of simulation analysis; values for uncertain input variables (such as changes in resource availability or time to complete particular project tasks) are randomly generated over and over to achieve a distribution of possible project outcomes. Simulations typically refer to an analytical method that imitates some sort of real-life system. Without using simulations, spreadsheet based what-if models typically only examine the effect of changes in input variables to one outcome at a time. In contrast, simulations vary input variables and examine multiple possible outcomes.

• 1. The likelihood of realizing a specific project objective
• 2. Risk quantification in terms of additional scheduling and cost needs
• 3. Identifying the most salient risks in terms of the project
• 4. Setting realistic targets in terms of scope, cost, and schedule

• One example of a sensitivity analysis
• A diagramming technique that graphically shows, in descending order, which risks can cause the greatest variability on some outcome
• The risks at the top can cause the greatest variability, and the risks at the bottom cause the least variability

• Tornado analysis: shows how different risks can cause variability in the base value of an information system. Discount Rate, Cost Avoidance, and Hardware Cost are the top 3 risk factors and could have a very large effect on the base value of this system.
• 

Project members responsible for specific risk activity decisions

• 1. Risk avoidance: A risk response strategy designed to avoid potential/identified project risks. Identified risks are avoided through a different course of action. Within an IS development project, this may include avoiding the use of an untested technology or avoiding changes to the scope of the system.
• 2. Risk transference: A risk response strategy designed to transfer risk to another party often through the use of contracts. Depending on the type of contract being used, risk may be transferred from the seller to the buyer or from the buyer to the seller.
• 3. Risk mitigation: A risk response strategy in which steps are taken to mitigate project risk. Used to reduce, eliminate, or transfer the chances of risk occurrence or to reduce the impact of the risk on project objectives. An example of risk mitigation during an IS development project is the use of a known technology provider rather than reliance on a less established vendor.
• 4. Risk acceptance: A risk response strategy in which risks are simply accepted and contingency strategies are planned. Occurs when managers simply decide that an effective response cannot be developed for a specific risk. In such a circumstance, the project team may decide to not alter the project management plan to deal with this particular risk, given the lack of a suitable response strategy. For example, an IS development project team may accept the risk that a new version of a particular software released during the execution phase of a project may not function as intended.

• A documented plan for risk response
• The project management plan (2nd risk response planning outputs) contains the risk management plan, a subcomponent of which is a risk response plan

• 1. Any risks that have been identified along with a description and the areas and objectives the idenfied risk may affect
• 2. The roles and responsibilities of any risk owners
• 3. Qualitative and quantitative risk analysis results as well as any trends identified during either of these processes
• 4. A description of the risk response strategies including avoidance, transference, mitigation, and acceptance, and the specific risks to which the various strategies will be applied
• 5. An acknowledgement of any residual risk projected to remain after any risk response strategies have been applied
• 6. A list of actions to be used to implement the risk response strategies
• 7. Budget and schedule information for any risk response
• 8. Any contingency plans used as part of an active reponse to accept risks

• Any risks remaining after risk response strategies have been applied
• Those risks that remain after avoidance, transfer, or mitigation strategies have been applied, are identified during risk response planning

Any risks resulting from the application of a risk response strategy

• First wave:
• –In-house information systems development
• –More art than science
• –Limited talent pool
• –Most systems were custom-designed in-house
• –Slow and costly

• Second wave:
• –Art became a science through better defined processes (planning and documentation)
• –Technology assisted in development effort
• –Off-the-shelf software is an option, but “not built here” syndrome is present

• Third wave:
• –Need for faster development (Internet speed)
• –Move to agile methodologies
• –Software development acquired outside the organization
• –Exception is in-house development of Internet-related applications

The procurement of products and/or services from an outside vendor

• 1. IT (Information Technology) service firms: Firms that help companies develop custom information systems for internal use, or develop, host, and run applications for customers. If a company needs an information system but does not have the expertise or the personnel to develop the system in-house and a suitable off-the-shelf system is not available, the company will likely consult an IT services firm. Consultants use many of the same methodologies, techniques, and tools that companies use to develop systems in-house. IBM is listed as the top global software producer, being the leader in the IT global outsourcing market, also well known for its development of Web server and middleware software. Other leading IT services firms include traditional consulting firms, such as Computer Sciences Corp., Accenture, and Capgemini. The list also includes HP, another company formerly focused on hardware that has made the transition to being an IT services firm.
• 2. Packaged software providers: Companies in the business of developing and selling prepackaged, off-the-shelf, or shrink-wrapped software/system. Microsoft's Project and Intuit's Quicken, QuickPay, and QuickBooks are popular examples of such software. It serves many market segments and computer platforms. Almost 98% of Microsoft's revenue comes from its software sales, mostly from this Windows operating systems and its personal productivity software, Office. Oracle, is exclusively a software company, known primarily for its database software, but it also makes enterprise systems. SAP develops enterprisewide system solutions. Some off-the-shelf software systems cannot be modified to meet the specific, individual needs of a particular organization (called turnkey systems). The producer of a turnkey system will only make changes to the software when a substantial number of users ask for a specific change. A reasonable estimate is that off-the-shelf software can at best meet 70% of an organization's needs. Thus, even in the best case, 30% of the software system does not match the organization's specifications.
• 3. Vendors of enterprise-wide solution software (ERP vendors): Complete software solutions, called enterprise solutions or ERP, to support their operations and business processes. It's a system that integrates individual traditional business functions into a series of modules so that a single transaction occurs seamlessly within a single information system rather than over several separate systems. These ERP software solutions consist of a series of integrated modules. Each module supports an individual, traditional business function, such as accounting, distribution, manufacturing, and human resources. The difference between the modules and traditional approaches is that the modules are integrated to focus on business processes rather than on business functional areas. For example, a series of modules will support the entire order entry process, from receiving an order to adjusting inventory, shipping, billing, and on to after-the-sale service. The traditional approach would use different systems in different functional areas of the business, such as a billing system in accounting and an inventory system in the warehouse. The benefits of the ERP include a single repository of data for all aspects of a business process and the flexibility of the modules. The disadvantages are several. The systems are very complex, so implementation can take a long time to complete. Organizations typically do not have the necessary expertise in-house to implement the systems, so they must rely on consultants or employees of the software vendor, which can be very expensive. There are few major vendors of enterprise solution software. The best known are SAP AG and Oracle. Some firms use best-of-breed strategy instead of to deal exclusively with a single vendor. It's a strategy of using different software products from different sources (including in house development) to capitalize on the strengths of different products; for example, a firm might use SAP's order entry modules and Oracle's financial and human resources products.
• 4. On-demand computing providers: Customers pay for IT services only as needed. Another method for organizations to obtain computerized applications is to rent them or license them from third-party providers who run the applications at remote sites. Customers pay for IT services only as needed, much like they pay for utilities such as electricity, where a standard rate has been set for services, with itemized bills for bandwidth, data center usage, etc. Companies do not have to buy their own servers and the personnel to run and maintain them. It's the use of computing resources on the basis on a pay-per-use basis (IBM calls this service); also called utility computing (HP calls it) ("pay as you go"). On-demand, or utility, computing is in its infancy. It will take some time for large providers like IBM and HP to tie together all of the infrastructure and monitoring controls needed to provide computing services in the same way utilities provide electricity. On-demand computing is focusing on the provision of total computing services. Industries that invest heavily in IT and have standard business practices, such as financial services and telecommunications firms, are expected to be the most likely customers. Could be the future trend.
• 5. Open-source software: Systems software, applications, and programming languages of which the source code is freely available for use and/or modification. It's freely available, not just the final product but the source code itself. It's developed by a community of interested people instead of by employees of a particular company. It performs the same functions as commercial software, such as operating systems, e-mail, database systems, and Web browsers. Some of the most well-known and popular software names are Linux, the operating system; mySQL, a database system; and Firefox, a Web browser. Apache is another example. Open-source also applies to software components and objects. It is developed and maintained by communities of people (independent members of computing community), and sometimes these communities can be very large. Developers often use common Web resources, such as SourceForge.net, to organize their activities. Two primary ways companies and individuals can make money with open-source - (1) by providing maintenance and other services, or (2) by providing one version of the software for free and selling a more fully featured version.

Producers -> When to go to this type of organization for software -> Internal staffing requirements

• 1. IT services firms -> When task requires custom support and the system can't be built internally -> Internal staff may be needed, depending on application
• 2. Packaged software producers -> When supported task is generic -> Some IS and user staff to define requirements and evaluate packages
• 3. Enterprise-wide solutions -> For complete systems that cross functional boundaries -> Some internal staff necessary, but mostly consultants
• 4. On-demand computing providers -> When the company already invests heavily in IT and has standard business processes -> Ideally, none
• 5. Open-source software -> When the supported task is generic but cost is an issue -> Some IS and user staff to define requirements and evaluate packages

• The practice of turning over responsibility for some or all of an organization's information systems applications and operations to an outside firm
• The practice of one organization's developing or running a computer application for another organization
• It includes a spectrum of working arrangements: (1) at one extreme is having a firm develop and run application on their computers - all you do is supply input and take output, ex.: payroll; (2) you might hire a company to run your applications at your site on your computer.
• Why/rationale:
• (1) Cost effective such as payroll; if a company specializes in running payroll for other companies, it can leverage the economies of scale it achieves from running one very stable computer applications for many organizations into very low prices;
• (2) Allows access to increased knowledge and expertise that may not be available internally (Access to larger talent base);
• (3) It enables companies to take advantage of the availability and quality of vendors who provide outsourcing services;
• (4) Freeing up internal resources;
• (5) Increasing the revenue potential of the organization;
• (6) Reducing time to market;
• (7) Increasing process efficiencies;
• (8) Outsourcing non-core activities;
• (9) Enables company to better focus on core business;
• (10) Faster delivery;
• (11) Increased accountability;
• (12) Internal resources can be freed for other tasks; potential for increased revenue by transferring staff to profitable activities

• 1. Onshore team: The onshore business leadership team must take a hands-on approach. They must ensure that the offshore team delivers business benefits. The onshore team has to ensure that the offshore team delivers both technical and business benefits.
• 2. Program management: Offshore projects are very susceptible to changes in budget, timing, and deliverables. The program management team needs to be able to redeploy resources as needed and to anticipate change before it happens.
• 3. Delivery of benefits: Early benefit delivery from offshore projects is very important in proving feasibility and sustainability of service. Specific benefits need to be aligned with each requirement and linked to implementation milesones. It is important to plainly map dependencies so that it is clear what needs to be done to deliver a particular milestone.
• 4. Change and project management: The geographic separation and mix cultures inherent in an offshore project increase risk, worsen that arise, and lengthen time to resolution. A back-to-basics approach in project and change management will increase the chances of success. The offshore vendor's and the client's responsibilities need to be clearly defined and understood by both parties.
• 5. Geographic and cultural differences: One of the greatest challenges is overcoming differences in language, culture, and geography. While good communication is important to any project, it is crucial to offshore projects. The onshore company has to be aware of cultural differences and their effect on how directions are received, problems resolved, and responsibility delegated. When agreeing on schedules or reviewing specifications, onshore project managers should ensure that everyone correctly understands the details. Scheduling is also made difficult by differences in the number and timing of local holidays and vacation practices across countries. In some countries, for example, workers may typically get 4 to 6 weeks of paid vacation per year.

• 1. Document corporate processes and get vendors to sign off on them
• 2. Have vendors perform background checks on their staffs
• 3. In some countries, such as India, ask vendors to hire only applicants who have Indian passports, which can be acquired only after passing vigorous security checks by Indian law enforcement
• 4. Have vendors increase security awareness through employee training
• 5. Write security and regulatory compliance concerns into the procurement contract
• 6. Visit offshore outsourcing facilities and check them out personally
• 7. Investigate and understand local laws regarding internet access and restrictions

• •Security issues – different attitudes about privacy and property
• •Potential language/legal/cultural barriers
• •Change and project management critical
• •Requires close monitoring

• •Application maintenance
• •Disaster recovery
• •Help desk
• •Call Centers
• •Security
• •Telecom

• 10.1 Plan Purchases and Acquisitions (Planning Process Group)
• .1 Inputs
• .1 Enterprise environmental factors
• .2 Organizational process assets
• .3 Project scope statement
• .4 Work breakdown structure
• .5 WBS dictionary
• .6 Project management plan - (1) Risk register; (2) Risk-related contractual agreements; (3) Resource requirements; (4) Project schedule; (5) Activity cost estimates; (6) Cost baseline
• .2 Tools and Techniques
• .1 Make-or-buy analysis
• .2 Expert judgment
• .3 Contract types
• .3 Outputs
• .1 Procurement management plan
• .2 Contract statement of work
• .3 Make-or-buy decisions
• .4 Requested changes

• 10.2 Plan Contracting (Planning Process Group)
• .1 Inputs
• .1 Procurement management plan
• .2 Contract statement of work
• .3 Make-or-buy decisions
• .4 Project management plan - (1) Risk register; (2) Risk-related contractual agreements; (3) Resource requirements; (4) Project schedule; (5) Activity cost estimates; (6) Cost baseline
• .2 Tools and Techniques
• .1 Standard forms
• .2 Expert judgment
• .3 Outputs
• .1 Procurement documents
• .2 Evaluation criteria
• .3 Contract statement of work (updates)

• 10.3 Request Seller Responses (Execution Process Group)
• .1 Inputs
• .1 Organizational process assets
• .2 Procurement management plan
• .3 Procurement documents
• .2 Tools and Techniques
• .1 Bidder conterences
• .2 Advertising
• .3 Develop qualified sellers list
• .3 Outputs
• .1 Qualified sellers list
• .2 Procurement document package
• .3 Proposals

• 10.4 Select Sellers (Execution Process Group)
• .1 Inputs
• .1 Organizational process assets
• .2 Procurement management plan
• .3 Evaluation criteria
• .4 Procurement document package
• .5 Proposals
• .6 Qualified sellers list
• .7 Project management plan - (1) Risk register; (2) Risk-related contractual agreements
• .2 Tools and Techniques
• .1 Weighting system
• .2 Independent estimates
• .3 Screening system
• .4 Contract negotiation
• .5 Seller rating systems
• .6 Expert judgment
• .7 Proposal evaluation techniques
• .3 Outputs
• .1 Selected sellers
• .2 Contract
• .3 Contract management plan
• .4 Resource availability
• .5 Procurement management plan (updates)
• .6 Requested changes

• 10.5 Contract Administration (Monitoring and Controlling Process Group)
• .1 Inputs
• .1 Contract
• .2 Contract management plan
• .3 Selected sellers
• .4 Performance reports
• .5 Approved change requests
• .6 Work performance information
• .2 Tools and Techniques
• .1 Contract change control system
• .2 Buyer-conducted performance review
• .3 Inspections and audits
• .4 Performance reporting
• .5 Payment system
• .6 Claims administration
• .7 Records management system
• .8 Information technology
• .3 Outputs
• .1 Contract documentation
• .2 Requested changes
• .3 Recommended corrective actions
• .4 Organizational process assets (updates)
• .5 Project management plan (updates) - (1) Procurement management plan; (2) Contract management plan

• 10.6 Contract Closure (Closing Process Group)
• .1 Inputs
• .1 Procurement management plan
• .2 Contract management plan
• .3 Contract documentation
• .4 Contract closure procedure
• .2 Tools and Techniques
• .1 Procurement audits
• .2 Records management system
• .3 Outputs
• .1 Closed contracts
• .2 Organizational process assets (updates)

The process of determining which project needs can best be met by going outside the project organization to obtain them. Once the decision has been made to procure externally, planning contracting can begin. The main task of planning contracting is to create the documents needed to support the processes of requesting seller responses and selecting sellers. These documents are used to seek proposals from prospective vendors. They describe what is to be purchased and ask for offers from vendors who are interested in providing it. Common names for these documents include invitation for bid, request for proposal (RFP), request for quotation, tender notice, invitation for negotiation, and contractor initial response. The main task of requesting seller responses is to obtain bids that respond to the RFP. Once responses or bids are in hand, the process of selecting sellers begins. Here the bids are compared and judged by the selection criteria that the project organization has established. A vendor is chosen, and a contract is prepared. Contract administration is the process through which the project organization works with the vendor for the duration of the contract. Finally, once the terms of the contract have been satisfactorily met, contract closure begins. Both sides of the agreement accept the work performed, and the contract is completed.

• .1 Inputs
• .1 Enterprise environmental factors: Services and products available in the marketplace, the key providers, and the circumstances under which the services or products are available. (Assessment of available products and services and key providers; and any acquisition requirements)
• .2 Organizational process assets: Existing formal and informal policies, procedures, guidelines, and management systems that are considered in developing the procurement management plan; include lists of prequalified vendors, which limit the number of direct sellers to the organization. (Organizational policies/procedures/guidelines governing procurement; prequalified vendors)
• .3 Project scope statement: Provides the current boundaries of the project, including requirements, constraints, and assumptions; the most common constraint is limited funding.
• .4 Work breakdown structure: Hierarchical decomposition of the work to be performed by the project team; specific work.
• .5 WBS dictionary: Provides detailed statement of work that include descriptions of the work and resulting deliverables.
• .6 Project management plan - (1) Risk register; (2) Risk-related contractual agreements; (3) Resource requirements; (4) Project schedule; (5) Activity cost estimates; (6) Cost baseline: Provides the overall plan for managing the project and includes subsidiary plans that can provide guidance for procurement.

• .2 Tools and Techniques
• **.1 Make-or-buy analysis: A technique determine whether a product or service should be produced in-house, or produced from an outside vendor; now most are "buy."
• **.2 Expert judgment: Can be used to develop criteria for evaluating proposals submitted by vendors.
• **.3 Contract types: (1) Fixed-price contract; (2) Cost-reimbursable contract; (3) Time-and material contract.

• .3 Outputs
• .1 Procurement management plan: A plan that addresses such issues as who will prepare the evaluation criteria, how multiple vendors will be managed, where standardized procurement documents can be obtained, and how procurement will be coordinated with other project tasks.
• **.2 Contract statement of work (SOW): Document prepared for potential vendors that describes the service or product being sought in enough detail that potential vendors can determine if they can supply it. The SOW assures a common understanding of the project needs and is a very useful communication tool. It's not necessarily a static document; it tends to be revised and refined as it moves through the procurement process.
• .3 Make-or-buy decisions: A list of project products and services that the project team will either purchase or develop. This includes products and services needed to do the work of the project, as well as for operating the project's ultimate product.
• .4 Requested changes: Could result from planning purchases and acquisitions, and these changes are processed through the integrated change control process.

• A big part of procuring IT services is obtaining product support for your organization from the vendor of the services. Two key types of service contracts:
• 1. Incident-based support models: The organization is charged per incident by the service contractor; provide for the vendor to charge the client organization for each support related call the vendor handles. Two main reasons that incident-based support contracts are a bad idea - (1) A contract based on payment per support call provides an incentive for the vendor to sell bad or broken technology to clients; (2) They promote "incident hoarding," given that they are penalized for each call they make (i.e., they have to pay for each call with real money), customers search for other ways to take care of their problems rather than waste a support call; they may try to solve the problems themselves or engage in extensive searches on the Internet for solutions; such behavior may in the long run be even more expensive than support calls because customers waste time looking for solutions instead of doing the jobs they are paid to do and because the solutions they find may actually cost the organization additional money if they are so bad that they cause their own costly problems.
• 2. Subscription-oriented models: A single fee is charged by the service contractor for unlimited support; involves unlimited support from the vendor. Subscription-based support contracts give customers the opportunity for unlimited contact with the vendor's technical support staff; the emphasis in such contracts is on maximizing the value the customer derives from the technology the vendor delivers.

• The process of creating documents used to solicit proposals from vendors
• Creation of documents required to support the Request Seller Responses and Select Sellers processes

• .1 Inputs
• .1 Procurement management plan (from outputs of plan purchases and acquisitions)
• .2 Contract statement of work (from outputs of plan purchases and acquisitions)
• .3 Make-or-buy decisions (from outputs of plan purchases and acquisitions)
• .4 Project management plan - (1) Risk register; (2) Risk-related contractual agreements; (3) Resource requirements; (4) Project schedule; (5) Activity cost estimates; (6) Cost baseline

• .2 Tools and Techniques
• .1 Standard forms
• .2 Expert judgment

• .3 Outputs
• **.1 Procurement documents: Such as a request for proposal (RFP), evaluation criteria, and SOW updates. Updates to the SOW are simply revisions that are made as the result of plan contracting. Used to solicit proposals from vendors.
• **.2 Evaluation criteria: Criteria used to rate proposals that are received in response to a request for proposals. The criteria can be objective or subjective, and they are often included in the RFP. Used to rate responses from vendors to RFPs. Typically, the most important evaluation criterion is price; other criteria include how well the vendor understands the problem, whether or not the vendor has the technical ability to perform appropriately, and whether the vendor has or can obtain the financial resources necessary to deliver what is promised in the proposal. Buyers may also want to consider how long the vendor has been in business, how many employees the vendor has, whether an established vendor may be about to change business lines or emphases, and the number of other comparable projects the vendor has completed or is currently engaged in.
• .3 Contract statement of work (updates)

• The process of obtaining responses to the procurement documents produced during plan contracting
• .1 Inputs
• .1 Organizational process assets: Lists of qualified sellers which some organizations kept.
• .2 Procurement management plan
• .3 Procurement documents: RFP; can be sent to these vendors and any others that the project team has identified as potential bidders.

• .2 Tools and Techniques
• .1 Bidder conferences: Also called vendor conferences or contractor where members of the project team can meet with prospective bidders. At these conferences, project team members can explain the procurement process and goals, and potential bidders can ask questions. The answers may even become part of the revised procurement documents.
• .2 Advertising: In newspapers or trade magazines or professional journals.
• .3 Develop qualified sellers list: From the Internet, relevant local sources, or library directories.

• .3 Outputs
• .1 Qualified sellers list: Qualified vendors who are asked to submit a proposal (RFP), formal procurement document (called procurement document packages in the PMBOK), and the proposals themselves. Proposals may be supplemented with oral presentations if desired.
• .2 Procurement document package
• .3 Proposals

• The process of selecting a seller to supply the desired product or service
• The goal of selecting sellers is a contract with a vendor to supply the desired product or service; a contract is a legal relationship between parties, and it is subject to remedy in the court system
• .1 Inputs
• .1 Organizational process assets
• .2 Procurement management plan
• .3 Evaluation criteria: Have been established as part of the procurement process
• .4 Procurement document package
• .5 Proposals
• .6 Qualified sellers list
• .7 Project management plan - (1) Risk register; (2) Risk-related contractual agreements

• .2 Tools and Techniques (to discriminate among the bids so that a winner can be chosen)
• **.1 Weighting system: A method used to quantiatively compare proposals that are received from potential vendors. Each of the proposals is seen as an alternative solution, and each of the evaluation criteria are converted to attributes. A value is assigned to each attribute of each alternative. Attribute values are then multiplied by the weights to generate scores, and the scores are totaled across attributes to give sum totals for each alternative. The alternative with the highest score should then be the best one (chosen for the contract), and as such, it should be the best alternative in the set. Weights tend to be fairly subjective and, for that reason, should be determined through a process of open discussion to reveal underlying assumptions, followed by an attempt to reach consensus.
• **.2 Independent estimates: Estimates prepared independently of proposals which act as a check against the prices offered in proposals. Organization determines what they believe the estimate should cost. Major differences in these estimates and the prices in a proposal indicate the vendor did not adequately understand what was being asked for or did not respond fully. Sometimes these independent estimates are called should-cost estimates.
• **.3 Screening system: A system using minimum values for one or more performance criteria to eliminate proposals that do not meet the minimum values. For example, any rating below 3 is eliminated.
• **.4 Contract negotiations: Discussions between the buyer and seller to clarify and reach agreement on the structure and the requirements of contract prior to its being signed. All agreements reached to date should be reflected in the contract. Topics to be covered include responsibilities, authority, applicable terms and law, contracting financing, and price.
• **.5 Seller rating systems: A system used to select vendors based on factors such as past performance, quality ratings, delivery performance, and contractual compliance. Companies may have such information on vendors because they have dealt with them before and collected this information as part of the contract administration process.
• **.6 Expert judgment: Can be called upon to develop the criteria used to evaluate proposals, and it can also be used to evaluate proposal directly. Proposals can be circulated to domain experts from universities or the government or other organizations, and these experts can provide their own evaluations and rankings of the proposals, independent of the procuring organization. The expertise can also come from within the organization but from outside the project team and can include legal, financial, accounting, manufacturing, engineering, and other experts.
• .7 Proposal evaluation techniques

• .3 Outputs
• .1 Selected sellers
• .2 Contract
• .3 Contract management plan: An outline that guides the oversight of the contract during its lifetime.
• .4 Resource availability: The quantity and availability of resources and when they will be needed.
• .5 Procurement management plan (updates)
• .6 Requested changes

The process of comparing what was contracted for with what is being done or has been done to ensure that both parties perform according to the contract

• .1 Inputs
• .1 Contract
• .2 Contract management plan
• .3 Selected sellers
• .4 Performance reports
• .5 Approved change requests: Asked for by the project oganization; change requests may include changes to the terms of the contract or to descriptions of the work to be performed. Beware of constructive change orders issued by someone with actual or apparent authority.
• .6 Work performance information

• .2 Tools and Techniques
• .1 Contract change control system: Embodies the process, agreed on by all parties to the contract, through which the contract can be modified. Change requests, tracking mechanisms, processes for resolving disputes, and a process for approving changes are all key parts of the change control process. Agreed upon process through which the contract can be modified.
• .2 Buyer-conducted performance review: Structured reviewed of the vendor's progress in fulfilling the terms of the contract. They focus on how well the vendor has been able to adhere to the project's standards for quality and to the project's budget and schedule.
• .3 Inspections and audits: Conducted by the procuring organization, with the assistance of the vendor, to determine if there are any weaknesses or shortcomings in the vendor's work processes or deliverables.
• .4 Performance reporting: Process through which the vendor or supplier reports to the procuring organization about the progress it is making in fulfilling its contractual obligations.
• .5 Payment system: A system set up by the buying organization to pay the vendor for work performed, and payments are usually handled by the buyer's accounts payable system.
• .6 Claims (disputes) administration: The management of claims or disputes related to whether required work was done or what the submitted work is worth. The contract establishes the way in which claims are documented and managed.
• .7 Records management system: An automated record-keeping system and the processes governing its creation and operation that helps the project manager to keep track of contract documentation and results.
• .8 Information technology: Supports the record management system and many other aspects of contract administration, including the payment system, claims administration, and so on.

• .3 Outputs
• .1 Contract documentation
• .2 Requested changes
• .3 Recommended corrective actions: Consist of anything needed to bring the vendor into compliance with the contract.
• .4 Organizational process assets (updates): Include correspondence between the buyer and the vendor, payment schedules and requests, and seller performance evaluation documentation. This documentation is the result of buyer-conducted performance reviews, vendor performance reporting, and inspections and audits.
• .5 Project management plan (updates) - (1) Procurement management plan; (2) Contract management plan

• The process of verifying that all products and services contracted for are acceptable
• Supports the process of closing the project
• .1 Inputs
• .1 Procurement management plan
• .2 Contract management plan
• .3 Contract documentation
• .4 Contract closure procedure

• .2 Tools and Techniques
• .1 Procurement audit: A structured review of the procurement process from the plan purchases and acquisition process through the contract administration process.
• .2 Records management system

• .3 Outputs
• .1 Closed contracts: The buyer provides notice to the vendor that the contract has been completed.
• .2 Organizational process assets (updates): Include the contract file, which is a complete set of indexed contract records, deliverable acceptance, and lessons learned documentation. Deliverable acceptance is a formal written notice from the buyer that the deliverables have been accepted or rejected. Lesson learned documentation results from the analysis of the contract and the vendor used. It can provide useful information for future procurement planning.

• 1. Fixed-price contract: A type of contract specifying a fixed price for a product/service. The project requirements have been sufficiently detailed for suppliers to feel comfortable in establishing fixed price. The supplier or vendor is bound to the price provided in the contract. A fixed-price contract is less problematic when the product or service is well-defined.
• 2. Cost-reimbursable contract: A type of contract that involves payment for the actual cost of the product plus a fee that represents the vendor's profits. Costs are considered to be either direct or indirect. Direct costs are those incurred by the vendor in providing the product or service. Indirect costs, also called overhead costs, are part of the vendor's cost of doing business and involve such as things as the salaries of managing executives. Indirect costs are typically billed as a percentage of direct costs. For example, many sponsored research contracts between universities and government sources involve cost-reimbursable contracts, and indirect cost rates set by universities are as high as 50% or more.
• 3. Time-and-material contract: A type of contract where vendors provide an hourly rate and estimate the amount of time and materials required. It is possible to cap a T&M contract by asking the vendor to provide a not-to-exceed price. Otherwise, the price is open. For a T&M contract, it is often recommended that contract requirements specify review points and progress assessments. The contractor may also want to tie payment to deliverables.

• A document provided to vendors to ask them to propose a solution to a specific problem related to your project
• According to Porter-Roth, it's a standard tool used by governments and businesses to purchase equipment and services by promoting competitive proposals among suppliers
• It allows buyer and supplier to communicate using the same rules, requirements, schedule, and information
• Once a vendor responds to the request, the RFP becomes a foundation for the future working relationship between the buyer and the vendor (or supplier)
• The proposal prepared by the vendor often becomes a part of the final contract, as an addendum or exhibit, between the supplier and the vendor
• Time-consuming activities:
• –Creating the RFP (buyer)
• –Responding to the RFP (vendor)
• –Evaluating responses (buyer)
• Each may require a project team

• 1. Project overview and administrative information section: Contains an overview of the company and a statement of the problem the RFP is designed to solve; the administrative information part of this section lists all of the requirements for an acceptable proposal which include where and when to submit the proposal, if and when a bidders' conference will be held, the relevant dates for procurement, specific requirements for preparing proposals, how proposals will be evaluated, RFP staff contact names and addresses, and other information required for a supplier to be judged responsive.
• 2. Technical requirements section: Includes an overview of the relevant technical information so that potential vendors can determine if they can provide the solution that is being sought. This section will include technical factors critical to the success of the project, functional specifications, performance specifications, and so on.
• 3. Management requirements section: Contains information about the project's needs for implementation, installation, training, maintenance, and related matters, such as staffing requirements, installation schedule, and acceptance test requirements.
• 4. Supplier qualifications and reference section: A request for information about the potential vendor. Its purpose is to help the buyer determine if the vendor is really qualified to supply the needed product or service. Information requested includes the vendor's financial status, the number of its currently installed systems or components, and the names of customers who can provide references for the vendor.
• 5. Suppliers' section: Asks for any additional information the potential vendor thinks may be relevant. For example, the vendor here may explain a unique solution to the problem that the buyer had no previously thought about.
• 6. Pricing section: Provides a detailed format for vendors to follow to prepare their price proposals. Pricing can be broken down into separate items for such things as maintenance, licensing, and documentation. If the RFP is for a complete system, then the price proposal should include separate items for software, hardware, installation, systems integration, and so on.
• 7. Contract and license agreement section: Provides guidance to potential vendors on how to respond to contracts and agreements, and also provides contracts used by the buyer so suppliers can study them.
• 8. Appendices: Provide additional information that supplements the rest of the RFP or that was too technical or detailed to be included in the main body of the document.

• At the very least, an RFP must contain 4: project overview and administrative information, technical requirements, management requirements, and pricing.
• Creating and evaluating an RFP can take up to 6 months or longer, often a project in itself.

• Pre-REP Activities:
• 1. Identified need.
• 2. Perform initial study.
• 3. Write project justification.
• 4. Estimate budget for project.
• 5. Approve RFP project.

• RFP Activities:
• 1. Identify RFP team.
• 2. Identify project schedule and key dates.
• 3. Identify high-level requirements.
• 4. Start vendor and/or technology education.
• 5. Identify and interview users.
• 6. Develop technical requirements - (1) Review requirements with users; (2) Review requirements against corporate standards and constraints; (3) Finalize technical requirements.
• 7. Develop management requirements - (1) Review requirements with users; (2) Review against corporate standards; (3) Finalize management requirements.
• 8. Write RFP.
• 9. Develop evaluation criteria.
• 10. Develop RFP schedule.
• 11. Send RFP to suppliers.

• Post-RFP Activities:
• 1. Allow question and answer period.
• 2. Receive proposals.
• 3. Evaluate proposals.
• 4. Ask suppliers questions if needed.
• 5. Hold supplier presentations, site visits, demonstrations & reference checks.
• 6. Select winning supplier.
• 7. Negotiate contract.
• 8. Provide supplier debriefings for losing proposals.
• 9. Review, clean up and store losing proposals.
• 10. Start project implementation.

• I. OVERVIEW
• The [RFP Requestor] is the parent company of [RFP Requestor] , a leading global investment banking, securities trading and brokerage firm. Since XXXX, we have helped corporations, institutions, government and individuals reach their financial objectives. Clients have come to rely on the breadth of our expertise, out commitment to client service and out innovative approach to problem solving....[RFP Requestor] is seeking a partner(s) to assist the Information Technology Group (ITG) of [RFP Requestor] in performing a gap analysis of its technological capabilities against the requirements of straight through processing and T+1 settlement processing being promulgated by government regulatory agencies and various industry consortia.

• II. TERMS AND CONDITIONS FOR PROVIDING SERVICES TO [RFP Requestor]
• Vendor Personnel - All personnel assigned by Vendor to perform the Services shall be full-time employees of Vendor, shall be fully qualified to perform the tasks assigned to them, and shall perform the Services in a competent and professional manner....
• Insurance - Vendor shall maintain, throughout the performance of the Services under this Contract, a policy of workers’ compensation and disability Insurance with coverage limits as may be required by law of the states in which services are to be performed....

• III. TERMS AND CONDITIONS FOR RESPONDING TO THIS RFP
• A. General Conditions - This RFP sets forth the requirements for consulting services and solicits a detailed proposal from you to include pricing and other details in the specified format...
• B. Contract - Following selection of the vendor(s) to provide the Services further described in this RFP (each, the "Vendor"), this RFP and the terms of Vendor's proposal accepted by us will be incorporated in a fully executed, definitive contract (the "Contract")....
• C. Right To Negotiate With Other Parties - [RFP Requestor] reserves the right to award one, multiple, or no contracts pursuant to this RFP and proposal review process. Furthermore, [RFP Requestor] reserves the right to negotiate with parties other than those submitting proposals for delivery of some or all of the services described herein.
• D. Valid Period Of Your Offer - The prices quoted, as well as all other material terms of your proposal, shall be valid and binding, and not subject to change without our consent if accepted by us, subject only to changes agreed to by both parties in writing.
• E. Confidentiality/Non-Disclosure - The information contained in this RFP, your proposal as well as information accumulated through other written or verbal communication between you and us is confidential and proprietary to us, regardless of any statement contained in or accompanying your proposal or response....
• F. Right Of Rejection - [RFP Requestor] reserves the right to make all decisions regarding this proposal, including, without limitation, the right to decide whether any proposal does or does not substantially comply with the requirements of this RFP....
• G. Cost Of Proposals - Expenses incurred by you in the preparation of proposals in response to this RFP are your responsibility.

• IV. INSTRUCTIONS FOR COMPLETING THIS RFP
• A. Schedule Of Events - Release of RFP April 17, 2002....
• B. Completion Of Your Proposal - This section describes the general requirements for completing your proposal....
• C. Submission Of Your Proposal - Please submit five hard copy proposals and one electronic version of your proposal....
• D. Intention To Submit A Proposal - You must notify us of your intention to submit a proposal no later than 5:00 PM (EST) on April 18, 2002....
• E. RFP Questions - Any questions or comments regarding this RFP must be submitted via e-mail to RFP Response Lead by 3:30PM (EST) on April 19, 2002....
• F. Project Staffing - Each vendor is required to submit the following information with respect to team composition and fees....
• G. Professional Fees And Expenses - [RFP Requestor] prefers to receive a fixed price bid for this project....
• H. Structure Of Vendor Response - Each vendor shall submit the response to this RFP in both electronic and hard copy form in accordance with the conditions set forth in the section entitled III....

• V. STATEMENT OF WORK TO BE PERFORMED
• Project Overview
• [RFP Requestor]’s principal interests are to: (a) perform a gap analysis between the market and regulatory requirements of T+1 settlement processing and the capabilities of our current information technology platforms to meet these requirements....
• Detailed Work Plan
• The following work plan illustrates the key steps that the vendor must propose to undertake....
• Stage 1 – Gap Analysis
• Activities: Create a current map....
• Stage 2 – Solutions Identification
• Activities: For each deficiency identified....
• Stage 3 – Concomitant Benefits Identification (may be combined with Stage 2)
• Activities: In this phase the vendor should identify....
• Stage 4 – Project Plan for Selected Strategy
• Activities: Pursuant to approval....

• VI. ATTACHMENTS
• A. Summary Statistics
• The current environment consists of approximately:
• Back Office Applications = 600...
• B. Infrastructure Overview
• See files labeled Attachments A & B

Executive Summary - This document provides the PROVIDER response to the CLIENT Request for Proposal (RFP) for the Information Technology T+1 Settlement Readiness Assessment....

• Section I - Vendor Understanding Our Purpose and Objectives: in this section the vendor will describe in general terms, the firm’s understanding or view of the current T+1 requirements and issues and of CLIENT’ requirements for this initiative as discussed in Section V. Statement of Work to be Performed.
• PROVIDER Response - PROVIDER Understanding of the Current T+1 Requirements and Issues....

• Section II - Overall Approach to the Engagement: in this section the vendor will describe in general terms, the proposed organization of the project team and the top level phasing of activities, analyses and deliverables and high level schedule or timing.
• Introduction - The approach that we have taken to this study....

• Section III - Detailed Project Plan: in this section the vendor will provide, a detailed project plan that shows week-by-week the expected set of activities, events, analyses and deliverables for addressing the tasks described in Section V. Statement of Work to be Performed. CLIENT recognizes that this section will be subject to modification as the analysis develops and in response to availability of key personnel, but the schedule should be complete in showing the set of activities that must be accomplished and their approximate sequencing. This section will be used to demonstrate the vendor’s knowledge of activities and analyses that must take place with enough depth that CLIENT can be confident that the vendor can successfully complete the assignment in the proposed timeframe.
• PROVIDER Response - Below is the estimated schedule for the T+1....

• Section IV – Summary of Deliverables: in this section the vendor will summarize the key deliverables being proposed including: (1) The name or title of the deliverable; (2) The expected (approximate) timeframe proposed for delivery; (3) A description or overview of the contents of the deliverable; (4) Any other information about the deliverable (optional)
• PROVIDER Response - PROVIDER will deliver the following Type II Materials as defined in the PROVIDER Customer Agreement....

• Section V – Project Staffing: In this section, the vendor will provide staffing details of the proposed team per the instructions contained in Section F, above.
• PROVIDER Response - Below are key members of the PROVIDER team....

• Section VI – Fees and Expenses: in this section the vendor will provide a detailed explanation of proposed fees and expenses as contained in the instructions, Section G, above. If any limits exist on the proposed terms of the bid (e.g., expiration date), the vendor will so note in this section.
• PROVIDER Response - PROVIDER will provide an estimated 12,200 hours of services at an hourly rate of $205....

• Section VII – Administrative Information: In this section the vendor will provide administrative contact information, including Points of Contact, telephone numbers, office addresses and email addresses.
• PROVIDER Response - The following individuals are contacts for Administrative Information....

• Appendix A – Project Change Control Procedures
• The following provides a detailed process to follow if a change to this Statement of Work (SOW) is required....

• Appendix B – Financial Instruments & Associated Processes
• This chart highlights the trade related processes....

• Appendix C – Detailed Project Plan
• (Charts of Schedules)

• Appendix D – Sample Resumes
• (Consultants Resumes)