IJIS Factor Blog   |   Contact Us   |   Sign In   |   JOIN US!
IJIS Procurement Innovation Blog
Blog Home All Blogs
The IJIS Institute's Procurement Innovation and Interoperability Standards Advisory Committee addresses issues specific to how government and private industry can more effectively collaborate to drive innovation and fuel change in the procurement process through defining best practices. Through this committee, IJIS Institute Member companies work with public sector partners to drive change that is beneficial for all while improving the understanding of how standards adoption can inform and improve the IT procurement landscape. The IIS Procurement Innovation Blog is intended to discuss issues relevant to procurement innovation and interoperability standards and provide information on procurement resources.

 

Search all posts for:   

 

Top tags: procurement  RFP  SOA  budgeting  Cloud Sevices  Communications in Procurement  contract performance  Enterprise Architecture  Governance Structure  GRA  interoperability  NIEM  open standards  planning  Pre Planning  pre-RFP  Procurement History  RFI  risk  Risk Management  Technology  Timing in Evaluation  web services  WSDL  XML 

Interoperability Standards and the Procurement Process

Posted By Robert Shumate, Wednesday, June 3, 2015

Procurement methods should seek to identify a framework within which information transfer and interoperability requirements may be implemented quickly and economically as future needs dictate. Rarely, if ever, will a buyer know at the time of procurement all of the possible information interactions that the system will need to handle in the future. Buyers should specify that products or custom solutions must embody implementations based upon open standards rather than proprietary methodologies. Established open standards are more likely to have implementations available from a wider selection of product or solution suppliers thus increasing your selection pool and offering flexibility for future expansion.

As in other areas of procurement, the buyer should refrain from proposing detailed specifications regarding the information exchange methods being sought and, instead, request providers to specify in detail how their solution will be able to deal with the implementation of future and as yet unknown exchange requirements. Buyers should concentrate on developing requirements that identifying those standards and specifications the supplier’s solution must incorporate. Buyers have a responsibility to ensure that they have adequate technical representation on their procurement governance committee to fully evaluate approaches to interoperability being offered by providers. If necessary, this may be a point at which obtaining outside technical expertise in evaluating suggested approaches may be well worth the cost.

Avoid the snare of narrowly selecting a solution that only addresses a currently known interoperability requirement and focus instead on seeking a broad framework to interoperability that offers an ongoing agile and economically feasible way to implementing interoperability requirement that may be required in the future. It is very important that you require Suppliers to describe in detail how provisioning of their interoperability services is accomplished focusing on cost and timing for provisioning a new endpoint.

Interoperability is generally defined as the ability of heterogeneous networks, applications, or components to exchange and use information. Unless you plan on living in isolation in an otherwise connected world, it is essential that you specify a set of interoperability standards that must be part of the solution that you are seeking. This is even more important if you do not have a well-defined Enterprise Architecture in place since this will provide a structure for you to participate in exchanging data with other systems in the future. In the following sections, we will discuss what an open standard is, how open standards fit in an interoperability framework and how to approach data transformations in defining interoperability in the procurement process.

Read the full article in the attached PDF.

Download File (PDF)

Tags:  interoperability  NIEM  open standards  procurement  web services 

Share |
PermalinkComments (0)
 

Does Balancing Risk Improve the Procurement Process?

Posted By Robert Shumate, Tuesday, May 19, 2015

In recent years, much attention has been directed toward providing a more level playing field in risk management associated with the procurement process. Buyers have become more open to changing what in the past has been one sided risk positions where Suppliers were expected to assume most of the risk of project failure. This has come about as Buyers began to realize that unbalanced risk assumption was driving away some of their best potential suppliers. Efforts to change contract terms and conditions have gained favor, two examples of which are Oregon and California who in collaboration with the Supplier community have produced terms and conditions templates where the risk of failure is more evenly distributed between the Buyer and the Supplier. This is all to the good since suppliers have complained for years that unlimited liability, protection of intellectual property rights and performance bonds among others have made it difficult to assume the risk of bidding on technology contracts. While these steps may indeed increase the pool of perspective suppliers willing to submit bids on technology projects these risk mitigation initiatives do not by themselves improve the chances of  a successful completion of a technology contract. The penalty provisions in a contracts terms and conditions usually are enforced only after, the procurement and the ensuing project fail to achieve a successful conclusion. In 1995, the Standish group conducted a study of IT contract performance results. They found that 31% of such contracts were abandoned before completion, while 53% were challenged, defined as either over budget, late or did not deliver the required features (challenged). There is little evidence that contract results have improved that much during the ensuing period. In 2009, a similar study by Standish showed that the relative figures were 24% of the contracts were canceled and 44% were challenged. More recently (2013) the Code for America Foundation, the Omidyar Network, and the Sunlight Foundation conducted a procurement survey of local government entities to try to determine what problems local government entities faced.[1] Ninety-six percent of the survey respondents indicated that they face “significant” challenges in procuring technology projects. The relationship between the procurement process and the success or failure of the resulting project is even today not fully understood. It would be unreasonable to assign all of the blame for contract performance failures on the procurement process alone since management of the contract activities after the procurement is complete can be a contributor to failure. However many people who have examined contract failures believe that the procurement process itself is a significant contributor to the high failure rates. Based upon a number of studies the probability of any specific technology procurement producing a fully satisfactory result is less than 50%. Not all unsatisfactory results lead to penalties or litigation but the possibility of some level of failure is sufficiently high that both Buyers and Suppliers are highly incentivized to seek to reduce their risk level that are specified in the legal terms and conditions. Reducing the Suppliers level of risk make the likelihood of failure more acceptable but add only marginally to improving the chances that the procurement will result in a successful implementation. The real risks of a project failure lie in other elements of the current procurement paradigm. The following summarizes a few of the more compelling issues in procurement that jeopardize their success. The Buyer often does not organize the procurement effort to insure that stakeholders, technical staff, procurement and legal professionals as well as the Buyers project manager are involved under a competent leader with the authority to manage and move the process to completion in a timely fashion. However, an integrated project team alone doesn't mean that the procurement is integrated with the project plan.  Effective technology procurement should have a procurement strategy that is a component of the business case and is integrated into the technology project plan.  A misaligned procurement strategy can lead to project failure even if the procurement itself is awarded. Sometimes in technology related procurement, the using agency and therefore the buyer have not done an adequate job of identifying the problem that must be solved.  If the agency attempting that needs the technology does not understand the business objectives, the solution that the buyer is trying to purchase is unlikely to be successful. Buyers should prior to issuing a formal RFP, take the time to invite two or three Suppliers to make presentations of what solutions they have that would be applicable to the problem you are seeking to solve. This as a minimum requires the Buyer to expend the effort to think through and document the as is processes for which they are seeking a solution. Buyers can often use the RFI process to achieve this end but they should ensure that the process involves face-to-face presentations from qualified suppliers. Many RFP’s present prescriptive technical details that often do not reflect the best technology approaches to dealing with the problem. Add to that the inclusion of requisites that limit the responders’ flexibility to offer a more effective solution and you create a perfect situation for a Buyer ending up with a solution that will fail to meet their expectations. Buyers understand the business they are in and should concentrate on describing the problem they want to solve and rely on the Suppliers to propose the best technical solution. Communicate, communicate, and communicate. Once a formal RFP has been issued, Buyers should provide a forum for near real time response regarding questions that Providers may have regarding the requirements contained in the RFP. In today’s electronic world the ability to provide rapid response to questions while maintain transparency with other participating suppliers exists and Buyers should expend the effort to insure that communication lines are open throughout the RFP process. An open communication process will help reduce misunderstandings between the Buyer and the Seller regarding the requirements contained in the RFP. These are but a few of the elements that can help improve the procurement process. For a more complete examination of the elements in procurement that deserves consideration, see the IJIS Task Force Procurement Innovation Report.    

