This paper addresses the most common issues facing companies that make use of vendors and sub-contractors in a software development environment. It attempts to address the myth that you can exercise little control over vendors and sub-contractors. This myth is fueled by the poor planning and follow through of companies purchasing these services.
In order to effectively manage third party software development suppliers, a number of principles and processes need to be applied by the customer company to increase the probability of project success. This paper discusses the processes and underlying principles to assist client companies embarking on third party software development projects
Companies that outsource software development projects to third party suppliers are transferring risk of running the projects using solely in-house resources to highly skilled third-party vendors. This strategy brings with it its own set of challenges, advantages and disadvantages, as well as its own unique set of risks.
Hiring a software development company can be a difficult and challenging process – more difficult than it needs to be. The goal of hiring a (custom) software development company is to find the right team, for the right type of project, at the right time. The following 6 Practice areas broken into 12 Principles will help you manage vendor intensive software projects.
The Statement of Work (SOW), as part of the RFP, must fully describe the work to be performed by the vendor. The better the work is defined, the better the vendor can submit a well thought out estimate. If incomplete work descriptions are contained in the RFP, then problems with the vendors bid can be expected for months to come as we attempt to refine the work over and over.
Principle 1 – There is a direct relationship between the completeness of the Request for Proposal (RFP), and the completeness of the bid proposals received.
The point to be made here is that is that this is the client’s project. The client must be proactive in driving a contract with a vendor that satisfies the business needs. If the client doesn’t drive assertively for the right contract and demonstrate the discipline and leadership to ensure the contract is executed properly, no one will.
Principle 2 – When formulating a contract with a vendor, you get what you negotiate – nothing more, but often less.
This paper addresses the most common issues facing companies that make use of vendors and sub-contractors in a software development environment. It attempts to address the myth that you can exercise little control over vendors and sub-contractors.
Prior to the RFP being released to vendors, it should be reviewed and approved by key project groups; that is, by any areas that can be impacted by the SOW and the terms and conditions of the RFP.
Principle 3 – Avoid blind-siding the organization – get your organizations agreement before releasing the RFP to vendors.
Quality specifications should be clearly spelled out in the RFP. I’m not talking the specific subject of software quality systems – I’m referring to the overall conduct of the project, its deliverables and operations in general. Vendors should be asked to identify any trade-offs they feel must be made between cost, schedule and quality. Be aware, however, that trading quality for schedules and cost almost never pays off. Nevertheless, creative ideas may be offered to reduce schedule time and cost by knowledgeable vendors.
Principle 4 – When it comes to quality work from a vendor, you usually get what you ask for. Ask in the RFP.
While this may seem like common sense – you would be surprised how vague some RFPs can be, and how insufficient the resulting contracts can be. The prospective client should be of the mind that if it is not delineated in the RFP, it’s not getting done. And if it’s worth delineating and getting done, its worth tracking.
Principle 5 – Do not assume the vendor plans to work on an activity – spell it out in the contract. At a minimum, the vendor must provide a schedule plan that clearly lists these items:
Consider these additional requirements:
Principle 6 – End of project and end of effort may be different. The vendor needs to clearly see the whole picture of what is being committed to so as to provide an accurate bid.
Many projects tend to track the groups that are farther removed, either physically or organizationally, much less rigorously than they track their own project members who are nearby. This means that vendors typically receive much less attention and visibility than regular project members.
Principle 7 – Vendors should be tracked just as routinely and intensely as other groups participating in a project as follows:
Principle 8 – The client should insist on obtaining information from a vendor that it feels is required to manage the project successfully.
As the purchaser of the vendor’s services, the client needs to be in charge. Many project leaders have a hard time engaging this notion.
The result is the creation of a vendor that is too empowered. Don’t accept this behavior – even once. The vendor may have legitimate problems, but the agreement was made up front as to the terms and conditions of the contract. Hold the vendor to the contract. The key is to make sure the verbiage in the contract is satisfactory.
Principle 9 – The client is in charge of the project – end of story.
When there is a disagreement between the purchaser and a vendor, the contract should also describe the process and chain of command on both sides that must be followed to resolve problems and instantiate project changes.
Principle 10 – Expect and plan for the likelihood that escalations will occur. Establish an effective, efficient contract arbitration and project change control process that includes management from client and vendor.
Before a vendor is selected, be certain that the vendor operates under a formal quality system. In this context, a quality system is a defined, documented process and supporting procedures that will describe clearly how the vendor operates while performing contract work. If the quality system is unclear or not defined, a bright red “stop” flag should appear.
Principle 11 – The vendor must have an acceptable quality system so that the quality result of the effort is largely predictable. Items to look for in a vendor’s quality system include:
If the vendor has been registered or certified for following a recognized standard, such as ISO 9001 (model for quality assurance in design/development, production, installation, and servicing), then the above items should be readily available.
Incentives can be monetary, non-monetary, positive, or negative. They can be based on cost, on schedule, or on quality of performance. Regardless of the final composition and structure of the incentives, the goal is to encourage and motivate the best-quality performance.
These can be a percentage of the base contract or specific dollar amounts. Recommendation: Don’t be stingy with the use of bonuses to improve schedule and quality requirements, or with penalties for missed schedules and poor quality. Incentives are a time-tested, proven tool.
Principle 12 – All contracts should include incentives and penalties.
A formal vendor management program is as necessary to a business’s long-term success as is a formal human resource (HR) program. After all, businesses invest their financial resources with both employees and vendors, so it’s only logical that both need to be managed effectively if those investments are going to produce the desired results.