P. D. Rudd, Associates

Management & Information Systems Consulting

Technology Sourcing Process White Paper

February 27, 2002

“Where are we on this project?”

“Why haven’t we selected a supplier yet?”

“Are we going to be faced with further delays?”

Sound all too familiar? Long gone are the days when it was easy to go with the “safe” technology purchase, only because there just were not that many options. You may even remember hearing, “nobody ever got fired for buying IBM.” With so many technology options available today, and more on the horizon, it’s no wonder that it is so difficult, and all too time consuming, to find a solution that meets your needs, at a price you can live with, and easy to implement as promised.

With companies cutting costs and “right sizing,” everyone has so much on their plate, that all too often, technology decisions are based on a presentation, a recommendation from a friend, or even the best sales pitch that comes through the door. Unfortunately with technology, one size does not fit all. Decisions made in this manner tend to come back to haunt us for far longer than the time it takes to follow a proven process.

What is technology sourcing?

Technology Sourcing is the process or activities related to procuring a technology service provider. This could include anything from purchasing computer hardware, to complete outsourcing services. And although the effort may vary depending on the solution to be sourced, the process must remain consistent.

Prior to moving into the sourcing stage of a project, you must identify a “need to source”. This includes identifying the business requirements for new technology along with justifying the economics and determining that the solution is not readily available within the organization.

The four basic steps that comprise the sourcing stage of a project are:

-    Requirements definition

-    RFP process

-    Due diligence

-    Contract negotiation

1. Requirements Definition

Typically, if the sourcing stage of the project does not follow a formal process, requirements are ill defined, resulting in a less rigorous selection process. In this case, your organization will probably spend more time than is necessary on these activities, and the end result will be that the customer’s real needs are not met, resulting in wasted funds and resources.

“Analysts estimate that American businesses end up spending
billions for software that doesn’t do what it’s supposed to do.”
(Oct 15, 2001 CIO Magazine)

When a formal process is followed, you can identify gaps between your requirements and existing supplier functionality prior to purchasing an application, which greatly reduces the problems associated with, and disappointment of, implementing a solution that does not meet the organizations requirements. We have all heard that we will never find a software solution that meets 100 percent of the requirements, and I personally have found that to be quite true. It’s the old 80/20 rule: if you find a solution that handles 80 percent of your requirements, you are doing good. Just make sure that the remaining 20 percent are NOT requirements that affect the success of the project.

“The company with the most information, and uses it, wins!”

I don’t know how many times I have heard a marketer in the petroleum / convenience store industry say that they don’t want merchandise vendors controlling their business and believe that the way to take control is through information. This is no different with Technology Providers. The more information you arm yourself with in the form of documented requirements, the better the decision you will make.

When identifying requirements, it is important to define real, tangible requirements. Make this a list of functions that the system must perform, rather than making an open cry for help! To accomplish this, you must interview the individuals within your organization who will ultimately use and support the system. Asking corporate managers to define requirements for a system that field employees will use will result in more of a wish list.

However, it is okay to use this as a forum to build your wish list, but you must distinguish between those items that are critical to the success of the project versus the “nice to haves.” To accomplish this, assign a priority to each requirement, ranking them high, medium, or low. Use these priorities later in the process to narrow down solutions.

Why go through this exercise? Won’t it waste time? Will you find a system that does it all? As previously stated–—no. But you also won’t be surprised or disappointed late in the process either. If you know up front what the system does and doesn’t do, you will not waste time chasing down what you expected it to do. This is good not only for you, but also the supplier – they utilize resources, justifying what they said versus what you heard. Documenting requirements will help insure the success of the entire project. Everyone involved has the same expectation level, therefore buying into the project and supporting the supplier choice. This spreads ownership beyond the selection team to include the real system users as well as key stakeholders.

2. Request for proposal (RFP)—the process within a process.

The RFP becomes the foundation for clear, accurate communications between the marketer and supplier, insuring that everyone involved makes the best decision. It specifies the minimum functionality that is acceptable, along with project constraints such as schedules and budget. Typically, you should communicate the RFP to as many potential suppliers as is feasible.

Supplier feasibility is usually limited by:

-    Desired functionality

-    Prior experience

-    Resource constraints

-    Awareness of available options

Sending out RFPs and deciphering the responses has the potential for taking the most time (longest duration), because you need to give the suppliers adequate time to respond. You don’t want them just throwing together a proposal in order to meet a deadline. If you want a head start, ask them to reply with an “Intent-to-Bid” form within a week after receiving the RFP. This will give you time to distribute additional RFPs if you will be receiving fewer responses than expected, and prepare you for the effort ahead.