[1] Local Government Procurement Survey

Tags:  procurement  risk  Risk Management 

Share |
PermalinkComments (0)
 

Contract Oversight and Management

Posted By Robert Shumate, Thursday, May 14, 2015

This is the last of an eight-part series on procurement practices in information technology. This series is authored by Bob Shumate, a Member Emeritus of the IJIS Institute and the chair of the IJIS Institute’s Procurement Innovation Task Force. The material in these articles covers the findings of the Procurement Innovation Advisory Committee and offers some insight into the problems and solutions in procurement evident in today’s information technology markets.

There is a common misconception that, once the solution provider has been selected, the work of the procurement governance group is complete and that they have no further responsibility for oversight of the project. Best practices suggest that better project results are realized when the governance group remains involved throughout the contract performance period. Consider that this group has nurtured the effort from its earliest inception through the final signing of the contractual agreement and is aware of, and understands, all of the details of how the procurement was handled and the reason why certain requirements were included and other eliminated. If the group has followed suggested best practices, the buyer’s project manager will have been involved as part of the governance group from the outset and will become the principal point of contact with the contractor. The project manager acts as the intermediary between governance group and the contractor and manages the day-to-day interactions between the buyer and the contractor.

The support of the procurement group throughout the project is essential and the group should act as a resource for final resolution of disagreements that may arise during the project performance period. The group should also conduct periodic reviews of the project progress with both the Buyers project manager and the contractor’s project manager to remain familiar with progress and to obtain early awareness of any pending problems.

This is not intended as a dissertation on project management techniques and is directed solely toward the oversight role that the Procurement Governance group should assume during the performance period of the contract. Change is part of any IT effort, and few projects will reach completion without some type of change. While the day-to-day oversight of the project progress will be in the hands of the buyer’s project manager, there will be numerous situations throughout the life of an IT project where situations will arise that need to be reviewed and acted upon by the Governance Group.

Change Orders There will be change as the project progresses. Conditions will arise on both the buyer’s and provider’s side that require deviation from the original work plan. As progress on the project continues, better or different ways to deal with a process will become apparent, requiring a change in the work specification that may require either additional or fewer funds. The buyer may discover that needed data or personnel may not be available as planned, requiring a change in schedule. While routine changes may be approved by the buyer’s project manager, changes that materially affect the budget or the completion schedule should be reviewed, negotiated, and approved by the Governance group.

Dispute Resolution Disagreements will arise throughout the project over the meaning of a work statement, responsibility for a delay, or the acceptance of an interim work product, just to name a few. While an amicable and professional relationship between the buyer’s project manager and the contractor’s project manager can frequently lead to a satisfactory resolution, inevitably, there will be disagreements that are unresolved. The Governance group should act as the first line of arbitration, listening to both sides of the dispute and seeking an equitable resolution of the disagreement.

Task Acceptance Almost all projects include a series of work tasks that have specific acceptance criteria defined. Usually such acceptance is directly related to payment to the contractor for the work performed. The buyer’s project manager is responsible for making the recommendation for acceptance but the Governance group should sign off on the acceptance or resolve any disagreement between the buyer’s and contractor’s project manager regarding the status of the task to be accepted.

Scope Changes Routine change management has been discussed above, but, occasionally as the work progresses, it becomes apparent that there needs to be an adjustment in the scope of the work to meet needs that were not apparent prior to the project commencement. This may or may not involve additional budgetary requirements but may require work statement changes, contract modifications, and/or extension/contraction of the schedule.

Final Acceptance The final completion of a project and the turnover of the product is the final step in the process that began with the procurement planning stage. Based upon the recommendations of the project manager the Governance group will act as the final sign off authority accepting the product being delivered. Even in those cases where local legal requirements specify an explicit individual who has the legal acceptance authority the Governance group should review and recommend whether acceptance should take place.

The Governance group has an oversight responsibility to monitor project performance and should be established with this requirement in mind and given the necessary authority to exercise this obligation.

Comments welcome on this topic! Thank you for reading our special series in procurement practices in information technology.

For further reading: http://www.ijis.org/?page=Procurement_Resource

This post has not been tagged.

Share |
PermalinkComments (0)
 

Negotiating a Contractual Agreement with the Selected Supplier

Posted By Robert Shumate, Thursday, May 14, 2015

This is the seventh of an eight-part series on procurement practices in information technology. This series is authored by Bob Shumate, a Member Emeritus of the IJIS Institute and the chair of the IJIS Institute’s Procurement Innovation Task Force. The material in these articles covers the findings of the Procurement Innovation Task Force and offers some insight into the problems and solutions in procurement evident in today’s information technology markets.

If you have included the contract terms in the procurement document and have provided the opportunity for feedback from the RFP responders, you are probably in a position to reduce the time required to reach agreement as to legal terms and conditions. The selected provider(s) either already knows the terms that will be required or has negotiated acceptable changes and can be presumed to be ready to agree to them.

The contract is an important part of the procurement process and can absorb anywhere from a month to a year to reach final agreement depending upon the size and complexity of the work to be performed and whether or not there has been pre agreement to the terms as part of the RFP. Negotiating the contract involves reaching agreement as to the level of risk each party will accept in respect to performance of the service. The development of the contract agreement ideally should involve the professional procurement officials who are likely to understand the practical requirements and the jurisdiction’s legal representatives who can ascertain and advise as to the legal requirements of the desired terms.

Contract negotiations by their very nature are adversarial. Keep in mind that you will be entering into a relationship that will function best as a partnership rather than two adversaries seeing who can outpoint the other in working with the agreement. Attempt to keep negotiations civil, rational, objective, and as non-controversial as possible. Keep in mind that collaborative partnerships produce better results than the adversarial relationships that can easily develop during negotiations of the contractual agreement.

Contracts between the buyer and the solution provider need to be fair and balance the risks associated with the effort equitably between the two parties. Traditional approached to public contracting have, in the past, tended to place an undue risk burden on the solution provider. While this does reduce the buyer’s risk, it can also eliminate some of the best-qualified companies who are unwilling to accept the level of risk being demanded and result in the buyer having to accept less qualified providers.

No two contracts are exactly alike and circumstances will dictate many of the terms and conditions that are included in the final agreement. Further, many states, as well as counties and cities, have laws or administrative requirements specifying terms that must be included in a contract. However best practices advocated by numerous groups involved in procurement innovation suggest that the following areas deserve consideration.

Limitations on Liability

Solution providers should be prepared to accept liability for failure to deliver the solutions that they have offered and any direct damages resulting from contract breach. Few reliable companies are, however, prepared to accept unlimited liability including special and consequential damages, incidental damages, and third-party claims arising out of indirect damages. Contracts should contain caps on the amount of liability the provider may incur. This is usually either the amount of the contractor or some percentage multiplier of the contract amount. NASCIO’s 2010 survey found that the average state cap for liability limitations (in states that allow them) was between 150% and 200% of the contract value with the absolute floor being 100% of contract value. Generally speaking, you should balance the limitation of liability with the risk involved subject to whatever limitations may apply by law in your jurisdiction.

Intellectual Property Rights

As more RFP’s turn to COTS or SaaS approaches, intellectual property (IP) rights become less of an issue since license agreements contain specific provisions regarding IP and frequently include copyright or patent rights of the provider. However, procurements that require extensive modifications to a COTS product may involve serious IP issues. Contract terms that require that any work performed under the agreement become the property of the Buyer also tend to limit competition or result in using a less qualified provider due to the reluctance of a qualified supplier to relinquish IP rights to the work to be performed.

  1. The solution provider retains ownership of the IP and grants the buyer an unlimited, irrevocable, worldwide, perpetual, royalty-free, non-exclusive right and license to use modify, reproduce, perform, release, display, and create derivative works for, any State government purpose.
  2. An alternative approach is to reverse the process with the buyer having ownership of the intellectual property produced under the agreement and then granting the solution provider an unlimited, irrevocable, worldwide, perpetual, royalty-free, non-exclusive right and license to use modify, reproduce, perform, release, display, and create derivative works for any purpose.

There are of course numerous variations of language found in specific contracts but in principle these represent the two principal approaches to IP.

 

Performance Bonds


Generally speaking, the use of performance bonds in IT contracts should be avoided wherever possible since the requirement tends to discourage competition. Surety companies that issue such bonds do not know how to evaluate the risk of contract failure in IT contracts, thus, they are reluctant to issue such bonds to small- and medium-sized companies, making it impossible for them to compete. In the case of larger companies, to minimize their perceived risk, surety companies charge high premiums that will be passed on to the buyer. Further, current accounting practices require that such bonds appear on company balance sheets as a liability, which discourages even large companies from bidding on procurements that require such bonding.

There are numerous other ways in which the buyer can minimize the risk of failure including such practices as: payment holdbacks until defined tasks are completed and validated; project termination with damages, warranty remedies, and liquidated damages.

 

An excellent paper discussing the pros and cons of Performance Bonds in IT procurements is Leaving Performance Bonds at the Door for Improved IT Procurement prepared by NASCIO in collaboration with TechAmerica and NASPO.

 

Indemnification and Warranty


Warranties should guaranty substantial conformance to the contract requirements and freedom from material defects. Contracts that have terms stating that the results shall be free from defects are rarely acceptable to the solution provider because of the lack of limitations. The preferred approach is to warrant substantial conformance to contract requirements and freedom from material defects. Indemnity against claims of infringement should provide for the buyer to use the alleged infringing property while the provider defends such claim or replaces the infringing portion with a non-infringing solution.

 

Mutuality of Responsibility


If a contract is to have a successful conclusion, both parties must assume certain responsibilities. Agreements that attempt to place all of the responsibility for contract performance on the solution provider are likely to lead to problems during the implementation. Successful implementation of any IT contract requires that the buyer provide certain services including access to facilities, data, and people as well as timely reviews and approvals all of which can leads to project delays. Further, the buyer must provide a project manager with the authority to make decisions and meet the buyer’s responsibilities in a timely fashion. The contract should provide terms that provide contractual and financial relief to the solution provider that mirrors the penalties that would be assessed if the solution provider fails to meet their obligations. Mutuality provisions in the contract should be aimed at encouraging responsible actions on both parties to the contract by providing comparable penalties for failure to meet those responsibilities.


The above items by no means cover the entire range of contract issues. Further, the emergence of COTS solutions as a preferred means of addressing IT requirements require new terms and conditions to satisfy the requirements of this approach. The emergence of cloud computing is also generating a completely new set of requirements that have to be addressed as part of the contract negotiations. A recent collaboration between the private sector and the California Department of General Services resulted in a contract template for terms and conditions entitled General Provisions Information Technology that is a major step towards finding common ground between buyers and sellers on a number of controversial contract terms including those discussed above.

Next: Contract Oversight and Management

For further reading: http://www.ijis.org/?page=Procurement_Resource

This post has not been tagged.

Share |
PermalinkComments (0)
 

Evaluating Responses to the RFP and Selecting a Supplier

Posted By Robert Shumate, Thursday, May 14, 2015

This is the sixth of an eight-part series on procurement practices in information technology. This series is authored by Bob Shumate, a Member Emeritus of the IJIS Institute and the chair of the IJIS Institute’s Procurement Innovation Task Force. The material in these articles covers the findings of the Procurement Innovation Task Force and offers some insight into the problems and solutions in procurement evident in today’s information technology markets.

Perhaps the most significant provision is one that defines how the responding solutions provider may obtain information regarding both the RFP and the problem that they are being asked to solve. The nature of governmental private sector relationships are such that the procedure is usually restrictive and seeks to ensure that any information that is supplied to one entity must be made available to all entities who have submitted their intent to respond. Usually a limited period of time is designated during which responding solution providers may seek clarification of descriptions contained in the RFP. Responding solution providers are usually not allowed to talk directly to any individuals within the procuring entity who have knowledge regarding matters that relate to business or technical issues related to the solution being sought.

In the past, the process usually provided for a bidders meeting in which bidders were encouraged to ask questions regarding the RFP in front of the entire bidder group. Today, most procurement provides a means to electronically present question from the supplier to the buyer either via email or directly via a website. Questions are visible to all the invited participants as well as the answers to the questions. While the use of this type of approach has improved the communications process, it is hard to replace the interaction of face-to-face communications where one answer often leads to another question.

This approach provides the kind of integrity that governments seek in the way their employees comport themselves and ensures a sense of fairness for the solution providers responding to the RFP. On the down side it limits communication to such an extent that in many cases there is a disconnect between what the procuring entity thinks it asked for and what the responding solutions provider thinks they want. One improvement is to speed up the response to submitted questions by having a more interactive environment where electronic responses are provided in real time similar to what many help desk provide on a regular basis. Within the limitations imposed by law, administrative procedures, and customs, seek to provide the most open method of communication available to you.

It is probably no accident that Business-to-Business (B2B) procurements have a better performance record (although certainly a far from perfect one) than public procurements. In B2B procurement, the procuring entity encourages as much direct communications between the procuring entity and the solution provider including direct contacts to ensure that there is a mutual understanding of the problem to be solved.

Evaluating the Responses

The evaluation of responses and selection of the solution provider that will provide the services tends to be a complex process. The evaluation and selection process should be kept to the shortest possible time consistent with the need to ensure the best possible outcome. In a technological world where changes frequently occur in months it is not unusual to find that by the time of an award is made to a solutions provider new technological advances have made the proposed solution less desirable than a solution supported by new technological advances or even obsolete.

There are two major areas that the evaluation should focus on.

Evaluation of the solution provider’s capabilities. If you are to have a successful result from your procurement, as part of the evaluation you must decide whether the responding company has the ability to provide the solution it is proposing. While there is no perfect template for assessing the ability of a company to perform there are some areas that you should take the time to assess.

Take the time to ascertain what the organizations past experience in providing solutions to similar problems been. Has the organization been successfully in completing similar projects in the past on schedule and within the original cost estimates? Contact previous customers and get their candid assessment of the strengths and weaknesses of the organization in completing similar projects. This is why it is important to request that the solution provider to supply a list of all customers for the past three years rather than references the suppler selects.

Consider what level of resources the supplier has available within his or her organization to develop, install, and support the solution. Inquire as to what current commitments the organization has and how the commitments will affect the ability of the supplier to complete your project on within the proposed schedule. Key questions involve the number and type of personnel the supplier employs and particularly their availability for your project. If you are seeking a COTS solution, what type of support facilities does the proposer have for ongoing maintenance support?

Does the company have sufficient financial resources to implement the proposed solution if unexpected difficulties arise? Take the time to examine current financial statements and pose questions where appropriate regarding the suppliers ability to undertake the proposed solution.

Evaluation of the Proposed Solution. While it is important to insure that Solution Provider has the capability to deliver the proposed solution the more difficult part of the evaluation is to select among several proposed solutions the one that will best meet your needs. While each case is different, there are certain general principles that should be followed.

If you have asked the solution provider to present a solution to your problem rather than having attempted to specify the solution yourself this is where you have a chance to consider different approaches to solving your problem. This will require that you have sufficient technical expertise available to your evaluation team to be able to assess the technical foundations of each solution offered.

If you are seeking a COTS solution, approach to your problem either have the solution provider set up a demonstration of his or her product(s) or, even better, arrange a visit to a site where a similar solution is in operation to get feedback as to how well the system meets the needs of the user.

Evaluate in detail how the solution provider has responded to your hardware and operating system requirements set forth in the procurement document. Consider whether they will be providing the service levels, you requested through their own facilities or whether they will be using a third party to provide the services.

Evaluate carefully how the solution provider proposes to handle data exchange, interoperability and Identity Credential and Access Management within the proposed solution. You should be assured that facilities for data exchanges with as yet unknown entities would be available through a standard service interface, which is an integral part of the solution being proposed.

Consider payment approaches being offered. Among the different approaches are a license where the buyer pays a license at the time of system acceptance and enters into a maintenance agreement for maintenance support services, a subscription approach where payment for the service is on a monthly or quarterly basis and includes both license fee and maintenance support, a per use basis in which the Buyer pays usually a fixed amount per transaction processed by the system.

Making the Selection

The selection is usually made by the Governance Group consisting of the major stakeholders in the work that is to be performed by the selected solution provider. Procedures vary from location to location but usually the list of solution providers is reduced to a small number, usually no more than three, by the group reviewing the submissions, eliminating those that have not met the requirements set forth in the RFP and others whose response clearly do not meet the requirements specified in the RFP.

In most but not all cases when the non-compliant responses and those that clearly do not meet the perceived need are eliminated, the submitting solution providers are asked to make oral presentations. This may range in complexity from a single half-day presentation to a multiple day demonstration if software products are involved. This is an important part of the selection process and provides the opportunity to determine whether you have successfully communicated your needs to the seller. This is the point at which you need both your technical experts and your business process experts involved to insure that you fully understand what is being offered as a solution.

It is usual to defer cost analysis to the later stages of the selection process under the theory that it is important to insure that bids are compliant and that the best solutions are selected for final decision-making. In most cases (but not all) responding Solutions Providers are provided an opportunity to provide a best and final price after oral presentations are complete. This works best if you have been transparent regarding your budget since all bidders will be aware of the cost framework within which they must provide the desired solution.

Final Negotiations

Do not confuse final negotiations regarding the proposed solution with negotiating the contractual the agreement between the buyer and the solution provider. Final negotiations are detailed discussions between the buyer and the solution provider regarding the proposed solution, how it might be amended, and the impact such amendments would have on the price. Contract negotiations, which will be discussed in the next section, relate to the responsibilities that each party will assume under the effort.

This is an area that is highly controversial within the public sector. The issue that is the most difficult is the extent to which the procurement group should be allowed to negotiate simultaneously with multiple qualified bidders. This often presents difficult problems since the bidders may have different technical solutions and whether each party has been provided the same opportunity may be difficult to determine in any rational way.

Your jurisdiction may be subject to legal limitations that either prohibit or restrict the ability of the procurement body to negotiate with bidders regarding their proposed solutions. There is some evidence that the ability to negotiate the final conditions of the proposed solutions does result in improved outcomes. A recent article by Robert Metzger and Lauren Kramer highlights the importance of competitive negotiations and compares jurisdictions that permit such negotiations with those who prohibit such negotiations. Jurisdictions have been slow to change both legal restrictions and administrative regulations that either restrict or prohibit such negotiations.

Completing the Selection

The final step in this process is to complete the decision, obtain whatever sign offs may be required and notify the solution provider of their selection. Selections are always subject to the negotiation of a final signed contractual agreement and in some cases may be subject to a best and final price offering (BAFO).

The process suffers from some of the same limitations noted in previous sectors the most significant being the availability of technological knowledge within the selection group to be able to evaluate what are often competing complex solutions involving technologies that are difficult for laymen to understand. Again as in the previous sections, the procuring entity sometimes may have to resort to employing outside expertise to assist them in making rational decisions concerning the best-proposed solution.

Comments welcome on this topic!

Next: Negotiating a Contractual Agreement with the Selected Supplier

Future Posts:

  • Contract Oversight and Management
For further reading:http://www.ijis.org/?page=Procurement_Resource

Tags:  Communications in Procurement  Timing in Evaluation 

Share |
PermalinkComments (0)
 

Disseminating the Formal RFP

Posted By Robert Shumate, Thursday, May 14, 2015

This is the fifth of an eight-part series on procurement practices in information technology. This series is authored by Bob Shumate, a Member Emeritus of the IJIS Institute and the chair of the IJIS Institute’s Procurement Innovation Task Force. The material in these articles covers the findings of the Procurement Innovation Task Force and offers some insight into the problems and solutions in procurement evident in today’s information technology markets.

