4

Solution Provider Procurement

I have seen quite a few enterprises dealing with resource procurement just as if they were doing recruitment of employees. This is acceptable in situations where it is difficult to find qualified people as employees or where you need to replace an employee for a shorter period. However, it is not a good idea if you need resources to produce a specific solution to a complicated task, such as the setup and implementation of a COTS-based information system.

The resources you need for setup and implementation of COTS-based information systems are highly specialized and qualified people who can contribute to your total solution with an important part of an information system foundation, but you do not need them every day once the solution is in production.

Take a simple example such as the procurement of a car:

You do not employ engineers and technicians that produce your car; you just buy the car.

You can buy whatever service is needed to make the car run from a car service provider.

You might employ a driver to run the car or you might drive it yourself.

In this example, you procure a solution. You do not procure engineers and technicians because you would never be able to lead and manage them to produce what you need. Furthermore, you would not be able to provide them with the production environment needed.

In car procurement, this is obvious; when it comes to COTS system implementation, it is less obvious, but just as true.

Many organizations think that buying a COTS system is like buying a car once they have a number of product user licenses and a system operator in place.

They believe that once the COTS system has been delivered and runs on their IT infrastructure with access securely ensured to the users, the users just turn on their PCs, laptops, or other connected devices and run their business processes.

Even the most simple accounting or project management COTS system does not allow you to just turn the key and run even after training and operation management setup.

In order to be able to use and manage IT- and COTS-based information system solutions, you need competent users and an IT organization with three basic components:

