Managing Software Vendors – 6 Practices for Project Success

Introduction:

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

Advantages and Disadvantages of using Vendors

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.

Advantages:

• You can obtain skills or technology that are not readily available in your organization.
• Regular employees can be offered greater job security during tougher financial times by letting go of vendors before downsizing an organization.
• You can start activities sooner than your resources would otherwise allow.
• The project’s overall schedules can be potentially shortened.
• You can associate the project with a well-known and respected vendor.
• You can perform activities at a potentially lower cost.

Disadvantages:

• Some key skills can disappear from the project and from follow-on projects when the vendor contract completes.
• The employees whom the vendor chooses to assign to your project may not perform as expected and needed.
• In mid-project the vendor may decide to swap employees working your contract with employees working other contracts, leaving your project at a higher risk.
• Vendors often have a higher attrition rate than many companies; therefore, a negative impact might be felt if key employees of the vendor leave the company.
• You may have less direct control of the actions of the vendor’s employees than you may feel comfortable with.
• The vendor can gain knowledge of sensitive inside information about your project and company that you would prefer is exposed to regular employees only.

6 Processes for Project Success

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.

Process 1 - Defining the Vendors Work

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.

Process 2 – Trackable Plan

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:

• Activities to be performed with deliverable descriptions
• Person responsible for each activity
• Schedule logic (predecessor relationships)
• Planned start and end dates of each activity
• Contract deliverables and the dates of those deliveries
• Assumptions behind the schedule plan
• Contract funding plan

Consider these additional requirements:

• Reviewing project documents such product specifications, publication content plans, quality plans, test plans, and test scripts
• Performing and participating in design inspections
• Reviewing drafts of the product’s publications
• Reviewing changes being proposed to controlled documents such as the product specifications
• Responding to problems discovered by others during testing

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.

Process 3 – Measure Performance

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:

• Track the progress and problems of the vendor weekly
• If the vendor resides at the client site, include a vendor representative in your weekly project tracking team meetings (unless sensitive information is being discussed)
• If the vendor is remote, then use teleconference (or equivalent) tracking meetings weekly and face-to-face meetings monthly
• Make tracking meetings with the vendor formal; that is, distribute progress and problem status at each meeting so there is a written record of actual-to-planned progress
• Shift sites where tracking meetings occur, that is, have them sometimes at the vendor’s site and sometimes at the client’s site
• If the vendor is always included in the tracking meeting, then sometimes have a private meeting with only the vendor to cultivate a close working relationship
• Discuss contract funding with the vendor if the contract requires tracking of the expenditure of funds.  This discussion may be for a limited audience

Principle 8 – The client should insist on obtaining information from a vendor that it feels is required to manage the project successfully.

Process 4 – Who’s in Charge

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.

Process 5 – Quality System

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:

• Documentation that fully describes the quality system, including the processes and supporting procedures
• A quality plan that shows the adaptation of the quality system to this specific contract work
• The identification and availability of resources (staffing, equipment, fixtures) and skills required to achieve the desired quality
• Description of specific quality control, inspection, and testing techniques to be used
• Measurement techniques to be used to ensure that the quality system is being followed and the desired quality is being achieved along each phase of the software development process.  This should include the identification and preparation of “quality records” that prove the quality system is being followed appropriately
• Problem reporting is integrated into this system

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.

Process 6 – Performance Incentives

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.

Conclusion

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.