Once you reach the stage of issuing a formal RFP, you are likely to be governed by legal requirements or at the least by established administrative procedures that define how the formal RFP process must be handled. Use the both the legal and the procurement representatives on the governance committee to outline the boundaries of what you are allowed to do within the formal RFP process. Decide how you will proceed within the legal and procedural requirements governing this stage of the procurement and agree whether you want to seek any exemptions particularly to administrative rules.

Preparing the RFP document. The content of the RFP document will be dictated to some extent by existing legal and administrative requirements. In most cases, you will have some latitude in how the document may be structured and often you may find you have more latitude than you thought. Use the work that you completed during the preplanning and problem definition stage to prepare a document that describes the results you want to achieve and ask the suppliers to propose the best and most cost-effective way to achieve the results. Describe how the enterprise operates, how you want to change the business processes within the enterprise, and what you want the business process to look like. Examples of language that asks for a solution might be, “Currently applicants fill out a form that is subsequently entered to the system by a clerk using a computer terminal. The proposed system must allow applicants to enter their application data directly to the system via personal computers, mobile devices, and public kiosks supplied by the agency. The system currently processes 5000 incoming applications per day which is projected to grow to 8000 per day during the next five years.” In this example, you have stated a requirement of the system and are asking the supplier to propose a solution.

What should be included in the RFP? There is a wide difference between individual jurisdictions as to what should be included in the solicitation document. Provide your potential bidders with as much information as allowed by legal or regulatory requirements permit. Doing so will likely result in a more realistic response. Here are some of the items you should consider including:

  1. The problem statement already referenced in the previous paragraph. If local regulations require a prescriptive RFP approach, allow as much flexibility in response for alternate solutions as local custom or regulation permit.
  2.  Include the contract terms and conditions you expect the provider to agree to. If local rules permit, state that the supplier may propose alternative terms as part of the pre-submittal communications and be prepared either to agree to such alternative procedures or to reject them as part of the communications process. It serves no one’s interest for a supplier to be selected and then for both parties to find that agreement to the terms and conditions cannot be reached.
  3. Be as transparent as local rules and customs permit regarding your budget for the process. The argument that allowing suppliers to know the budget will encourage bids to the maximum available has been advanced as a reason for opaqueness in the procurement process. Responsible suppliers want your business and as part of the competitive process and are going to offer the lowest price consistent with the solution you require. Nobody ends up the winner when suppliers offer $10M solutions when you have a $5M budget.
  4. Equipment, operating systems, and support tools represent a significant part of ongoing costs so you should include within the solicitation document a requirement that responders offer alternative approaches to you purchasing and maintaining the support infrastructure.
  5. All RFPs require interpretation of some sort so make it clear how interested suppliers can seek responses to their questions in a timely manner. If possible, a highly-responsive system that allows questions to be entered online with interactive response (available to all bidders) would be the ideal method. If you do not have those facilities available, at least provide for responses within 24 hours of receipt of the question.
  6. Require that the provider supply you with information about the company. Always request audited financial statements (both P&Ls and balance sheets for the three most recent years) since financial stability can be a serious risk factor. Require that the bidder provide a list of all organizations to which the provider has supplied similar solutions during the past five years and permission for you to contact the organizations so you can decide which organizations to contact. Ask for any litigation that the supplier has or is engaged in that relates to contract performance.

Specifying interoperability standards required by system. Interoperability is generally defined as the ability of heterogeneous networks, applications, or components to exchange and use information. Unless you plan on living in isolation in an otherwise connected world, it is essential that you specify a set of interoperability standards that must be part of the solution that you are seeking. This is even more important if you do not have a well-defined Enterprise Architecture in place since this will provide a structure for you to participate in exchanging data with other systems in the future.

There currently are no widely endorsed templates for how you should word such requirements in your RFP but based upon ideas presented at the abstract level let us look at some practical approaches to defining interoperability standards. Continue with the concept of stating the problem or result you want to achieve and ask the solution provider to specify their proposed approach to a solution.

It is important that you specify that the standards you are requiring are Open Industry Standards. Be sure you understand the difference between Open Source and Open Standards. In general, terms Open Source refers to software and Open Standards refers to documents (that may then be implemented by software). There is no single global definition for either term; however, while most agree on the value of open standards for helping achieve interoperability, there continues to be some debate about how best to define Open Standards.

There are three general areas that you want standards to be addressed.

  1. The ability to exchange or receive data from any external system in a common format even though the internal data may be kept in a proprietary format. Require that the IT system you are seeking be able to send and receive data to or from other system using any schema that conforms to XML recommendation from the World Wide Web Consortium (W3C) using a Service Interface that will translate internal data elements to any XML-conforming schema and, similarly, expose available incoming XML schema’s to internal data formats. The Service Interface should be self-provisioning in respect to the inclusion of different schemas.
  2. The solution should include a public accessible repository called Service Interaction Profile* that defines the web services required to access the services available to a consumer It should include the ability to use the Web Services Descriptive Language (WSDL) to specify what web services you employ to exchange data between your system and other systems whose identity is unknown at present. Using WSDL lets you tell other users what web services you employ and how you will accept data. (*A service interaction profile defines a family of industry standards or other technologies or techniques that together demonstrate implementation or satisfaction of: service interaction requirements, interface description requirements, message exchange patterns, and message definition mechanisms.)
  3. The solution must provide a common identification and privilege management system to provide security for multiple users who have access to the system. This addresses the need for security in a framework that permits the exchange of information between different consumers and provides a framework for identity management by addressing the issue of authorization, or privilege management, within systems and applications in a federated environment.

The availability of these standards and the cost of their inclusion within your solution will be affected by whether you are seeking a COTS solution as opposed to a custom solution and also what type of cloud solution you are willing to accept.

Locating the appropriate solution providers. An important part of the RFP process is locating solution providers that have the expertise and experience to deal successfully with your problem. If, as suggested, you used the preplanning process to hold informal discussions with solution providers you may already have a list of providers who you feel have the capabilities you are seeking. If you do not as yet have a list of several solution providers with expertise relevant to the problem you are, trying to solve you has several options to seek such expertise.

  1. Turn to the procurement professional on your Governance committee to seek suppliers with the appropriate expertise.
  2. Use your website or a procurement website to announce the availability of the RFP and the desire for qualified solution providers to respond. Also, several private and public not for profit advocacy groups will supply you with a list of companies that have the type of expertise you are seeking if you are able to provide a definition of your business and the problem for which you are seeking a solution. Some of these groups are: the IJIS Institute, TechAmerica, and NASCIO.
  3. There are companies that specialize in providing procurement information to companies for a fee that will be happy to list your RFP if you supply them with the necessary information.

In soliciting suppliers to respond, try to strike a balance between larger companies who have a large pool of resources and smaller companies who may be more nimble in their ability to suggest innovative solutions to your problem.

How much time should be allowed for responses? Provide sufficient time for solution providers to take the same care in developing and proposing a solution that you took in preparing the procurement document.

Comments welcome on this topic!

Next: Evaluating Responses to the RFP and Selecting a Supplier

Future Posts:

  • Negotiating a Contractual Agreement with the Selected Supplier
  • Contract Oversight and Management
For further reading:http://www.ijis.org/?page=Procurement_Resource

Tags:  WSDL  XML 

Share |
PermalinkComments (0)
 

Defining and Articulating the Problem

Posted By Robert Shumate, Thursday, May 14, 2015

This is the fourth of an eight-part series on procurement practices in information technology. This series is authored by Bob Shumate, a Member Emeritus of the IJIS Institute and the chair of the IJIS Institute’s Procurement Innovation Task Force. The material in these articles covers the findings of the Procurement Innovation Task Force and offers some insight into the problems and solutions in procurement evident in today’s information technology markets.

Past approaches to technology procurement have emphasized the use of inflexible RFPs within which the buyer attempts to define, in detail, the technical solution that he expects and limits any deviation from the specifications. The problem with such an approach is that it assumes that the buyer is sufficiently knowledgeable, understands current technology, and knows how it should be applied. This is rarely the case since modern technology is evolving at ever-increasing speeds, making it difficult for the buyer to be cognizant of the latest and best technical solutions.

Avoid inflexible RFPs wherever possible. Inflexible RFPs force suppliers to limit what may be better-quality approaches to the problem in order to remain compliant under most current procurement rules. Avoid trying to describe how the technology should be applied to solve your problem and stick to describing the problem for which you want a solution. Rapidly changing technology may have made the approach you proposed obsolete or less desirable by the time the RFP is in the hands of solution suppliers. If, because of legal or administrative requirements, you must use a restrictive approach in your RFP, at least try to make the inclusion of alternative approaches to the problem an option to suppliers. Procurement documents that attempt to define how the problem should be solved and that contain rigid response requirements often discourage some of the best-qualified suppliers from bidding on your project because your approach may not be realistic. Further, it may limit your receiving a more cost-effective solution to your business problem.

Concentrate on defining the problem rather than the solution. Buyers understand their business processes far better than they understand the technology that may best be applicable to the results they wish to achieve. Concentrate on describing the business process(s) involved and what you want to achieve in improving the way they are handled rather than trying to specify the solution. This is an exercise that will require a significant effort to understand and describe your business practices. Describe how you want to change the business process to make it more efficient. The effort may lead you to a much better understanding of your business practices and thus make you more aware of how processes must change to accommodate technology. For example, it is a real change to avoid the manual keying in of data that could be electronically forwarded and added from another source without intermediate action, which may involve eliminating work positions as well as changing the entire way the in which the transaction takes place.

Structuring your RFP around a problem definition is by no means a short cut; in many instances, it is far more difficult since it forces the organization to take a detailed look at its business process and consider how they need to be changed to achieve efficiencies and provide better service to consumers. Remember throughout the process that technology is a means to and end and the business process is the important factor. Often the business process must undergo change to create the most effective adaptation with an IT solution.

Consider what standards should be included. This is the time to consider how and what standards requirements you should include in the procurement document. All IT systems today should be viewed as a single node on a global network of information sources. You must be able to serve as either a consumer or a supplier of information from other systems and be able to exchange data with other systems. No matter how carefully you have designed your Enterprise Architecture, or whether you do not have architecture in place, no one can foretell the future and additional requirements for data exchange will inevitably occur and your system must be able to add both consumers and suppliers in as seamless a manner as possible. Your system while remaining locally independent should have the ability to exchange and use information from heterogeneous networks, applications, or components while maintaining the integrity and independence of your system.

Standards such as the Global Reference Architecture (GRA) based to a large part upon the OASIS Reference Model for Service Oriented Architecture (SOA) defines at the abstract level how such architecture should be applied in defining standards. There is a difference between the architectural concept and the technical requirement that have been developed in support of SOA. Procurement requirements, by their nature, deal with technical needs because they specify what a service or a product needs to provide. We have to look to those requirements specified in SOA that translate into terms suitable for use in a procurement document.

(We will discuss in more detail how you should express these standards in the procurement document in our discussion on Preparing and Disseminating the Formal RFP.)

Consider your approach to hardware and operating system infrastructure. In the past, this usually meant you would request the provider to specify the hardware, operating systems, and database system needed to support the proposed solution. Today the options available are much more complex and require considerable thought to select the best approach to meet your needs at the most effective cost performance level. There are currently three approaches that should be considered in addition to the option of you purchasing and maintaining the required hardware, network connections, and operating systems at your site. Most of the approaches described below are provided on a subscription basis under which you pay only for the services utilized.

  • Infrastructure as a Service (IaaS): The Cloud Service Provider (CSP) supplies and manages the networks, servers, data storage, and the customer provides the rest, which includes the operating system, software applications, development tools, and related services.
  • Platform as a Service (PaaS): The CSP provides and manages everything including the operating system, development tools, servers, data storage and hosting to provide the customer with a development platform within which he can develop and deploy his applications.
  • Software as a Service (SaaS): The CSP procures and manages everything, including the software applications and related services. Some common examples widely used today are email services, document preparation applications, and accounting applications.

There are several ways in which each of these services may be deployed.

  • Public Cloud: The service infrastructure is remote, connected through the web and provides services to multiple clients using a shared infrastructure. Usually two types of services are offered, dedicated, and shared. Dedicated service means that the entire physical server(s) is dedicated to a single customer and is shared with no one else. Shared services mean that physical server(s) are shared among several clients with resources being allocated based upon demand.
  • Private Cloud: The service infrastructure may be located on your premise with the equipment owned and serviced by the CSP or at an offsite location on servers designated for and used only by you. Most CSPs offer private (dedicated) cloud facilities for IaaS and PaaS.
  • Community Cloud: The service infrastructure is used by several related customers such as other agencies within your political subdivision. The infrastructure may be located locally at one of the participating agencies with equipment being owned and serviced by the CSP or at an offsite location on servers dedicated for use only by the group.
  • Hybrid Cloud: The service infrastructure is a combination of different kinds of clouds (public, private, community) that exchange data and applications. You might for example have your applications running on a private cloud while part or all of your data storage is in a public cloud.

Decide whether you want to produce separate procurements for the IT solution and for the infrastructure hosting. Solution providers have becoming accustomed to serving as an interface between their customers and CSP and have become increasingly proficient in understanding the various tradeoffs between different approaches to infrastructure hosting. Depending upon your organization and the technical skill levels available to you it may make sense for you to negotiate directly with a CSP to get the best possible approach for your IT requirements.

Please feel free to add your comments on this topic below.

Next: Preparing and Disseminating the Formal RFP

Future Posts:

  • Evaluating Responses to the RFP and Selecting a Supplier
  • Negotiating a Contractual Agreement with the Selected Supplier
  • Contract Oversight and Management
For further reading: http://www.ijis.org/?page=Procurement_Resource

Tags:  Cloud Sevices  GRA  RFP  SOA 

Share |
PermalinkComments (0)
 

Preplanning For The Procurement

Posted By Robert Shumate, Thursday, May 7, 2015

This is the third of an eight-part series on procurement practices in information technology. This series is authored by Bob Shumate, a Member Emeritus of the IJIS Institute and the chair of the IJIS Institute’s Procurement Innovation Task Force. The material in these articles covers the findings of the Procurement Innovation Task Force and offers some insight into the problems and solutions in procurement evident in today’s information technology markets.

The first step in the procurement process involves deciding what it is the entity would like to achieve. In a very large number of cases, the procuring entity has only limited knowledge of the technologies that it seeks to acquire as a means of improving its performance. The first step toward a successful procurement is to establish a governance structure to both manage the process throughout the procurement itself and to maintain oversight of the project implementation. In almost all technology procurements, the governance structure should include:

  • Key enterprise stakeholders that will be affected by the newly acquired technology.
  • Technical specialists who have an understanding of the technology being sought.
  • Procurement professionals who manage the details of the procurement.
  • Legal representatives who understand the legal requirements inherent in the procurement.

Establish procedures for the governance group that will allow it to be nimble and responsive, recognizing that technology is ever changing and decisions need to be made promptly when required. While key players need to be involved, keep the total membership as small as the procurement requirements allow. Make sure that someone is in charge with the authority to call meetings, require decisions to be made as necessary and to ensure that the procurement remains on schedule.

An often neglected but critical aspect of pre planning is the need to create a road map that shows how the new technology will interact with other entities. Who will be the likely suppliers of information to the system entity and who will be the likely consumers of information generated by and available within the system? How will the acquired system(s) fit within the architecture at a higher level such as the county, state, or even national scope?

Enterprise architecture is vital for ensuring that information sharing for both the immediate needs and requirements that may occur in the future. Make the effort to determine what Enterprise Architectures may be in place that will affect your procurement and make the effort to develop an architecture that describes how your system will fit within the enterprise at all levels. Understand how you will share information in a way that minimizes the dependencies of each system on the implementation of other systems. One of the most important benefits of an Enterprise Architecture is identifying consumer systems from provider systems and identifying the type of services required to tie them together. This is the defining characteristic of a service-oriented architecture (SOA) and is the key to ensuring that your system will be able to deal with dependencies between systems both presently and in the future.

The Architecture should encourage the sharing of information and functionality between systems using open industry standards. We are living in a period where changes in technology are taking place monthly. The approaches that have become mainstream in the past five years include such concepts as Software as a Service (SaaS), Infrastructure as a Service (IaaS), Platform as a Service (PaaS), automatic provisioning, and cloud computing services – either private or public. All of these options come with advantages as well as challenges and there is no better time than the pre-planning period to become familiar with the advantages and shortcomings of these alternative approaches.

Use the pre-RFP period to gather information. Invite several companies to engage in informal discussions with the Governance Group to listen to the problem, which needs to be solved and to present their ideas of what a solution would look like. This is a great time to conduct informal presentations since the procurement process has not yet entered the formal stage and ideas can be freely discussed. Use this forum as a way to become educated in the solutions available and to get some idea of the costs associated with solutions that may be applicable to your problem. Depending upon the legal and administrative restrictions that are in effect in your jurisdiction, you may have to be creative to manage this portion of the effort. You may have to issue a formal RFI and then select a sub group to present their solutions to the governance group. While this may take a little more time, it will also work to give you insights into approaches to your problem that you had not previously considered.

The pre-planning period is the time to focus on what the changes you would like to achieve are going to cost. Because this is a period outside the normal RFP process, you can often use informal visits to get at least broad estimates as to the cost of different approaches. This is the time to reconcile what your budget is with the estimates you have received for different solutions. Unrealistic expectations that exceed the available budget almost always lead to disappointing results. This is the time for the governance group either to lower expectations or to seek additional funds for the anticipated project. Whatever you do, do not try to force a five million dollar project into a two million dollar budget.

Wherever able, be as transparent as possible regarding your budget for the technology you are procuring. Suppliers need to be able to present solutions that fit your budget and a lack of transparency regarding your budget often results in solutions well beyond what you can afford. Reputable suppliers will not try to offer a ten million dollar solution if they are aware that you only have a five million dollar budget and often may be able to propose solutions that fit within your budget. In the event that no supplier is able to offer a satisfactory solution within your budget, you can consider either revising your plans and seeking a solution that fits within your budget or postponing the procurement until budget conditions meet your needs. Both options are preferable to trying to implement a solution for which you have insufficient funding.

Use common sense when evaluating solutions and costs. If three suppliers price similar solutions in the ten million dollar range and a fourth offers the same solution for four million dollars be very skeptical and submit the proposed solution to additional scrutiny. Many times companies will propose solutions at unrealistic prices in the expectation that somehow they can fashion a solution within the available budget or use the change order procedure to make up the difference. Rarely does this result in a successful conclusion. Depending upon your size and the availability of internal resources with the ability to manage the preplanning process you may want to consider contracting with an outside firm to assist you in managing the procurement process. There are a number of companies that specialize in providing assistance to agencies in advising on how the process should be handled. If you do employ outside assistance undertake the same careful process you would use in selecting the final contactor to find a company that has the capability of providing the type of assistance that you need.

Comments welcome on this topic!

Next:Defining and Articulating the Procurement Problem

Future Posts:

  • Preparing and Disseminating the Formal RFP
  • Evaluating Responses to the RFP and Selecting a Supplier
  • Negotiating a Contractual Agreement with the Selected Supplier
  • Contract Oversight and Management

For further reading: https://ijis.site-ym.com/?page=Procurement_Resource

Tags:  budgeting  Enterprise Architecture  Governance Structure  planning  Pre Planning  pre-RFP  procurement  RFI  RFP  SOA 

Share |
PermalinkComments (0)
 

How Did Procurement Get This Way?

Posted By Robert Shumate, Thursday, May 7, 2015

This is the second of an eight-part series on procurement practices in information technology. This series is authored by Bob Shumate, a Member Emeritus of the IJIS Institute and the chair of the IJIS Institute’s Procurement Innovation Task Force. The material in these articles covers the findings of the Procurement Innovation Task Force and offers some insight into the problems and solutions in procurement evident in today’s information technology markets.

In our last Procurement Innovation Series post, we looked at whether or not the procurement process was broken. To understand current procurement practices it is necessary to examine the history of how current procurement practices between the public and private sector developed in the US. In the early part of the 20th century, collusion and corruption were widespread in the procurement process. Few formal rules governing the process existed and those that did exist were frequently ignored. Fortunes were made by unscrupulous suppliers working with corrupt government employees, which inevitably resulted in inferior results. Eventually public outrage at the process resulted in significant reforms to the process that became the basis for modern day procurement practices.

