Software procurement is the practice of hiring subcontracting programming firms which specialize in writing code to order. The reason it works is that there are two parts to creating software: the planning and design and the actual coding. The most important part of creating software is the planning, and it is here where the creativity is needed. The actual coding of many portions of software is somewhat repetitive and mundane. Also, with the advent of object oriented programming (OOP) many smaller parts of programs can be done separately and assembled later, since this kind of programming need not be sequential.
In addition to the change in programming practices, programs became much larger with each increase in computing power. Larger programs could do more, and compact code was no longer required. More businesses began using software, and very quickly it became quite rare to see a business without some proprietary software for its every day functioning, like HR functions, accounting and documentation. Now these gigantic programs may require thousands of lines of code for the major functions and thousands more for all the little things that make the overall program work. Companies are more often contracting with specialized coding firms for this kind of work.
In more developed areas, companies find it difficult to retain coders for repetitive and mundane coding, and the pay structure for talented programmers makes the cost of in house support code development prohibitive by comparison to outsourcing. In effect, development has become two tiered, with one kind of firm doing the design architecture and major creations and other firms doing the necessary , but rather unimaginative small function coding. So it is cheaper and more efficient to contract one of the specialty firms to fulfill the nuts and bolts of the major programs. Some of these large programs take many months to complete and cost hundreds of thousands of dollars. The cost saved by sub-contracting the less critical and less difficult programming can be substantial. In addition, the need for this kind of programming is not constant, and so keeping full time programmers for this kind of work is not cost effective.
So it is clear why firms which develop large projects want to outsource, but why is outsourcing so available? This is because the start up costs are small, and the rewards relatively large for the firms which do this. In places like India, the Philippines and China, labor costs are extremely low, yet the money that these coders can make is much higher than they could earn on other jobs, so it is easy to find talented and willing workers to subcontract. In addition, there are no barriers, because it is essentially an intangible product, so trade barriers and bureaucratic interference is ineffectual.
The world once divided along industrial lines, with the industrial revolution bringing wealth and prosperity to the industrialized countries. Then these now wealthier countries suffered inflation, and wages rose as a result, making manufacturing less and less profitable. Companies began to “outsource” their manufacturing to countries where labor costs were lower. When software development took off nearly twenty years ago, companies in developed countries sprung up to meet this need. As the programs got larger and wages rose again, ordinary coding became too expensive, so companies began “outsourcing” this also, and now it is a thriving industry, and most major software development involves some outsourcing of the small function coding.
Overview of current outsourcing practices
In a recent survey companies in Hong Kong were asked about their outsourcing practices in order to assess the current state of outsourcing in Hong Kong. The following sections describe the respondents and their answers.
Definition of Respondents
Most firms who responded produce ERP or CRM packages, as these are the most popular and profitable programs for development. This kind of program often requires reams of coding, much of which is quite simple and tedious. The majority of these firms outsourced to Mainland China. There are a number of reasons they cited from the proximity and ease of payment to the language being less of a barrier than elsewhere. Hong Kong firms often have someone who can speak Mandarin, and even if they don’t, most of the time the written language carries the same meaning in both languages, so they can still communicate. India was the usual second choice for the efficiency, and the shared English language. According to business reports, India has become the foremost choice of North American companies for software outsourcing, because other outsourcing countries, including mainland China, simply cannot communicate adequately in English. Singapore was the third choice for outsourcing for the majority of these firms, about 25% of the value of their work was outsourced based upon the entire value of their projects. This amounts to a substantial portion, and it begs the question what the cost would be for these projects if the work was done in house instead. Compared with in-house development a 20% cost savings was realized, on the entire project. So doing the math, we can estimate that software development and the ultimate price to the end user would rise by 30%. Most of the firms stated lower costs as the main reason for outsourcing, citing lower labor costs and lower employment costs for benefits and other extras. Other reasons cited included lack of enough full time personnel with the right skill sets and that outsourcing the small parts then allowed developers to concentrate their focus upon the core development and not worry if the coders were keeping up with the chores. Among all these form, however, only 1.8 vendors were used. It seems that respondents were loathing trying new vendors if current vendors were at least satisfactory.
Respondent Hong Kong firms were cautious in their selection of vendors, valuing a long term relationship over other criteria. It has been hard for new providers to make inroads into this market for that reason. Even if there had been problems in the past they were not likely to change providers if work was eventually satisfactory. The past problems were seen as something that could be prevented from recurring due to advance knowledge. It is supposed that it is easier to deal with vendors you know than to worry about creating a relationship with a new unknown vendor.
Some companies responded that they usually depended upon themselves, because it is difficult to trust outside sources. The management style which prevails in Hong Kong is, perhaps, responsible, as local managers are often not used to delegating, and so have great difficulty with outsourcing concept. The Hong Kong corporate environment is so centered on the strong work ethic and collected responsibility being vested in one or two people that people are simply used to doing everything themselves or closely overseeing what work is delegated. Another reason that companies don’t do more outsourcing is they have a need for proving their overall robustness. There is an attitude that they needs to show that they have enough workers that they can afford to hire more workers if needed. There is an attitude that they must keep all work in house, because it proves their workers are better.
Overall satisfaction with outsourcing ranked average
It was found that overall satisfaction with outsourcing was only ranked as average, so questions were asked aimed at uncovering the reasons for the rather low satisfaction rate in order to improve situation. Cost satisfaction ranked the highest among things the companies rated about their outsourcing experiences. Mainland coders work cheaply, which is where most respondents contracted for outsourcing, so they were actually quite satisfied with the prices.
IPR ranked the lowest
The issues concerning intellectual property rights were rank as the area in which there is the lowest satisfaction among the respondents. Intellectual property rights are not truly respected in China yet, and the scope of this issue is not truly understood. Even when it is included in the contract, the cultural attitudes on the mainland are so focused upon profit above all else that ethics are simply different. When a company writes a support program on contract, they consider it quite all right to resell that program to another company in the future. The exact points concerning who owns what have to be spelled out in great detail in order to make it clear that every line of code that was contracted and for which the company paid became the property of the contracting software development company. Even then respondents has difficulty monitoring.
Advantages of Outsourcing to the Responding Companies
Low cost was seen as the main advantage for outsourcing. Cost Considerations included the cost of wages and the attending benefits. They also considered that in house development would require more machines and more work space for the extra coders. They would incur higher utility costs and the extra management required would also raise costs. Outsourcing also allowed them to focus on core development rather than split their attention and resources to oversee routine coding. The core development is the framework, and its development is essentially what they sell, requiring creative management and attention to the overall project. Outsourcing frees up the time of managers and lead programmers needed for the major tasks.
Action: Self Evaluation
When respondents evaluated their successes and failures they spoke mostly about how better planning, better definitions and better tracking would improve their outcomes. They mentioned that better definitions in needs analyses and cost analysis would improve the suitability of the final deliverable and also eliminate some time consuming explanation and discussion during the process. When deliverables did not suit the need, it could often be tracked to misunderstandings, possibly partly based on needs analyses with too little detail, even in the original RFP. They stated that some time could, at least, have been saved with better definition and more detail. Problems could more easily have been solved if the needs were more completely stated. More complete cost analysis might also have made the project budgeting process flow more smoothly. Better planning and more defined deadlines could also have improved the timing of deliverables.
Project managers sometimes keep too much in their heads, and should define all aspects of a project, including outsourcing as either part of the overall project or a sub-project of its own, in as much detail as possible, so that everyone on both sides of the outsourcing channel would know what was expected. Some mentioned that they might use a flow chart in the future to insure that all steps were included and to plot the timing properly.
Need for Well Defined Deliverables
Another area where the respondents cited a need for improvement was in defining the deliverable in more detail. Certain kinds of unsuitable deliverables could be avoided if the expectations were completely defined. The things they said should be defined were not just functional, but smaller things like: coding language, object needs, the hierarchical structure of parent objects under which deliverables will inherit, inheritance needs of deliverables. These are all examples of exact programming needs in order to insure that the deliverables will integrate properly and smoothly into the overall project. It also makes them easier to test. Even sequencing sometimes needs to be defined so that code runs when it should.
Another area where managers said caused problems was documentation need. If deliverables are not well and completely documented, they are difficult to use, cannot be as easily tested and required more man hours in order to document the overall function for which they were created. Documenting after the fact requires more time and is not always as accurate as ongoing program development documentation. In the days of smaller applications which were all done in one location by a static group of programmers, this was ok, but with pieces of the project being developed in many different locations by many different people, the documentation became a key issue as the program was assembled and as its final documentation was developed for the end user.
In the area of bonuses and incentives many problems were found. Managers didn’t really understand the concept of diminishing returns. Offering too much incentive for early delivery can be counterproductive as contractors race to beat the deadline. This can lead to sloppy or incomplete work and incomplete testing. They found it difficult to know just what sorts of bonuses and incentives would work best, and also to find the level at which such mechanisms become counter-productive. It was mentioned that, perhaps incremental bonuses and other types of non-monetary incentives, such as preference in future projects or early warning of RFPs, might work better than straight completion bonuses, and that not all should be tied to time, but that quality bonuses might be useful.
Factors Leading To Failure
The following were cited as factors leading to the failure of outsourcing projects by the various respondents.
Infringement of IPR
This was cited most often as a reason for assessing their outsourcing as a failure. It was not just the distinct possibility that intellectual property right would be infringed upon, possibly giving competitors and advantage, but also the high costs of monitoring IPR. One can never be quite certain that all deliverables and development materials have been wiped from the contractors’ computers. If they are not, then the temptation is always there to save time on future projects by using part or all of a previous project’s materials. The profit in this is so high that unless steps are taken to insure against infringement, one can assume it will happen. Long term relationships become more valuable when viewed in this light.
High Costs of Project Monitoring
Respondents said that the high costs of monitoring an outsourced project were implicated in certain types of failures. If not enough monitoring was done because of its high cost, this sometimes led to poor quality or missed deadlines. It was assumed that closer monitoring would have avoided these problems or, as least, allowed an earlier response, resulting in better overall performance on the project. Most of this high cost involves the extra manpower to follow up and communicate often with the contractor. It also includes writing extra testing procedures to be used during the development process in order to monitor quality on a continuous basis, and avoid nasty surprises at the end. Another cost involved documenting the testing of deliverables both during and at the final phase of an outsourcing project. The documentation requires more man hours, and so was sometimes a cause for skipping this. However, lacking the documentation of the testing sometimes resulted in incomplete testing and problems in interacting with the contractors in case of problems later.
High set-up costs
Outsourcing often appeared less attractive because of the high cost of setting it up. Of course, this cost was also a factor leading to some unsatisfactory results, due to poor planning and incomplete preparation for outsourcing. Just the man hours required for defining the project scope and the deliverables is considerable. So it can happen that too much stress is placed upon speedy starts and steps are missed. The cost of man hours in planning has such a time-deferred benefit that it is tempting to try to compress this process. However, that time should probably be spent even if work is to be done in-house. That time spent in planning will result in time saves in fixing.
Another area which has rather high cost is contract administration. This involves having someone highly skilled to draft the original and then handle subsequent negotiations. Legal counsel is not cheap, so it is tempting to use it only for contract drafting. However, negotiation and mediation by someone less skilled and knowledgeable can result in very unsatisfactory handling of contracts and trouble-shooting. Contracts that are incomplete or not detailed enough are unenforceable. Contracts that do not include consequences for various actions leave too much to be negotiated after the fact. Using highly skilled professionals at the outset can save time and much trouble later. Most respondents said they would take more time on this and expend more money in future to insure that there were very clearly defined objectives, time limits, quality definitions, defined expectations and mechanisms of recourse for problems.
Costs of settling accounts low
The cots of settling accounts were seen as the lowest part of the cost and also the least problematic. Once the contracting entity decided that the it had received acceptable work the agreed upon sum was simply paid. The only real cost of settling account is in the book-keeping. Even the cost of incremental payments on timed delivery dates was still the lowest of all the costs of outsourcing. The payment mechanism might be a lump-sum at completion, progressive payment or advance payment. Each of these has its own inherent problems, but they are still fairly straightforward and cause few problems.
In procurement, planning is everything. While planning may be very important in most things, when you have someone else do any portion of the work for which your company is ultimately responsible, planning is everything. You are essentially giving up control of part of your livelihood, and this must be carefully planned, tracked and documented. The planning is rather like trying to arrive at an unfamiliar destination by using a map. A good accurate map is essential, and the more detail, the better. You might even mark things on your map before you depart, such as mileposts, service areas, place to obtain food and lodging and landmarks. You should do the same thing with your project planning, especially where it concerns outsourcing any part of your software production. Without a road map to travel, you could wind up lost. Without the roadmap for outsourcing you could wind up the loser.
Tracking your project is obviously important, and tracking any outsourced portion is doubly so. If it is not on your site under your control, you must keep abreast of the development process and progress. Imagine again your trip, and think about times when gas stations are open, motel rooms are available and restaurants are open. If you leave at the wrong time and don’t track your progress, you could find yourself inconvenienced and without services or with poor services. When handling any software project, the outsourced portion must be closely tracked so that the various parts that you need will be ready when you need them. It also impresses the vendor when you show interest in their progress.
Not the least of your needs is good documentation. You must document everything from needs to negotiations, contracts, agreements, changes, stakeholders and responsible parties, criteria, deadlines, inspection and testing, troubleshooting, communications and final deliver and acceptance. If something is needed, it should be documented. If something is done it should be documented. Every step from planning through execution and final outcomes and assessments must be documented. This is to protect all stakeholders and insure that everyone is in agreement, and also it provides your road map for future projects.
Outsourcing is just not a simple matter of advertising and selecting a vendor, making an agreement and hoping that it fills your company’s needs. It is a very complex process that must be planned carefully. Yes, you are going to outsource the less critical portions, and yes it will probably be simpler work than your programmers will be doing, but the time you spend planning will save time and money in the execution, and more importantly, it may save your project.
Project planning has become such a recognized and important phase of business that it has its own certification. It is a complex and multifaceted function that demands the focus of the entire team at the beginning and the constant vigilance of the person charged with monitoring the project’s progress. It begins with the initiation of discussion between the company and the client’s project architect. Those two people (or small groups) will identify the needs of the client and define the project. In the beginning, the client is the company to which the software developer will supply the large software package (usually HRM or CRM for ERP in Hong Kong). Then the architect will form a team to fill the needs of the client. It is critical that all the needs of the ultimate end user be identified at this point in order for the outsourcing planning to be included from the inception of the project.
Identify outsourcing needs during the project planning stage if possible
The architect of the overall project should take into account the needs for outsourcing when discussing the project with the end client. It is not necessary to inform the client if or that any part of the project will be outsourced. It is enough that the architect simply knows which portions might be eligible for outsourcing. For example, controls that mate the overall ERP program to the CRM package and make it available to the entire enterprise might be a specialty that could easily and very successfully be outsourced. The architect must be thinking about this when setting tentative timetables with the client.
From the inception of any project, the various stakeholders must be identified. Their particular needs must be taken into account in project planning and the responsibilities of each stakeholder should be identified and agreed upon (preferably documented) from the start. These usually include:
- Client: the company for which this software package is being developed. Their responsibilities usually include defining their needs thoroughly. staying in touch with the developer company to keep them apprised of any changes or additions and administering and ultimately paying the contract. This client may be a real outside client or an internal department of a large organization.
- The first individually identifiable stakeholders will be architects and project managers from both the external company or department and the project manager for the developer. IN some companies the architect and the project manager will be two different people, or they may be the same person in a smaller company. It is the architect’s job to co-ordinate all the various elements of a project from start to finish. This person sees that all needs are defined, all stakeholders are identified and a team is formed. He or she will also be involved in the design process which precedes development.
- The team may include an actual project manager who will manage the actual development process, or the architect may also fill this function. In either case, the architects and project managers are major stakeholders and their needs must be well defined before a team is formed. The project manager will from the development team and be responsible for coordinating the functions and working of all the various teams and departments involved.
- In any project, the lead programmers or department managers will be minor stakeholders. They will have only the responsibility for their own portion of the development project. However, it is prudent to include them in the overall design process so that they know how their portions must fit into the overall structure, and also in order to have their possibly valuable input. The additional positive emotional impact of including them is a bonus.
- The programmers who must integrate outsourced works into the final deliverable are also minor stakeholders, and should be included in the initial design stage. They need to know how the overall program is expected to perform and what all its functions will be in order to know best how and when to integrate the outsourced portions into the large deliverable. These programmers may also be the managers of the outsourcing, responsible for managing the outsourced sub-projects, tracking and reporting progress to the project manager and finally integrating the outsourced portions into the main deliverable.
- Though they are often overlooked, documentation specialists are also stakeholders, as they are responsible for documenting everything concerning any project. They must document the initial agreements among stakeholders and their individual responsibilities, the actual development process and coding and the overall and specific functioning of the deliverable. Projects without proper documentation can become less than useless, since it may become easier to create something new than to decipher the old one and modify it without knowing how it was done.
- Finally, technical support must be included, as it will be their responsibility to support the client. If it is an internal project, these technical support people may be external to the department, but they must be included as stakeholders from the beginning phase. They can also be valuable contributors in that they know the other software to which this project may be attached, and all its quirks. They should be consulted concerning possible problems that could be avoided with proper program planning. They will know of past and present problems with ERP software.
Once the various stakeholders are identified, the needs and responsibilities of each should be defined, documented and agreed upon. In this way, each one will know exactly what is expected and when, and be much more able to function well. The architect and the program manager can easily stay abreast of developments by staying in close communication with these stakeholders.
Make or Buy
Once the stakeholders are identified and their need and responsibilities documented, and the overall project design has begun the possibility of outsourcing must be seriously considered. It should not wait until the project is actually underway, because the planning of the development phase of the project must include any portion that may be outsourced in order to do that with the highest probability of total satisfaction and success. The first thing that must be considered after the rough design of functions has been done is the question of whether the company will make or buy the smaller functioning portions, and, if so, from whom. The main issues to consider when planning for outsourcing are quality, feasibility and cost.
Quality is always the first concern, and most companies rightfully think that quality can be assured as long as they are in control of all phases of development. It is also understandable that any company is proud of its team, but realistically, there is some programming that is only rarely used, and some that is just plain tedious. There are many reasons why a manager may not want to use company programmers for certain portions of the program. The major reason may have to do with company retention of talented programmers. If you give them too much boring work, job satisfaction goes down. IN addition, the company programmers may be highly trained and highly paid, so it isn’t cost effective to use them for mundane repetitive work. The final reason may be that certain skills rarely used may not be equal to the task of specialty programming.
By outsourcing you can take advantage of a huge pool of expert programmers who are not on the company payroll, and do not require company benefits. The cost of keeping full time programmers for these types of programming can be prohibitive and is seldom cost effective. The key question to answer is: are they needed all the time? At times it may work to hire local contractors for extra work, but that can become quite expensive and local contractors not always readily available.
Outsourcing can be timed parallel to core development and, coupled with the fixed price, can help to keep the project on time and under budget. The budget planning for the entire project will be less problematic and the end price can be more easily set.
Planning the Management of the Procurement Process
Depending upon the size and business processes or company culture of your company, you may or may not have a full time manager for handling the procurement process. Even very large companies often prefer to allow each architect the freedom to either appoint a procurement manager, allow his project manager to appoint one or to handle it himself. Any of these will work nicely as long as the person so charged has sufficient time and resources. Somebody must be named to take this responsibility or there is too much room for miscommunication, tracking mistakes and the ultimate problems or failure that will impact the entire project.
Once it is decided how procurement will be handled and the person responsible knows where everything fits and knows the exact needs for time and deliverables, he can focus on controlling the whole scope of the outsourcing. He can research and assess possible sources, and can seek whatever approval and budgeting as may be necessary. He can plan testing procedures and see that testing scripts are created and ready. If needed, he can set up and manage the testing team. They should be prepared to test the deliverables at regular intervals during the development process. In all, the job of overseeing outsourcing is key to its success.
Just as the enterprise for which the major development is being done solicited the services of suppliers, you must be prepared to solicit the cooperation of specialized outsourcing companies. The method should be planned to blend well with the company’s normal mode of operations. If the company normally selects using RFPs followed by RFBs, then these must be prepared with care to be used to streamline the process of outsourcing. Internal documentation should be begun at this stage in order to avoid overlooking anything, and also to help work out who will do what and when.
You have already identified the needs of the overall project. At that point you picked out various portions of the overall projects that would be eligible for outsourcing. Next you must identify and document the needs of these individual portions. Identify each stake holder’s needs for each specific portion to be outsourced. You should be specific for each stakeholder, and specific for each portion or code subset that will be outsourced. You cannot use overall project needs definition here, but must define the exact needs for each stake holder for each outsourced portion. All of this should be documented and signed on by the stake holders.
Consider Budgeting Needs
One of the aforementioned stake holders is the finance person at whatever level controls the money for the project. It is imperative that this person understands both the needs and the costs very thoroughly. It is better to involve them from the outset and make them a part of the planning that to have to waste time explaining the expenditures. They can be measurably helpful in making the project come in under budget if they understand the development process. Uninformed finance people may balk at the cost of outsourcing if they do not understand the overall savings such measures create. Paying some other firm to program portions of the project may look like waste or even laziness unless they understand how the creative development team works, and the momentum needed to push through creative solutions. If they see that process at work in the early planning and brainstorming sessions, they will want to foster the synergy required to put together innovative development projects that will set your company apart from competitors.
Therefore, after the brainstorming and overall planning is complete, a project budget should be created and segmented as much as possible, with outsourcing funds set aside. The budget needs to be tracked through every level of the development process. At each stage, the financial stake holder should know the current status of every part of the project, be able to foresee possible extra costs and have solutions ready for any unforeseen expenses. The costs of development can usually be divided into several segments:
- planning costs, which include research costs, marketing costs incurred before the deal was sealed, and the salaries of all stake holders within the company;
- testing costs, which are ongoing throughout the project and should be budgeted separately to insure that sufficient testing is done, but that it is following a planned pattern;
- actual in house development costs, including salaries of programmers, cost of space and equipment, resources and documentation;
- outsourcing costs;
- and, finally, administration costs, including contract administration and project tracking.
In smaller firms these may not be separated out in this great detail, but larger corporations often prefer this kind of penny counting and accountability, because they are very aware of the total cost of miniscule waste over a large operation and over time.
Consider Quality Issues
Perhaps the most important part of the planning stage is the issue of quality, especially where it concerns outsourcing. For internal work, these issues can be addressed any time that quality is in question. However, for outsourced work, quality MUST be planned in. The exact quality expected must be discussed by the internal stake holders and a set of criteria agreed upon. Then tracking and testing must be planned. It must be in the contract what will be tracked, the method of tracking and what and what will be tested and when. If the suppliers know exactly what quality you will accept and how and when it will be tested, they are much less likely to fudge on their own testing, thereby saving considerable time and trouble that would be wasted in fixing problems. They will know that they must adhere to whatever is in the contract, so exact specifications and testing times and methods must be in the contract.
Identifying Potential Sources
The next step in outsourcing is the identification of potential sources for this service. If all projects are well documented, that provides a wealth of information about companies which have fulfilled this service in the past. It should be well documented what they did for which project and what kind of results were obtained. Documentation should include a copy of the original RFP and RFB plus the various proposals and bids that had been considered along with reasons for rejection or acceptance. Your documentation specialist or the program manager should have tracked the progress and copies of the reports should be available. Records should include the time frame required for completion, problems and resolutions, final results and a copy of the sign-off sheet where all stake holders sighed off the outsourcing portion of the project after their needs were met. Use these records to look for successful collaborations and also to qualify or disqualify proposals and bids, according to past experience.
In addition, you will likely find that other companies will openly solicit your attention, and you can include them on your corporate issue list for RFPs. Finally, an RFP can be posted in several; places to attract potential suppliers, including trade journals, on line specialty sites, your company website and major newspapers in various locations where such service organizations are found. There are generally special places for these in both magazines and newspapers.
Requests for Proposals
This subject rather overlaps both planning and action. However, in the planning stage the actual contents of the RFP need to be carefully considered. The actual issuing of the RFP is fairly straightforward. The handling of the RFP process is also something that needs to be planned. By definition, and RFP is an invitation to present a proposal for consideration. The more defined and detailed the RFP is, the more likely it is that you will receive a good number of well done proposals from which to choose. Generally this process is designed for two purposes: to let possible suppliers know what you need and when, and to streamline the process of selection. It is important, therefore, to be certain the right person writes them.
If you have a technical writer, then that person is usually the obvious choice. Otherwise it falls to the program or project manager or the manager assigned with the outsourcing, or even the person responsible for the documentation. I any case, one person is responsible for writing up the RFP according to all the things discussed by the stake holders in the planning sessions. The RFP should then be distributed to those same stake holders for signing off.
It was decided in the planning stage which portions of the project would be outsourced and why. The actual details of the needs should then have been discussed. All of this should be in the RFP in great detail. IN addition, it is recommended that you include your expectation is the greatest detail possible for both the proposal and the deliverable (s). If potential suppliers know what you want to know about them, it will make your decision much easier. If, at this early stage, a company cannot comply with the details of the RFP, then you cannot logically expect them to do any better for the actual project. So including the details of what you expect to see in a proposal will make it simple to sort through potential suppliers. You should have decided as a group in the planning sessions exactly what other criteria to use to sort through all the proposals.
Requests for Bids
Once the proposals have been sorted, most companies have a form letter for rejection and a prepared RFB. The difference between a proposal and a bid is the level of detail, including dates, prices, exact specifications of deliverables, problem solving methods, communications conduits and responsible people. The bids, if accepted, will form the basis of the contract. In the planning stages it must be decided if bids will be open or closed, and negotiable or not. This usually depends mostly on time factors. Closed and non-negotiable are much faster.
All through the previous sections the subject of documentation has been a recurring theme. Documentation must be planned if it is to be assured that it will be useful and factually correct and complete. For outsourcing, you must first decide what kind of documentation the deliverable will need and who is to provide it. Sometimes a company will send its own documentation specialist to the supplier to insure the quality of the documentation. The usability of any deliverables may depend upon very good documentation. In a perfect world, the supplier would have an excellent documentation specialist, but the truth is that it is often not economically feasible for the suppliers to keep such a wizard, who can manage to document many quite different projects at once. It is even sometimes impossible, considering the cost of outsourcing and the linguistic shortcomings of many areas where outsourcing is done.
One thing that must be documented in house is the plan for outsourcing. Everything we have already discussed about planning must be documented and much of it should be signed on and signed off upon completion by the various stake holders. Included in the documentation of planning is the level of documentation required for outsourced materials. This should be decided and recorded in detail. This plan for documentation of planning should be much the same for every project.
Documenting agreements must also be planned. Is it enough to have a copy of the actual contract, or what other documentation might be desirable? A flow chart of the overall program into which the outsourced code will be integrated is also quite useful. Anything that is done for a project is subject to documentation, from the needs assessment of the first planning stages to the final agreed upon needs, the modification and troubleshooting procedures, the deadlines and the list of stake holders and their areas of responsibility.
Documenting Progress Tracking
Even if the actual documentation of the deliverables is assigned to the outsourcing supplier, the tracking of progress and periodic QA testing must be documented. It should be decided early who will be responsible for that. Then methods for documentation should be clearly laid out, including the types of documents, the program used to do it and the final storage media and location. Finally all financial transactions and receipts must be recorded in the program documentation, separate from the finance department, for use in future outsourcing.
Evaluation criteria and methods should be planned and standardized across all projects in the broad sense. The criteria for each outsourced project should be the same in order to assure quality and accountability. It is best if this is agreed upon in the early planning meetings and signed by all stake holders. This will avoid any misunderstandings about who needed what and when at a later time. Even the procedure for modifying or accepting the criteria should be documented and signed.
Each stake holder should complete a needs assessment that when combined will completely define all deliverables. The needs assessment can be standardized on a form to facilitate communication and to streamline the process. It should be clearly stated in the needs assessment if the final acceptance criteria will be based on function, form or any combination of these with other aspects of the deliverable(s). Some things may change from project to project as certain aspects, according to the needs of the main program. These include:
- Object package
- Compactness of code
- Fitting of inheritance standards
Another factor that is always of prime importance in outsourcing is deadlines. These must be clearly defined, and the consequences or missing one should be clearly stated and standard. If these are always there, suppliers will get used to them. Deadlines should be part of company policy so that no supplier will feel either privileged or discriminated against.
Criteria for Short-Listing
Since short-listing is done at two stages, there should be a standard set for accomplishing it. The first will be to short-list proposal providers, and the second will be to sort among the bids tendered. It might be prudent to set up a point system on a chart and simply use this to winnow out the ones to be considered further. Some points to consider when creating this list are:
- Industrial knowledge: Does the vendor have any special industrial knowledge that will add to the value and reliability for the project?
- Expert programmers: does the vendor have a large pool of talent, expert programmers and specialists in esoteric code?
- Knowledge of end user industry: does the vendor have specialized knowledge of the end user industry. That could make them a valuable asset to your team. This would include, but not be limited to: electronics manufacturing or other real businesses who will be end users.
- Similar projects: Has the vendor proof of similar projects in the recent past. Do you respect the referents?
- Track record with industry: proven success can weigh heavily in a vendor’s favor, especially in light of recent successes. Recent successes may even overcome a problematic past if it can be shown that there has been significant change in problem areas.
- References: These can swing a borderline vote, but may be otherwise useless. It is extremely important that you also assess the value of the referents. If they are companies you know and respect, then they may be a valid consideration. It is even better if there is an actual person in the referent’s company with whom you have a relationship. However, competitors are not always motivated to share the truth.
- Sample work is probably a good indication of the supplier’s capability. At least it can be seen if they can produce the type of work you need, and you are seeing what they consider to be their best work. Keep this in mind as you assess the samples and be extremely critical.
- A company’s visibility may be an indication of their success, but it depends upon how that visibility was accomplished. A plethora of advertisements does not indicate anything more than that they have the resources, somehow, to pay for ads. Likewise, press releases should be seen with a critical eye, as publications are content hungry these days. If you judge the publication to be a respected source and know that they check their facts, then you can give more credence to press releases. What is seen in the regular media, whether complementary or not, is often more trustworthy than either ads or press releases, but you still have to consider the source. What is published in the trade press may have more information, but the caution about press releases holds especially true for this genre, as their scope is more narrow for content, meaning theyhave less from which to choose to fill their pages.
The decision concerning who will select short listed candidates should be made early in the planning stages. Will it be a person or a committee? What will be the procedures for a committee? Care must be taken to avoid slowing this process, as it is only preliminary, and not the final decision. If you have a documented list of criteria and a a procedure for selecting short listed proposals it will be much easier to get this done quickly.
The easiest way to make everyone happy is to create a weighting system for different kinds of deliverables. The needs of all stake holders should be included, among the different sort of things that can be outsourced. There is enough variance to differentiate each type of project. The weighting system should be based upon the overall needs of the program and not the whims of different stake holders. A repetitive visual basic script may not need more than simple documentation, while a new Java object may need quite a bit ore to be useful to the programmers. So the first might be weighted for speed of execution, ease of integration etc., while the second will lean more heavily on documentation and inheritance attributes.
Mostly, the evaluation criteria must adhere to the needs of the project. A screening system can be established to set the criteria for known types of outsourced projects and new types can be added as needed. Establishing criteria for advancing to each level of acceptance must also be done in the planning stages. This will include all the various steps of outsourcing from the evaluation of RFPs and RFBs to the evaluation of the final agreements and the deliverables.
These must be written in concert with all the stake holders and it should be decided as a policy what RFPs and RFBs will included. Much of the material is the same across all projects. The methods and criteria for the evaluation of providers should be another constants across all projects, even though each project will have different demands. Though Company A may not be able to meet the level set by the evaluation criteria for Visual Basic coding, this does not affect the criteria, but only the final outcome. Therefore the criteria can be standardized for the various projects, and include a section of exact skills evaluation.
Not only must you decide what criteria will be used, but also how to weight each area assessed. This will depend largely upon company policy and culture. In some companies, past experience is far more important than future potential or work samples. Other companies prefer to go by a case by case basis. The vendor’s reputation in the industry may be important to one set of executives and totally irrelevant to a certain point with others.
Perhaps the most important thing to assess among providers are the differences in quality. In addition to previous experience and industry reputation, the samples can be assessed and certifications checked. The value of certifications is questionable at best for some. In order to evaluate if any particular certification is valuable enough to weigh you must know what they test, how they test and what they certify. This sounds easy, but in practice, there are only three ways to judge certifications:
- Research by some person of firm in whom you have confidence
- Personal experience by a responsible member of your staff (preferable with all the different certifications, though this is rare
- Documented experience with a group of employees who cover the range of available certifications (This must be done by assigning the same variety of tasks to each in order for it to be valuable)
You can find out what each certification certifies by reading the extensive documentation for the product exam. research in the industry will also yield considerable information. It is easy to find out which are desirable and which are somewhat impugned. How they test may be of equal importance to what they test. Cicso tests with hands-on examination and simulations, making it the most desirable certification in the industry as it actually tests ability to perform tasks and not just memorized data. It is for your group, especially the lead programmers and program managers, to decide which certifications will be required.
Evaluation of Product
The terms and criteria for evaluation should be included in all documents when planning for outsourcing. There should be a standard for the selection of vendors in both process and criteria. There should even be a set of criteria defined for short-listing. Then in the final contract, all criteria for deliverables must be detailed and all stake holders should sign off on this document before it is tendered for agreement. That is, all stake holders should agree upon the contents of the contract, so that the needs of each are included within.
Key Concerns before Outsourcing
Quality is usually the primary concern before outsourcing. Someone must look at the overall project and select the portions that can be outsourced. A policy concerning the quality of deliverables should be established from the beginning, before even considering possible suppliers. Issues of quality are sometimes vague ideas in some manager’s or lead programmer’s head. This needs to be detailed on paper for each type of programming that has the potential to be outsourced.
It should be decided well in advance of any one project what criteria will be used to asses different types of work. Then, during the planning stage of the particular project, these criteria can be discussed and even modified if needed while selecting portions of the project for possible outsourcing. Planning ahead what standards will be used and how can these be satisfied is key to a smooth process for outsourcing over time and many projects. Procedures for quality assurance should be thoroughly discussed separate from any project and documented. Then in the planning stages of the project, these can be reviewed and modified to suit the current needs.
Control is key to successful outsourcing. Since we are the producers for the end user, it is our responsibility to check everything before delivery. How that will be done should take the form of a Standard Operating Procedure. Included in this should be a complete delineation for how to test specifics in order to keep errors from the customer (end user). How to test the outsourced deliverables for specific results needs to be set as the selection of what will be outsourced is done. However, the process for selecting specifics things to test and the method for testing for specific results can be included in the company Standard Operating Procedure for Outsourcing. In this way, it assures a kind of continuity across all projects and eliminates considerable duplication of effort on the part of the planners.
One very important consideration is how to handle the special needs of projects which may be outside usual needs and not within skill set of current personnel. If the outsourced work is not within the expertise of current personnel, how will it be tested for quality? It may be enough to test certain aspects and outcomes without any particular knowledge of the native code or function. However, it may sometimes be prudent to hire a local contractor for this special purpose, who will be responsible for both the QA testing and the documentation of that testing.
In general, the first reasons to seek to outsource parts of a project are usually a staff shortage, or the high cost of in house development for repetitive functions. So personnel skills have already been seriously assessed and either found wanting, or considered too expensive to be spent on this type of work.
Planning the administration of the project is almost as important as the administration itself, as well planned administration usually flows much more smoothly as everyone knows exactly what to do and when. It is first decided who the administrators will be, and what they will do is planned. Often the program manager for the outsourcing will do the administration work also. Progress tracking is a large part of the administrator’s job. However, many larger global companies have actually created this job title as the duties of the project manager grew in number and scope. The job status and pay scale falls between Contract Administrator and Program Manager with a pretty reasonable pay scale.
The handling of Procurement Contracts is often done by a special contract administrator. This can be one person who handles all contracts for the firm, a person named for this particular outsourcing project, one of the managers already discussed or even an outside law firm.
Contract administration that is well planned will leave no loopholes in the process. It will include handling of requests, changes and additions & omissions, and list completely who can make such requests and under what circumstances. This should cover every imagined possibility, and can be a template for company policy. Such things might be due to a change in client needs, basic project plan, vendor or client cancellation. All of these should be covered.
Handling Problems with Products
Quality assurance must be planned and provisions for dealing with quality problems should be well thought out. The issues of deadlines must be completely spelled out with conditions for change and consequences for delays spelled out completely. Timing issues should be made completely clear to the administrator who must track progress. The overall project should be segmented and the outsourced portion identified as to where in the overall timing of the project it fits. Then allowances should be made to cover possible delays.It is most important to answer the key questions about outsourcing timing: how will missed deadlines affect overall project, and can work continue in spite of delays with the outsourced portions? These will figure largely in the decisions for how to handle the problems.