Information System Management	IT Infrastructure Management	IT Service Management
This is the COBIT (www.isaca.org/) structured environment that ensures that business processes and users are supported to run the corporate business in an optimal way using their available information systems. This environment manages, for example: •  Requirements specification •  Solution development •  Solution implementation •  Solution governance	This organization runs the IT infrastructure using ITIL principles. It can be internal or it can be outsourced partially or completely. Cloud usage management would be part of this environment. Daily COTS operation is handled here with, among other tasks, the consolidation and reconciliation processes that ensure integrity and validity of data across systems and periods: •  Availability supervision •  Performance supervision •  Incident handling •  Problem management	This is the ITIL (http://itlibrary.org/) structured environment that ensures that the IT infrastructure is acquired and supported to be available and performing as required by the users. IT and COTS vendors are managed here: •  Service level agreements (SLAs) •  Release management •  Change management •  Error handling

A COTS system is not your information system solution.

What you want to procure is not a COTS system, but a solution, which is a business information system running just like a car; once the rules of conduct are established, the users are trained and sometimes certified, and the technical operators are competent to run the solution. You can use the ITIL and COBIT structure of organizational elements, processes, and objectives as a checklist to verify that your business organization and your IT organization cover these elements.

The COBIT standard comprises an Acquire and Implement section. You can get inspiration from this section to ensure that you do the right things, but the standard will not tell you how to do the things right.

The objective here is to show you an example of a relatively complex procurement of COTS systems and Solution provider services that went well under specific conditions, not to explain to you how to procure under all circumstances.

Procurement establishes a future required situation, in our case:

•  New COTS systems delivered and implemented

•  Solution provider service level agreements

•  User training

•  System operation

In order to succeed with procurement, you need to manage the risks involved with this process. Some of the more important risks comprise:

•  If you buy a COTS system before you have a detailed requirements specification, you will with high probability waste time and money because setup and implementation to fit your (unknown) needs will be a trial and error process until a feasible solution is established with very low probability of success.

•  If none of the potentially available COTS systems can contribute to your information systems needs without major changes or additions to their functionality, you might get important cost increases and solution delivery delays. In this case, we do not talk about parameterization and setup changes, but about changes not supported by the delivered COTS functionality.

•  A chosen COTS vendor always obtains a de facto monopoly once chosen and installed in your IT environment. You will be very weak in negotiations and might incur long lead times and high costs for adaptations in support of your business operations, especially facing business needs that are particular to your business if you do not foresee and include the conditions of these changes in the vendor contract.

•  If the COTS vendor goes bankrupt or in other ways ceases to do business, you lose support of your COTS system and you might need to procure another one. This is the background for the escrow clause in the vendor contract that is explained next. The escrow does not prevent you from losing money and time, but it might help you to protect your business information.

•  If the chosen solution providers and the COTS vendors do not have enough competent resources to set up the COTS systems and integrate them into your IT environment, you will encounter big delays in implementation and increased cost that you cannot recover.

•  The installation test performed by you and the COTS vendor is made on the COTS vendor’s contractual terms—you get what you see and that is all that the COTS vendor will guarantee, but this does not rule out serious errors seen from your point of view that the vendor looks at in a different way. This can create conflicts, delays, and increased cost.

•  If the best COTS solution does not use the same IT infrastructure that you have installed, the acquisition of this COTS system will require that you add to or change your IT infrastructure, which will add costs to not only new technology, but also costs and time to build the knowledge and organization necessary to run the new technology.

Once procured, you are still faced with risk of failure if you do not ensure that your IT infrastructure is properly maintained and supported, especially in the case where your COTS systems change versions, but not at the same time and not synchronized unless you ensure this synchronization yourself:

At one of our clients, we supported the upgrade to a new version of their Client Relationship Management (CRM) system. The CRM system was integrated with the client’s compliance control system that was legally required. The new version contained important solutions to legal requirements and had to be in operation fast.

    We had established a functional test model that showed that the CRM worked as it should when it was not integrated with other software. However, once receiving data from the compliance control system, the CRM system crashed. The compliance control system had not changed so we claimed that the error came from the CRM system, which the CRM COTS vendor refused to accept.

    It took quite a while before we discovered that the crash was related to incompatible data types that had not been a problem until the new version came about. The interface between CRM and compliance control was using a COTS application that was no longer supported in the marketplace.

    If the interface application had to be changed, we were faced with several weeks of development.

    The original COTS vendor agreement had an escrow clause and the escrow agent could deliver the interface source code to our client.

    So far so good, but no one in the client IT organization had a clue as to how to adapt the interface COTS system.

    In this situation, we found the names of the programmers who had installed the interface solution. They had established their own company, but they still had expertise concerning the interface COTS system.

    It took the experts 20 minutes to correct the situation once on board.

This example shows the importance of the escrow clause, but it also underlines the risk involved with complex IT environments using COTS systems from many different vendors.

Most organizations today are aware of these risks when buying new information systems based on COTS and they respond to the COTS procurement risk situation in different ways:

•  Some enterprises develop complete solutions based on a mix of COTS and their own development to be driven in their own proprietary IT environment, where the development and the COTS setup are delivered by turnkey solution providers. This is the typical banking industry solution, where confidentiality issues prevent data from being handled physically outside a country or outside the bank’s own IT infrastructure and secure IT environment.

•  Some enterprises develop complete solutions based on a mix of COTS and their own development, but this is run by a solution provider in the solution provider IT infrastructure. In this way, the enterprise can concentrate on its information system development and implementation supported by a turnkey solution provider. This can work out well if the IT solution provider is competent and if the information system user organization understands how to manage the IT solution provider, which unfortunately is rarely the case. Some cloud-based or System as a Service (SaaS) COTS-based solutions fit into this category.

•  Some COTS vendors develop industry specific ready-to-use solutions that they deliver as turnkey information systems. Smaller information system user organizations can profit from such a solution, but it should not be underestimated that the work with setup and training of the users still has to be done based on a good requirements specification. No COTS system on its own can be an information system. At a minimum, you need to add company-specific workflows and reporting. Today, this type of solution is typical in the cloud and it is widely used by physicians and dentists, for example, with standard integration and reporting to public health systems.

•  Some organizations buy a COTS system, install it, and perform an installation test provided by the COTS vendor in order to release payment to the COTS vendor for delivery of the COTS system once it has been proven to work in the dedicated IT environment. The user organizations then try to manage the setup and implementation of their COTS-based information system by themselves or by using competent resources from a solution provider with expertise and experience in the COTS setup. I have never seen this succeed without major scope changes, delays, and cost overruns in addition to deeply frustrated user organizations, even in the rare cases where good requirements specifications have been developed. The information system solution provider will inevitably accuse the COTS provider of delivering system components that do not work to spec, and the COTS vendor will claim that its system was never intended to be used as the information system solution provider has designed the solution. This is the situation in the bank information system swap case that we will (re)cover next.

•  Other organizations procure a turnkey solution to provide them with all the information systems they need. They leave it up to the turnkey solution provider to choose the COTS systems that they need for the solution and, quite often, they also let the turnkey solution provider choose and establish the type of IT environment that the solution requires. This is a very safe way for the solution demanding organization to get an information system solution that is feasible, if the underlying requirements specification is satisfactorily detailed and precise to ensure an acceptable solution, which is rarely the case. This is a very expensive solution, where the detailed requirements are developed by the turnkey vendor and where any change introduced after sign off on the requirements specification costs a fortune to implement. This is very often the situation with information system procurement in the public sector.

4.1    BANK INFORMATION SYSTEM SWAP RISK

Here the purpose is to describe a feasible case of COTS system and solution provider procurement in support of the bank information system swap case.

In this case, we used a solicitation, tendering, and contracting method that could allow us to minimize the risk of delivery failure even though some risks such as the COTS vendor contract terms giving this vendor absolute monopoly already had turned into problems, which would have to be worked around.

Most, if not all, problems with procurement occur because of bad procurement team building and risk management.

While the procurement team has the capability to Plan, Initiate, and Do the buying based on their high organizational level and access to funding, much too often they lack the capability to evaluate the outcome of the buying process.

If the procurement team does not act based on a good requirement specification, there is no way the team can evaluate the quality of what it has acquired. The purchase of COTS system cases that were previously presented are typical examples of this situation:

•  The electrical equipment distributor bought a system from a friend. This system is still not an information system and the company is using an increasing number of manual routines and spreadsheets to run the day-to-day business.

•  The bank bought a turnkey web-based solution for end user trading on multiple stock exchanges across the world, but forgot to ask the key-stakeholders if this was what they wanted. Unfortunately enough, the users did not turn up to make the solution profitable.

•  The bank management bought the same COTS application as a competing bank without considering their specific requirements. The initial implementation project failed completely. This situation could be recovered at a high cost.

The cases mentioned previously show the importance of risk management of procurement.

When you buy products and services from a vendor with de facto monopoly, there is a high probability that you cannot counteract bad performance from this vendor unless you contractually have ensured this opportunity to counteract.

The bank information system swap COTS system and solution provider choice and purchase are a good example of how procurement should not be done.

Bank management bought a COTS application without evaluating the risk from using a de facto monopoly as the provider of the COTS part of their future information system solution. In this situation, the bank management “forgot” to demand an appropriate Service Level Agreement (SLA), which resulted in the COTS vendor delivering solution components with errors that were so serious that it delayed the implementation process for several weeks.

That the bank management also acted without a requirements specification did not improve their risk situation.

In the case of human resource-based service procurement, the quality of what is procured is complicated to evaluate:

•  You can get a list of skills, but you cannot see if the person knows how to apply the skills, that is, the competence of the person even in the case of certified resources.

•  You can get a list of experiences, but you cannot see exactly how this person performed during this activity.

•  Some industries such as atomic power plants or oil production platforms require certified resources for production and maintenance, but even among certified persons you will find very different productivity and delivery ability.

•  Productivity of human resources differs enormously because the personality is playing a role, for example, some persons want to deliver perfect results irrespective of the time involved, while other persons deliver a feasible result fast.

•  You might obtain a guarantee of results delivered by the procured human resources if you demand it and if you have produced an appropriate requirements spec that focuses on results rather than on resource qualifications.

•  It might take a long time before you discover that the procured resources do not deliver what is needed if you do not manage the quality of delivered results very early in the delivery process.

4.1.1    Procurement Risk Mitigation

In the case of the private bank information system swap, a number of external resources had been working on the project for more than 18 months without any progress.

These resources had been delivered from three resource providers:

•  One person from the COTS vendor

•  More than 10 persons from a worldwide renowned consultant provider

•  One person from an agent selling “heads” based on their CV

The bank had not established a procurement team and it had not performed risk analysis of the procurement situation.

This lack of procurement team building and risk management is probably the most important cause of the encountered problems:

•  The project manager had simply demanded a gap analysis based on AS-IS and TO-BE observations of the current banking solution components—an impossible task to solve without requirements specifications. The future solution was not defined on a level where TO-BE could be compared with AS-IS. Nevertheless, the resource provider sold resources in bunches to do the job and to be invoiced based on delivered labor-months without responsibility for the result of the gap analysis.

•  There was no requirements spec telling the external resources what to do, how to do it, and most importantly why they should do it, so the external resources worked by intuition using whatever skills they had or could get from textbooks on gap analysis.

•  There was no competence expectation to the external resources except for their ability to do gap analysis, so they were all more or less junior management consultants without specific COTS implementation experience.

•  The resource provider invoiced by delivered labor-months, not by delivered results.

•  The project manager never questioned the methods used by the external resources.

•  An external resource was recruited from an agent that provided only one guarantee of quality: “The bank could cancel the resource contract with one month’s notice.” Here the bank was fully responsible for managing the external resource, who was later replaced by a qualified employee.

•  The COTS support person offered part time by the COTS vendor had very little COTS application knowledge and only reported documented problems back to the COTS vendor for correction. This reporting was of such bad quality that problems most often expanded instead of being solved. The COTS vendor had no further contractual obligation to deliver qualified resources for solution implementation.

•  No one had thought about producing a requirements specification because everyone thought that the COTS application would provide a solution once the data from the old information systems had been transferred to the COTS application and that the satellite information systems had been integrated with the COTS application.

If the bank had established a qualified and competent Strategy Governance Team to handle the information system swap, it could have eliminated most of these problems based on risk management.

One obvious response to the above risk situation is to transfer the solution delivery responsibility to the vendors of COTS and to potential solution providers because the bank had no experience in COTS implementation at all.

This risk transfer is not something that happens by itself because both types of vendors always act based on standard lawyer-produced contracts that explicitly place all solution delivery responsibility on the buyer.

The standard vendor contract explicitly limits the responsibility of the vendors to deliver their COTS product and listed resources as they are. They leave it up to the buyer to define the acceptance criteria and to control and evaluate that delivery takes place as agreed, a competence that the buyer most often does not possess.

Many organizations do not take up the fight in order to ensure the risk transfer because they lack tools and competence in this sort of negotiation. In this situation, they revert to buying turnkey solutions, where they leave the negotiation responsibility with the turnkey solution vendor.

Turnkey buying does not prevent the need of the buyer to produce a requirements specification if the buyer wants to be sure to get a feasible solution.

In some cases, the production of the requirements specification is done by the turnkey solution vendor, which in all the cases that I have seen has been a pure catastrophe. You need to separate solution quality management from solution production and implementation management. If this separation is not done, you as the buyer have to accept what you get.

The non-separation of quality management from production and implementation was done explicitly by a ministry that wanted to get a fast solution based on pure standard COTS functionality. Their objective was to adapt business to COTS functionality and not the other way around. They thought this would be safer and cheaper.

The ministry wanted to buy an ERP solution as a turnkey delivery. They produced a list of solution facilities that they would need.

Based on this list they asked a few very big COTS-based ERP-solution providers to bid for the delivery of their future COTS-based ERP information system solution.

The public buying process limited the number of possible vendors to five. All of these vendors used the same COTS system for solution implementation. In this case, it excluded a very competent local internationally renowned ERP COTS developer and vendor to be used for the COTS part of the delivery, which resulted in a big loss of local competence development and probably employment.

In order to ensure a satisfactory detailed solution description from the vendors, the ministry allocated €150,000 to each bidder who delivered a satisfactorily comprehensive proposal and solution description (to be their requirements specification) and who did not win the order.

The ministry and the future users were not able to evaluate the details of the proposed solutions, so they contractually committed themselves to accept and adapt their business to solutions that used the standard functionality of the COTS ERP system. This was not very smart because a COTS system does not have standard solutions, only standard functional elements that do not work and do not integrate as an information system before they have been set up to deliver a solution based on a detailed requirements specification. The facility list and the solution provider proposal were far from sufficient as requirements specs.

This solution requirements specification had to be developed with keystakeholder involvement after contracting. This was a major change to the signed solution provider contract.

The ministry and the future solution users were forced to accept whatever the turnkey vendor delivered. On top of this, the employees had to be trained to work with procedures that were completely new to them.

The implementation became considerably delayed. The cost overruns, especially the additional costs in connection with changes, were enormous.

The complete scope of the solution was continually adapted to what the turnkey vendor could and wanted to deliver, so by definition the delivery of the turnkey solution was a success.

Nobody bothered to ask the users and other key-stakeholders if they were happy because this was, by definition, the case.

The thinking behind this turnkey solution choice resembles the bank system swap case with one important exception. The ministry let the solution provider procure and install the COTS system, while the bank procured the COTS system and thought that they had bought a solution.

4.2    BANK CASE PROCUREMENT RISK RESPONSE

We had to establish solution provider procurement from scratch to ensure the bank information system swap delivery.

The procurement process demanded creative contracting and tendering terms in order to cope with the known problem and risk situation.

When we looked at the procurement tradition in the bank locally and even centrally, we could immediately understand that their legal condition-based standards were of very limited use in our case.

The problem situation of the bank project was good proof of the weakness of the bank’s current procurement policy:

•  Human resources were simply bought in bunches to be paid by the hour of work in confidence to that the resource provider would deliver resources that understood the information system swap need and who had knowledge and competence to solve this task.

•  There was no way the bank management and project management could control progress and delivery quality because there were no requirements specification to compare deliverables against.

•  The resource providers were not committed to deliver results, only person-hours. Result responsibility was solely on the shoulders of the Project Manager and the IT Director.

•  Money poured out of the bank based on used person-hours that did not deliver any usable solution to the bank.

•  The resource provider and the COTS provider used several weeks of bank employees’ working time to train them in COTS functionality that they would never use, and the bank had to pay for this service.

•  Almost two years were spent by the contracted human resources delivering only more problems and cost.

When this situation was closed out and the project declared in serious trouble, the procurement of additional COTS systems and important IT infrastructure components had not even been initiated.

Solicitation of the corresponding delivery opportunity situation had not been initiated either, which added a new problem because there were long lead times on important IT material that could delay the project.

The relatively complicated quality evaluation concerned with human resource service procurement demands that you perform risk management in order to obtain the following:

•  The resources can deliver results of the quality that you need and demand.

•  The aleatory resource availability is dealt with and the availability is controlled to be satisfactory.

•  The solution provider guarantees not only the quality of the resources, but also the quality of the results delivered.

•  You can manage the quality of delivered results from the human resources delivered by the solution provider.

•  The external human resources are motivated to work in a proactive way with the internal employee resources.

•  Internal employee resources work in a proactive way with the external resources.

These risk management objectives seem obvious, but much too often the risk management processes are not performed at all such as in this case.

For the core-banking information system swap, we would need solution providers and sub-contractors to perform the following jobs:

•  Set up the core-banking COTS system in support of the banking business.

•  Set up the COTS system-based reporting in support of:

•  Client reporting

•  Risk reporting

•  Public authority compliance reporting

•  Corporate reporting

•  Transfer live data from the old core-banking system to the new COTS-based one without losing information.

•  Integrate the core-banking COTS system with a future financial control COTS.

•  Integrate the core-banking COTS system with a future COTS system for reconciliation handling.

• Integrate core-banking COTS with a fund administration COTS under implementation.

•  Build the internal competence required to operate and use the future COTS information systems.

Fortunately enough the bank was not the only bank to use the core-banking COTS. Consequently, the COTS vendors of systems to be integrated with the core-banking COTS had a positive interest to succeed with this integration.

On the other hand, the core-banking COTS system vendor had a very bad reputation as an integration partner, which the bank could do very little about because it had already signed up for both COTS system and system support without an appropriate SLA to oblige the core-banking COTS system vendor to cooperate.

The initial project was replaced with a program managed by an appropriate Strategy Governance Team supported by a Change Management Board. The first task of this Strategy Governance Team was to perform the initial PQA process and to establish the Workgroups to create the missing requirements specification.

While these newly established Workgroups were struggling with the documentation of bank business workflows to be used for requirements specification, the Strategy Governance Team was “converted” into another Workgroup to execute the procurement of competent solution providers and sub-contractors for delivery of solution components, outstanding COTS systems, and missing IT infrastructure components.

In the beginning, we had thought that we just had to find COTS systems for finance and reconciliation, but it soon became evident that the core-banking system was delivered without a satisfactory reporting facility. The core-banking COTS system only handled transactions and a not too efficient integrity of its DB2 relational database. Reporting was the responsibility of the user organization based on a not very user friendly Application Programming Interface (API) to the COTS database.

Consequently, on top of the solution provider procurement we had to procure:

•  A financial control COTS system

•  The setup of a reconciliation COTS system

•  A reporting COTS system related to the core-banking COTS system

The new COTS system setup would have to be done in close relationship with the core-banking COTS system setup, so we decided to integrate the additional COTS system procurement with the solution component procurement in such a way that we could ensure IT, COTS system, and implementation resource availability for a very fast process with many parallel projects (Workpackages).

We were aware of the increased risk from many parallel projects, which we mitigated by building autonomous Workgroups for delivery of feasible results.

The total procurement activity gave us an opportunity to buy additional COTS systems that could be delivered with setup resources that had experience from integration with the core-banking COTS system.

In the luckiest case, the new best buy COTS systems had already been integrated with the core-banking COTS system at other clients; in the worst case, this was not the case and we would have to run the risk of failure if the COTS system implementers could not match the bank solution requirements.

In order to mitigate the worst-case risk, we would try to commit the COTS system vendors to deliver both COTS system and full integration of the COTS system with the core-banking COTS system, that is, turn the COTS system vendors into solution providers.

As mentioned previously, we established the Strategy Governance Team as the Workgroup for procurement of missing competent resources, COTS systems, and outstanding IT equipment. This looks very much like a centralized ivory tower-based buying organization without much contact to real banking needs. We were aware of this organization-based risk situation and did our best to avoid it by doing the following:

•  We got the users and departmental managers involved with requirements specification in the form of Workflows.

•  We visited the real implementers and their project managers in other banks approved by our and their management to understand the risk we were facing with the chosen and potential COTS applications.

•  We asked the reference banks about their experience with integration of other COTS applications.

•  We performed an appropriate solicitation of COTS and equipment vendors and solution providers in order to establish a list of competent potential partners although we had very little time to act.

•  We never panicked because we knew that one more bad selection of a partner would cause another disaster.

• We prepared a serious and dedicated call for tender that fully reflected our immediate needs and motivation to succeed.

•  We prepared all contractual terms beforehand. These terms would be able to ensure a win-win situation and could potentially transfer all possible solution delivery responsibility to the vendors.

•  Contractual terms and scope were not negotiable in order to ensure synergy and proactive attitude from all partners and bank employees and managers.

•  Change management was ensured in a way that could minimize conflicts except for the conflicts arising out of the missing SLA with the core-banking COTS vendor.

•  Only price and time were negotiable once the vendors had presented their accepted preconditions.

•  All test cases were developed and agreed to by both internal Workgroups and the corresponding solution provider teams before test runs, so there was “no excuse for failure.”

•  Payment could only be signed off once the end users had approved the solution delivered based on simulated and final Accept-Testing.

We had to develop a new set of contractual terms that were very different from European public and private standards.

European public and private sector contract standards have been developed by advocates working with the IT industry and IT user organizations with a view to protect primarily the buyer. This is understandable in light of all the failed deliveries and big scandals that you will find in the press.

As mentioned previously, the IT industry seller contracts were completely opposite and removed all result responsibility from the vendors. If the future user organization did not like what they got, as this was documented in the COTS user guide it was just too bad for the user. Error correction time was the sole responsibility of the vendor.

The problem was that such contracts did not in themselves present a guarantee of success. Any vendor could close his shop and restart business under another name. Already paid advances were lost and the public or private clients never got their solution on time.

In order to avoid another disaster, we decided to formulate other types of contractual terms that committed both buyer and vendor to do their best. These terms focused on common responsibility to succeed and placed just as much pressure on the buyer organization as on the vendor organization to allocate the best possible resources as required and agreed. You could say that these contractual terms reflected the “no excuse for failure” principle.

All this preparatory work took almost three months, but the investment paid off in the end. The bank never lost a partner in the process and the teams delivered a feasible solution.

Optimization was never addressed, only feasibility.

4.3    THE REQUIREMENTS SPECIFICATION

Whether you want to develop or to buy your future information system, you are obliged to provide a specification of requirements.

There are two basic forms of requirements specifications concerned with development and implementation of information systems:

1.  A list of functional, technical, and general features to be delivered by the contractors without specifying how these features must be established—you express what and the vendor offers how. You might have established a weighting system to the requirements because some requirements are more important than others are. You might also rate the how functionality offered by the vendor.

2.  A detailed design of the future information system solution to be set up by the contractors constrained by your technological infrastructure. You rarely find such requirements specifications unless you want the vendor to develop the solution from scratch. On the other hand, your business might be so special that it is the best solution to ensure your benefits.

In the case of the bank information system swap, the second form, relying on documented Workflows, was chosen because:

•  A list of features would make the spectrum of solutions too broad with the risk that the bank got a new solution with heavy training needs and the needs of cultural changes that were not demanded.

•  Workflows could ensure that bank working procedures would be maintained in the new solution, minimizing learning needs and optimizing Accept-Test performance.

•  Workflows resemble more a design than a list of features, but they are still open to COTS-specific user interfaces and reporting.

•  The implemented solution had to be established on COTS technology.

•  Integration had to be programmed from scratch using among other tools the COTS system API.

•  Reporting was very specific and demanded detailed report design.

On this background, it was decided to request competent people for solution delivery before equipment and COTS application delivery.

The chosen vendors and solution providers in all cases could choose their preferred COTS application to work with, except for the already acquired core-banking COTS application.

We wanted to be able to choose more than one vendor and solution provider in order to ensure an ability to get the most competent resources on board.

We knew that having more than one vendor and solution provider left us with a management task of important dimensions, but on the other hand, we had less risk of failure than with a turnkey delivery that we could not control.

In the end, the proposals that we could obtain would limit our choice under all circumstances.

4.4    SOLICITATION FOR COMPETENT CONTRACTORS

There were circumstances originating from our talks with the local reference banks that made us somewhat optimistic concerning our procurement strategy with new contract terms, detailed functional requirements based on Workflows, and our willingness to work with several vendors and solution providers concurrently:

•  Not one single reference bank using the core-banking COTS had good experiences from their implementation irrespective of choice of implementation partner. Here we had an opportunity to do better by using another method than theirs that for the most part had been based on turnkey solution delivery by a major solution provider that in all cases had delivered late with heavy cost overruns.

•  We knew that all the big consultancy firms had experience from former implementation of the core-banking COTS application, so some qualified resources might be available for our Workflow-based COTS setup. What we did not know was to what extent they had competence in setting up the parameters of the COTS application.

•  We got a list of potential partners from the reference banks to which we talked.

•  We established good relationships with project managers in the reference banks.

4.4.1    The Solicitation Process

Based on the list of potential partners, we invited them to tell us what they could do for us in light of the outlined tasks and Workgroups that we had documented in a PowerPoint presentation.

The three major bank-consulting companies in our local environment confirmed that they would bid if invited. They also confirmed that they had access to available and fully qualified resources to do the job within our very optimistic time frame of nine months from contract signature date.

The provider of the reporting COTS application was more of a solution provider than a vendor of COTS applications. This COTS vendor confirmed that it could deliver the reporting required if the bank could provide internal resources and requirements specifications to work with its report developers. This gave us even more hope because its report developers had profound experience from working with the core-banking COTS that we could drag on in our evaluation of work performed by other solution providers. The vendor’s requirements to be able to profit from and share knowledge with internal resources were just sweet music in our ears. At that point in time, we did not know how hard it would be to activate the internal IT resources.

All the reference banks had declared that the build-in reconciliation facilities in the core-banking COTS were unusable. The solution providers that we solicited confirmed this situation, but they could of course offer a COTS-based solution if the bank was willing to run the risk.

The bank already had an external provider of its current COTS-based reconciliation application; but this solution provider had never integrated its COTS system with the chosen core-banking COTS application before. As we had expected, it became very difficult for this solution provider to comply with our contract terms. Nonetheless, they were invited to bid.

The provider of a financial COTS application was very consultancy minded and declared that they would be happy to deliver a solution based on their COTS application. The final negotiations with them as partner turned out to be quite tough because they tried to avoid taking any risk on the sale of the COTS application and because we would not pay for the COTS application before the fully integrated solution had been Accept-Tested.

We also talked to a few major agents and other classical resource providers with experienced resources in our market, but they only sold heads, not solutions, which ruled them out as potential partners.

The result of the solicitation was a list of six potential partners, all of them committed to bid on some part of our call for tender.

4.4.2    Commitment of Internal Workpackage Workgroups

When we initiated the program after closing the original project, we solicited all internal IT employees who had been involved with the failed core-banking implementation.

To our big surprise, we discovered that the internal IT employees had been trained in the core-banking COTS system together with the future users only. This meant that they had no training or any form of experience with running or setting up the new core-banking COTS system.

This lack of education and experience had to be remedied immediately. The COTS vendor did not have resources available for this training. The COTS vendor system support personnel were prevented from working outside the COTS vendor premises, and actually no structured training in COTS internal technical facilities was available, only documentation.

After very tough negotiations with the COTS vendor, who claimed that it had delivered according to its contract, we obtained that the bank IT personnel could try out the COTS system at the COTS vendor site with access to limited support during the period we used for procurement of solution providers.

This opportunity was rarely used. We had clearly underestimated the lack of motivation among the IT personnel after the failed implementation project.

After this discovery was made, we simply distributed IT coordinators to all Workgroups with the very precise objective to ensure that IT infrastructure needs were resolved as needed and that the COTS system was installed and running in four environments:

•  Setup and interface development

•  Migration of new versions

•  Testing

•  Training

This worked out because of pressure from IT management, Workgroup management, and solution provider team management to get needed test and training facilities set up internally. Solution provider team management knew exactly what was required and the problem with COTS vendor support in getting these requirements fulfilled. They had seen the COTS vendor problems before.

4.5    THE CALL FOR TENDER

The Workflow-based requirements specification made the tendering process much easier to manage than a traditional tendering based on a demand for functional, technical, and general facilities:

•  There was no need to prioritize facilities because all Workflows had to be developed and implemented.

•  Workflows were classified into Workpackages.

•  There was one Workpackage for each banking functional area.

•  The potential solution providers could bid on one or more Work-packages to be delivered at a fixed price with a fixed deadline.

•  The bank Workgroups would create the Workpackage documentation in time for development and implementation.

•  The bank Workgroups would create Accept-Test cases based on the documented setup of the core-banking COTS delivered by the solution providers.

•  Payment would take place after successful Accept-Testing.

•  A number of Workpackages were reserved for internal delivery to ensure the availability of development, test, and implementation infrastructure for the solution providers in the bank.

•  No Workpackage activity was allowed outside the bank premises because Workflows and solution setup were confidential bank property. In this way, we wanted to ensure the proactive cooperation between internal Workgroups and solution provider setup teams, which would not be possible unless all resources worked together in the War Room.

• The bank was committed to set up the development, implementation, training, and test environments needed (“no excuse for failure” was ensured).

The program setup with bank Workgroups, solution provider Work-packages, and Workflows were established according to our Coffee Bean method that you will meet in Chapter 5 under strategic initiative implementation. One of the strengths of this method is that it enforces agile cooperation across development and implementation teams, which is needed if one wants to succeed with solution implementation of high quality.

The example here of Coffee Bean method use is quite typical when the primary task is the implementation of a COTS system:

•  The Workpackages represent development work that documents the technical setup of the COTS application and closes out with the full support and operation documentation for IT solution governance.

•  The Workgroup Workflows represent implementation work that will close out with user guides for the business usage of the COTS application after completed Accept-Testing.

•  The cooperation between bank Workgroups and solution provider Workpackage producing teams represents the project management and quality management activities that produce test setup, initial user training, test cases, and Accept-Testing, which ensure delivery of fully accepted results in a feasible IT infrastructure environment.

The Coffee Bean method process requirements were implicitly applied to the contracting terms that all solution providers and internal Workgroups were demanded to sign off. These contracting terms were included with the tendering material.

These preconditions limited the time needed for evaluation of the proposals to:

•  A study of the CVs for each resource to be involved in order to evaluate their competences and experience. We also had a very fruitful dialogue with these resources before they were accepted.

•  All involved resources had to be known at all times during the Workpackage execution as they personally had to sign a confidentiality agreement to get the key-batch to enter the bank premises.

• The number of consultants to work on each Workpackage in order to evaluate if the proposal was realistic in light of the number of Workflows and reports to be developed.

•  A list of reference banks with core-banking COTS implementation.

•  The willingness of the solution provider to use the documentation standard established by the bank for solution documentation, test documentation, and training documentation.

•  The willingness of the solution provider to adapt to the method used by the bank.

In this way, we could spend more time to establish win-win contract terms that would satisfy the bank’s legal department and at the same time motivate the potential solution providers to bid instead of spending time on condition elements that we would not be willing to negotiate anyway.

Our biggest risk was that we would get too few or no proposals at all. We had mitigated this situation in the solicitation process, but we had not shown all tendering elements during solicitation. However, we did get proposals from all parties, but not to our full satisfaction.

4.5.1    The Workpackage Workflow Documentation

In parallel with the Strategy Governance Team development of a new contract for solution providers (sub-contractors), our Workgroups worked hard to produce Workpackage documentation using a document standard with this content requirement:

Name of Workgroup

Content showing Workflows covered

Workgroup scope (general introduction)

Participants’ experience

Participants’ key figures (employed since, jobs performed)

IT systems used

General comments

For each Workflow:

The required quality of the products (= the purpose, the client/user) Essential business processes/procedures

Origin of data (internal/external organization, function, IT system) Treatment of data (manipulation, quality assurance, and control)

Data delivered to (internal/external organization, function, IT system)

Suggested improvements to product (e.g., to products such as SHARES, INTERNAL DEALS, BONDS), process, and organization

This document standard was adapted from our Business Analysis (Information Requirements Study) standard to this simplified form.

We wanted to have one complete Workpackage from one Workgroup ready for the tendering process so that the potential bidders could see what the bank was committed to deliver as requirements specification.

After reviewing the Workpackage documentation at the bank, the bidders could add their specific conditions and reservations concerning their quality expectations and need for access to further knowledge and decision making during their core-banking COTS setup activity.

No Workpackage documentation was allowed to leave the bank, but I can show an example (extract) from the “Security Transaction” Workgroup Workflows that gives you an idea about the quality without revealing any secrets or confidential information:

SECURITIES TRANSACTIONS Workgroup Workflows

Workgroup members:

NV (Back office) (Workgroup manager) HS (Trade Desk)

EF (Back office)

KO (Fund Management)

PJ (Front office)

SS (Finance)

LJ (Cash)

Abbreviations used

This Workgroup defines End-To-End Securities transactions accruing from:

•  Shares

•  Internal Deals

•  Bonds

•  External Funds

•  Investment Funds

•  Pools

•  Investment Management Funds

•  Short Selling

The Workgroup also handles requirements concerning:

•  Securities Static Data and Classification

•  Reconciliation

•  Prices

•  Mortgages

•  Holiday Calendar

•  Portfolio Management Department Documents

•  Investment Department Documents

•  Insurance Client Documents

GENERAL COMMENTS

General portfolio information is delivered to PM by CBS.

Transactions, positions, prices, securities static data are transferred from GC to CBS.

PM accesses CIS data (Portfolio names) via data warehouse.

CBS delivers brokers to PM which OMS accesses via a data service.

TD/FO establishes the broker agreements. BO sets the brokers up in CBS upon instruction from TD/FO.

Price catalogue for broker fees is present in PMS. TD is responsible for creation and updates of the broker fee tables. This is valid only for shares and bonds. No broker fee structure is available for external funds.

Price catalogue for clients is present in PMS. Standard dealing fees. AM is responsible for updates according to client agreements. This is valid only for shares, bonds, and internal Funds and Pools. No structure for External Funds.

PMS communicates with GCS.

Client Deals are automatically booked in GCS from PMS.

All clients have their depot number registered in GCS. BO is updating the depots in GCS (direct access).

The client’s depot numbers are linked CBS.

After EOD in CB, we receive files with holdings, and transactions (plus other non-transaction related files) and CBS will be updated.

CBS checks for missing cash accounts (or if following the booking of the transaction, the account has been closed in CBS).

Bookings are created and will hit customer accounts, nostro accounts, and profit, and loss-accounts.

Broker SSI are present in GCS.

Settlement details like safe custody a/c, cash a/c, swift code, are all updated in GCS

If for different reasons (FX to be added to the deal, new SSI …) we cannot use the GCS, the deal can be booked manually.

All broker deals have a shadow booking on a banks depot for security transactions.

The two bank sides of the customer and broker deals are matching each other out.

Following our booking of the broker deal in GCS it will catch the transaction and settle the deal.

Transaction will hit our accounts in GCS and we are going to be debited/credited cash on value date.

We have cash accounts for security transactions in every currency with GCS. We match nostros (client deal against broker deal) the day after value date.

SHARES Workflow (Executed by AM through the Trading Desk)

A client initiates by himself or by his/her AM to buy or sell a share. The order can be received by phone call, meeting, or fax. FO receives the order, executes the trade through the TD and books the deal.

BO processes the deal and the client gets a confirmation by mail.

The required quality of the products (= the purpose, the client/user)

FO executes the order based on client’s requirement and makes sure that commission is charged according to client’s agreement. TD makes sure to execute the correct order. BO controls that the transaction has actually taken place and checks correctness of charges.

A 4-eye principle is maintained on all transactions before they are executed.

In case of errors, BO informs FO.

Essential Business Processes/Procedures

Suggested improvements to product (SHARES, INTERNAL DEALS, BONDS), process, and organization

The Client should have the possibility to place Internet orders, which should be routed via OMS to the broker.

To facilitate STP the Broker should be placed with our custodian or we should have direct link to the Stock Exchange.

All kinds of orders, whether it is executed through TD or direct with the broker, should be registered in OMS with full log.

Automatic matching of client deals and broker deals in OMS with creation of outstanding list on screen/print. (This functionality could also be in place in COTS).

The possibility to have more broker/client relations than the usual one client deal against one broker deal:

•  Broker deal with many client deals

•  Many broker deals with one client deal

•  Many broker deals with many client deals

The very complete Workflow documentation with a direct link to current application screens, Excel spreadsheets, Access elements, and documents in combination with the bank’s committed setup of applications and document copies in test mode convinced all potential solution providers about the feasibility of the solution implementation strategy.

The Workgroup Workpackage review and support persons in the Strategy Governance Team were accessible for further information as needed. The level of competence of these persons contributed to the motivation of potential solution providers, who could smell a good reference to come.

The other Strategy Governance Team members produced the contracting material and made themselves available for negotiation with and supplementary information to the solution providers once they started producing proposals.

The actual tendering material did not comprise any detailed Workflow documentation, but it listed and outline scoped the Workpackages on which the solution providers could bid.

After solicitation, we had three potential solution providers that claimed that they could set up and implement the COTS solutions that we needed. All of them were represented in the local marketplace and could demonstrate competence and experience. We would see from their proposals if they also had the capacity to deliver the tendering requirements.

Although the core-banking COTS vendor claimed their system could handle Asset Management (Funds) and Reconciliation using SWIFT and FIX, all references in the marketplace had confirmed that this was far from true.

Our own investigations of the COTS software quality confirmed this, so we knew that we had to find other solutions to these important Workpackages, although management had already bought the Asset Management module.

The bank already used COTS software for Reconciliation via SWIFT, but this software had never been integrated with the new core-banking COTS. On this background, the Reconciliation Workpackage was included for tendering by external solution providers.

We also distributed the tendering material to a highly recommended solution provider that could do all the reporting in the solution. This solution provider also happened to have a Reconciliation COTS package integrated with the core-banking COTS.

Finally, we included the vendor of the already present reconciliation COTS vendor because the bank had a very good experience with this vendor. On the other hand, the experience also showed delayed and quite expensive solution delivery; a situation that the bank saw as an opportunity to change for the better based on the new solution implementation Framework agreement with an appropriate SLA in the COTS vendor contract terms.

The tendering material was later used again to acquire a new COTS package for Financial Control because the delivery of this internal Workpackage failed.

4.6    THE TENDER MATERIAL

The legal department of the bank proved to be a very valuable sparring partner while we produced the detailed tendering material and the future contract for solution providers. The legal department knew the bank standard contract terms so that we could avoid the most obvious blunders in our specific contract formulation; however, they found a real pleasure in the invention of a completely new contract to comply with the core-banking COTS implementation program and the “no excuse for failure” win-win principle.

The tender material contained all the bank-required contractual conditions in such a way that the solution providers could simply choose the Workpackages they could and would like to implement, offer a fixed price and time frame (duration), and sign the contract on their side. The contract material comprised:

•  Workpackages for contracting to be referenced by the framework contract

•  General contractual terms

•  Confidentiality agreement to be signed by all involved resources and resource management in the solution provider organization

•  Proposed Workpackage sheet to be filled in with fixed price and time frame and signature from solution provider authorized management

•  The bank IT Director would sign off the Framework agreement with the Workpackages assigned to the solution provider

It was stated in the contract conditions that the bank wanted to have more than one qualified solution provider. In this way, the overall management responsibility was with the bank program manager and all other solution providers would have to cooperate proactively in order to ensure that everybody could deliver feasible solution components.

We expected that destructive conflicts would be impossible because no one could win without the contribution from the others, and because everybody was contractually committed to succeed if they wanted to be paid. The only exception was the core-banking COTS vendor, but this key-stakeholder faced a very strong implementation team with high visibility in the market.

In this way, all key-stakeholders were motivated to succeed.

4.6.1    The Workpackages for Contracting

The Workpackages for contracting were presented in a document, which also described the way to deliver the Workpackage in cooperation with other solution providers, the COTS vendor, and the internal employees of the bank.

As we knew that the COTS vendor would guarantee only the functionality that was documented in the COTS vendor’s usage and release documentation, we mitigated the risk of conflicts between the COTS vendor and the solution providers by accepting that the solution providers worked only with COTS vendor approved and guaranteed COTS functionality. This was quite natural because the bank management had already signed off the delivery of this functionality from the COTS vendor.

We knew that the bank had bought only a subset of available functionality from the COTS vendor, but nobody knew what additional functionality had to be bought in order to implement the core-banking solution, except from the future solution providers. The solution providers discovered the missing COTS elements and it cost the bank almost the same price as the original purchase price to acquire the missing functionality, but this came as no surprise to the Strategy Governance Team.

The bank IT Department and the former Project Management had never tested the delivered COTS completely for compliance with the very complex documented functionality and database content integrity delivered by the COTS vendor. This was not practically possible, and it was too late to build a good sampling-based test model.

In order to utilize the COTS vendor guarantees the best possible way, we gave the solution providers authority to raise problem and error reports against the bought COTS components in the bank. It was then the responsibility of the bank program change management board to follow through the error correction with the COTS vendor. Whenever possible it was the responsibility of the solution provider to find workaround solutions if there was a risk of serious delays based on waiting for a COTS vendor solution.

Let us look at the Workpackages for contracting document that was delivered as a separate document for tendering and which shows how the risk situation was mitigated.

4.6.2    The Framework Agreement

The Framework Agreement covers the usual legal contractual terms that do not change from one party to another.

There are no special conditions included in this contract part and nobody had any problem signing this.

This agreement is included as Appendix C.

4.6.3    The Framework Agreement Consultative Service Agreement

This attachment to the Framework Agreement was a Consultative Service Agreement that was developed especially in relation to the problem and risk situation of the bank.

There is one Consultative Service Agreement for each Workpackage that has been agreed to be delivered by the solution provider with corresponding deadlines and payment conditions.

This agreement is included as Appendix D.

4.6.4    The Framework Agreement Statement of Confidentiality

This attachment is a standard confidentiality agreement that protects the bank’s proprietary right to all developed and implemented solution elements, and their underlying requirements specifications and other bank proprietary documents to be used by involved external solution provider resources.

The COTS vendors add their own confidentiality agreement concerned with their proprietary software. The bank had only a usage right to this software.

4.6.5  Escrow Clause

If the COTS vendor goes broke, is taken over by another legal entity that you have no trust in, or delivers such bad quality that it threatens your solution delivery, you want as an emergency action to be able to get access to and use the source code of the COTS software.

The contractual terms that appoint a third party (an escrow agent) to keep the COTS software source code available for your organization at no further cost under such conditions is called an escrow clause.

The escrow clause will probably not be included with the standard COTS vendor agreement unless you ask for it. The COTS vendor will pay the escrow agent and might ask you to pay for this service.

Although you will probably never use the COTS software source code, it is nice to know that you have access to do this—just in case. Therefore, I recommend that you always get this clause included in the COTS software vendor agreement, which is not part of your Framework agreement, but which normally exists for all COTS software that you have the right to use.

4.7    CHOICE OF SOLUTION PROVIDERS

We distributed the tendering material consisting of:

•  Workpackages for tendering document

•  Framework Agreement with attachments:

•  Consultative Service Agreement

•  Statement of Confidentiality

We obtained:

•  Three proposals for core-banking COTS setup and implementation

•  One proposal for reporting

•  One proposal for reconciliation

None of the solution providers wanted to bid for the Asset Management Workpackage, which was what we had expected.

The Asset Management Workpackage was never attributed to external parties. It took several years to replace the internally developed functionality that in fact only very limited uses the core-banking COTS data.

4.7.1    Core-Banking COTS Setup Proposals

All three core-banking COTS setup solution providers offered the setup of all modules except for the Asset Management module.

All of them had the capacity to deliver within 9 months, although only one solution provider could prove that they had done that before.

All solution providers would involve at least 10 named resources, and strangely enough, the most expensive solution providers had a smaller number of CVs attached to their proposals than the less expensive one.

When we investigated their proposal for the Client Reporting Work-package and the Control and Risk Management Workpackage, we could understand by the proposed prices and conditions that the solution providers to set up the core-banking COTS had no reporting tool well integrated with the COTS software. They all agreed to this conclusion.

We could not run the risk that the bank’s already weak requirements specification of these Workpackages based on low user motivation would cause heavy delays and present a foundation for future expensive changes.

It was therefore with some excitement that we opened the proposal from the reporting solution provider—and what a relief! This COTS-based reporting proposal showed by all means the solution provider’s expertise in reporting from the core-banking COTS system. As this COTS system did not offer a reporting facility other than their standard API, the reporting solution provider had based their report generator on this API in such a way that future changes to this API could be contained without demanding changes to the bank reports in most cases. Furthermore, this solution provider could show examples of all the required report types listed in the bank Workpackages.

We could again breathe and return to the proposed Workpackages from the three other core-banking COTS-based solution providers.

All Workpackages, as well as the Reconciliation Workpackage, had been proposed.

Two solution providers were more than two times the price of the third one. This would normally mean that the third one had misunderstood something, but not in this case.

The two expensive solution providers simply listed a set of CVs and had included the Workpackage cost and time proposals per Workpackage as we had requested, but they did not agree to work the way that was outlined in the Workpackages for tendering document.

They claimed to have a better methodology and documentation standard and that there was no way that they would agree to work under the bank program manager.

Both of them offered program management as part of their proposal, which we had not asked for.

On top of this, they claimed a right to adapt and approve the Workflow documentation that had already been approved by the bank. This point was not acceptable because it was clearly stated that the bank placed the responsibility to do workarounds or ask for COTS changes on the solution provider, not on the bank Workgroups.

If the COTS application could not perform a Workflow, the situation had to be evaluated in a much broader spectrum than simply changing the Workflow.

The third and less expensive solution provider was willing to let the bank provide program management with a change management board and accepted all method terms from the Workpackages for tendering document.

Based on their experience with the COTS Reconciliation facility they could offer a solution here, but they recommended using the COTS API and an external solution provider with easily adaptable Reconciliation functionality based on a separate reconciliation COTS system.

In this way, we got ideal partners to provide a complete solution that could fully replace the old core-banking facility.

The currently used COTS for Reconciliation was already loosely connected to the old core-banking solution and the vendor of this package was willing to deliver the Reconciliation Workpackage. We were happy about this opportunity, but unfortunately enough:

•  The offer was too cheap to be realistic.

•  The listed resources were already known by the bank and were not acceptable.

•  The proposal was based on a new technologically attractive release that was not ready yet.

•  The integration with the core-banking COTS demanded this new release.

In the situation we were in, we had no real choice. We signed up for the reconciliation COTS with a vendor who was also the only possible solution provider given that the COTS software was still under development.

An important reason for accepting this risk was that the reconciliation COTS system vendor was committed to deliver the new release to another bank six months before our delivery deadline.

Although we obtained much better delivery conditions than we had before, the choice of this COTS vendor as solution provider to Reconciliation gave the bank a lot of work to do internally in support of this vendor.

With some delay, the bank got a state-of-the-art reconciliation solution that both parties could be proud of and that quite a few other banks now profit from.

All other Workpackages were signed off to the less expensive, but very flexible, solution provider who proved to be an excellent partner.

The major problems were with the internal Workpackage delivery because the IT Department did not think that it had to sign off the internal Workpackages, but that is another story.

4.8    LESSONS LEARNED

I have seen quite a few enterprises dealing with resource procurement just as if they were doing recruitment of employees. This is acceptable in situations where it is difficult to find qualified people as employees or where you need to replace an employee for a shorter period. However, it is not a good idea if you need resources to produce a specific solution to a complicated task, such as the setup and implementation of a COTS-based information system.

A COTS system is not your information system solution.

In order to succeed with procurement, you need to manage the risks involved with this process.

Most, if not all, problems with procurement occur because of bad procurement team building and risk management.

If the procurement team does not act based on a good requirement specification, there is no way it can evaluate the quality of what it has acquired.

If a project comprises many sub-projects and broad organizational involvement, you must establish such a project as a program with a Strategy Governance Team and a competent Change Management Board. Here the solution providers participated on the Change Control Board, which avoided all conflict.

If you are faced with a monopolistic vendor and you have a weak SLA seen from your point of view, ensure access to competent knowledge on your side before you negotiate any further conditions with this vendor. If not, you risk losing your case even in court.

Trust your partners only if this trust is based on a good contractual foundation (SLA). This is the best way to avoid litigation and complete program failure.

Internally delivered Workpackages are agreed to in writing with the internal “solution provider” just like the external ones.

Internal solution provider personnel prove their competence based on pertinent CV data just like the external ones.

Demand weekly tracking of progress from both internal and external Workgroups based on reliable Work Breakdown Structures (WBS) and estimations of time to complete (cost tracking is not an issue if delivery is on a fixed price).

Use a project management COTS system in support of WBS registration, planning, and tracking.

Any program and project is risk to be governed by risk management (PQA) in order to ensure efficient risk response.

Risk originates from solution, process, and organization elements; and risk response encompasses management of the quality of all of these elements.

Do not be afraid of doing what no one has done before if this is the only way you can respond to your risk situation.

Things are never so urgent that you do not have time to do what has to be done, right.

Make sure that all victories are victories for all involved parties.

Get the key-stakeholders activated even though they claim that they have no time to offer. Risk management and Finance management suddenly had all the time required when they were delayed, but it was too late to avoid total solution delay.

Close out with Champagne, also to celebrate important milestones.