During that period, efforts to reform the process were directed toward preventing collusion between the sellers and the public officials handling the purchase of the services. Much of the procurement reform during that period centered on the twin concepts of transparency and maintaining an arm’s length relationship between the buyer and the seller. Further, the notion of fairness in seeking the best results from the procurement by providing a level playing field for all providers was also embedded in the reform movement. The reform movement occurred over a fifty-year period and became embedded in the procurement culture by the end of World War II. These changes underlie much of our current procurement process. During the period from 1950 until the end of the century, the process continued to be defined and codified in both legal requirements and administrative practices.

In the early 80s, procurement practices began an almost imperceptible but significant change as the concept of Supply Chain Management began to enter the lexicon of the procurement process. This concept gained significant traction in the 1990s as technology advanced to permit sophisticated schemes for supply chain management to be developed. While these concepts originated within the business-to-business community, the public sector has used many of these concepts to manage their procurement cycles particularly as it relates to commodity procurements involving supplies, equipment, non-technology services, etc.

During the latter part of the 20th century, procurement reformers began to become concerned that current procurement practices were ill suited to the process of procuring technology projects. Technology projects, such as information systems, involve complex procedures that are rapidly changing and often represent products not yet designed and for which there is little precedent, including the pricing of the proposed systems. The rigidity of current practices often did not permit buyers and sellers to communicate in such a way that mutual understanding of the problem was reached – often resulting in unsatisfactory results. This problem is only going to be exacerbated as we deal with the procurement of Cloud Computing, Software as a Service, Infrastructure as a Service, and similar technologies.

The objectives underlying the evolution of the procurement process are commendable and in the public interest. Past history is rife with examples of what happens when transparency and public scrutiny is subverted. Inflated cost and shoddy performance have often been the twin consequences of such lapses. The reforms of the first half of the 20th century served the public sector well until the beginning of the technology era (circa 1990) when the complexity of the technology began to come up against the rigidities embodied in prevailing procurement practices.

One of the most important questions that must be addressed is how to maintain the concepts of transparency and fairness in the procurement process and still allow for flexibility from the more rigid requirements for technology procurements. Solutions that may be available to improve the process will require a great deal of research, study experimentation and enlightened discussion between members of both the private and public sector.

The next article in the Procurement Innovation Series begin our coverage of the procurement process for technology products and services, which is divided into six segments. In each segment, we will discuss ways in which the procurement process can accommodate the needs of technology procurement without compromising the basic tenants of good procurement practices, transparency, and fairness.

Don’t forget to provide your comments!

Next: Preplanning for the Procurement

Future Posts:

  • Defining and Articulating the Problem
  • Preparing and Disseminating the Formal RFP
  • Evaluating Responses to the RFP and Selecting a Supplier
  • Negotiating a Contractual Agreement with the Selected Supplier
  • Contract Oversight and Management

For further reading: https://ijis.site-ym.com/?page=Procurement_Resource

Tags:  Procurement History  Technology 

Share |
PermalinkComments (0)
 

Is the Procurement Process Broken?

Posted By Robert Shumate, Wednesday, May 6, 2015

This is the first of an eight-part series on procurement practices in information technology. This series is authored by Bob Shumate, a Member Emeritus of the IJIS Institute and the chair of the IJIS Institute’s Procurement Innovation Task Force. The material in these articles covers the findings of the Procurement Innovation Task Force and offers some insight into the problems and solutions in procurement evident in today’s information technology markets.

Over the past three decades, technology procurement within the public sector has continued to produce substandard results in terms of subsequent performance. In 1995, the Standish Group conducted a study of IT contract performance results. They found that 31% of such contracts were abandoned before completion, while 53% were challenged, defined as either over budget, late, or did not deliver the required features (challenged). There is little evidence that contract results have improved that much during the ensuing period. In 2009, a similar study by Standish showed 24% of the contracts were canceled and 44% were challenged.

The collective attention on the procurement problem often points to events with significant media attention and key power players. However, thousands of technology contracts, ranging in size from two million to fifty million, end up as failed or compromised efforts and attract little attention beyond the parties affected, even though they collectively result in hundreds of millions of dollars of wasted effort.

So why are so many projects going badly?

Is the procurement process, as it currently exists, broken? If so, what does it take to make it more responsive to today’s technology needs?

Recently (2013) the Code for America Foundation, the Omidyar Network, and the Sunlight Foundation conducted a procurement survey of local government entities to try to determine what problems local government entities faced. (http://www.codeforamerica.org/blog/2013/09/27/the-state-of-local-government-procurement/) Here are some highlights from the survey effort:

  • 96% of the survey respondents indicated that they face "significant” challenges procuring technology.
  • 64% identified writing well-defined statements of work as a major challenge.
  • 25% identified finding enough qualified bidders as a major challenge.
  • 25% identified screening applicants as a major challenge.
  • 21% identified lacking institutional knowledge of effective technology as a major challenge.

The relationship between the procurement process and the success or failure of the resulting project is not fully understood. It would be unreasonable to assign all of the blame for contract performance failures on the procurement process alone since management of the contract activities after the procurement is complete can be a contributor to failure. However many people who have examined contract failures believe that the procurement process itself is a significant contributor to the high failure rates.

Procurement practices are often directed toward creating an adversarial relationship between the purchaser and the supplier. This is exacerbated by adversarial contract negotiations after the procurement is awarded that further cements the two parties as adversaries rather than two parties that have a common interest in producing an acceptable product at an agreed upon price. The nature of software and related services are sufficiently complex that a partnership between buyer and seller is more likely to create a productive relationship than when the Buyer and the Seller view each other as adversaries.

The procurement process, particularly as it relates to the acquisition of technology products or services, is a complex activity that involves a variety of activities and skills. Because of this, the concept of producing a comprehensive roadmap for changing the process is extremely complex and involves a very broad community of both public and private entities. When we speak of the procurement process, we are referring to procurement for technology projects primarily at the state and local government level. Procurement for commodities such as desks, vehicles, supplies and similar items, while important are not included in these discussions.

This Procurement Innovations Series will include eight articles, with this being the first. The next article will discuss how the procurement process got to the state it is in, and the remaining articles will cover the procurement process for technology products and services, which is divided into six segments. In each segment, we will discuss ways in which the procurement process can accommodate the needs of technology procurement without compromising the basic tenants of good procurement practices, transparency, and fairness.

Stay tuned for more on this incredibly important topic, and feel free to get involved in the discussion here and provide your thoughts.

Next: How Did Procurement Get This Way?

Future Posts:

  • Preplanning for the Procurement
  • Defining and Articulating the Problem
  • Preparing and Disseminating the Formal RFP
  • Evaluating Responses to the RFP and Selecting a Supplier
  • Negotiating a Contractual Agreement with the Selected Supplier
  • Contract Oversight and Management

For further reading: https://ijis.site-ym.com/?page=Procurement_Resource

Tags:  contract performance  procurement 

Share |
PermalinkComments (0)
 
Membership Management Software Powered by YourMembership  ::  Legal