During this phase you will need to establish a method for answering questions raised by the suppliers, and for keeping everything on even ground by supplying those questions and answers to all participants. This activity cannot be underestimated. Depending on the number of RFPs distributed and the completeness of the RFP, this could be a very demanding activity.

It may be necessary to conduct a “bidders conference” where you invite all of the potential suppliers together in a room, and you can explain the process and requirements to all of them. This way they all get to hear the same message and meet the key stakeholders. This exercise also sets the stage for negotiations, since it clearly shows that there is competition.

Providing you were clear in developing the RFP and structured the method of response to the requirements by requiring a predefined response such as, “Yes – No – Yes with modifications,” the responses can be converted into a matrix, which will identify the option that best fits the requirements. This is where the priorities, established in defining the requirements, come in to play. It may also require a round of “gap-filling” between you and the suppliers to clarify responses.

When reviewing the proposals, don’t rely strictly on the supplier’s ability to meet your requirements. Also consider items such as the size and stability of the organization, technology deployed, existing customer base, and, of course, price.

Don’t forget, in this phase you should update the economic model to determine the feasibility of continuing on with the project. If the numbers are not going to work out, it’s best to find out before you sign a contract.

3. Due diligence

Once you narrow the selection to one, two, or even three suppliers that appear to meet your requirements, it’s time for due diligence. Don’t be afraid to ask for references, request hands-on demos, and attend user group meetings. If the supplier will not provide references due to “confidentially,” warning bells should go off. It is also okay to pilot more than one solution if you have the resources to support the activity.

Prior to contacting references, you may want to assemble a questionnaire or script so you and your team are gathering the same information from each reference. Consider using a rating method in place of open-ended questions to get you a more honest, accurate response and make comparison easier.

During the demonstration of the solution, make sure you are looking at the production version of the system and not a mock-up, or demo version. Ask to have your data loaded. You may want to visit the supplier’s site for the demo, which will also give you a first-hand look at their facilities.

Once again, don’t underestimate the effort required in tracking down references and validating the RFP response, and don’t forget to update the economics. Each step is a learning experience.

4. Contract negotiation

It’s finally time to make a deal. When negotiating the contract, remember price is not everything. Making a great deal that the supplier cannot deliver is no help. You need to make sure you have realistic, well-defined milestones and contingency plans in place, should you need them.

With technology companies either going out of business, or being acquired, make sure you are protected. Consider placing clauses in the contract that provide you with options in the event of acquisition or merger.

Contract negotiations can easily become a quagmire of legal mumbo-jumbo. Be cautious not to fall into the trap of accepting a supplier agreement, which will tend to be one sided. Make sure you have the criteria used to measure the supplier and system performance in writing, as well as the remedies should they not meet the criteria. Remember, “If it’s not in the documents, it’s not in the deal!”

While this is not the last time you will be updating the economics, it is the opportunity to update it with final pricing and lock in an implementation budget. You will use this to track against actual implementation costs as the project continues.

You may want to start with a letter of intent to get the ball rolling while you hammer out the contract details. This way you are not holding up the project and rushing through the contract.

In summary

The sourcing process is not one that you can shortcut and still achieve success. In today’s economy, everyone is running lean organizations to optimize resources, leaving everyone busy handling day-to-day operations. This process requires dedicated resources to achieve the value used to justify the project.

Don’t underestimate the effort; be sure to take internal resources into account in the economics. While they are already being paid for, if you take them away from their daily duties, you need to back fill. If you don’t, did you really need them to begin with? If you don’t have the resource to dedicate to this, or need additional expertise and experience, get help! You are committing considerable resources in time and money to the project— be sure to spend it wisely

It doesn’t end here. It is important to review your agreements on a regular basis to identify compliance, changes in business requirements, and changes in use. The business may have changed to a level that justifies re-negotiating your agreement to achieve a better pricing structure or service level. A prime example is credit card use in gas stations. As the price of fuel increased in the summer of 2001, credit card use increased along with it, as did the total purchase amount. If your agreement with your transaction processor did not contain tiered pricing, you may have been spending much more than you needed to process these transactions. This may present an excellent opportunity to re-negotiate.

A structured process will eliminate many of the headaches that come with the discovery of gaps in a system that you have already purchased and scheduled to implement. It also gives you the ability to provide stakeholders with progress reports each step of the way. It will position you to avoid hearing: