|
Outsourcing a project to a supplier and IT contract management is fairly easy to understand. Companies write contracts and suppliers fulfill them. The complexity is found in the terms and conditions, service level agreements, supplier responsibilities and defined project deliverables. Quality management is just one of the deliverables that need to be defined before outsourcing a project to a supplier. The following recommendations will help keep quality management in mind before the company contracts with a supplier for services.
Recommendation No. 1: Ensure quality management is defined in the statement of work If the organization is contracting with a supplier to deliver an IT product or service, quality management requirements need to be defined in the statement of work rather than a contract assumption. During the sales cycle, everyone provides smiles and promises before the supplier is selected and the contract is signed. During project delivery, issues, misunderstood expectations and requirement changes will often occur. To resolve any disputes, both parties look to the contract to clarify the agreement. In order to manage the overall quality of solution, quality needs to be contract deliverable. An effective approach is to define the quality management plan, test cases, test scripts, defect logs and other quality management work products as supplier responsibilities. The statement of work should also define quality management responsibilities for both the supplier and the company. Providing a detailed statement of work limits misinterpretation and clarifies assumptions. During a recent system implementation, a software supplier expected the client to perform integration and user acceptance testing. The client expected the supplier to manage the integration and user acceptance test cycle. By defining the quality management deliverables up front and reviewing them with the supplier, quality management ambiguity was eliminated and the project team had clearer definition of quality roles and responsibilities.
Recommendation No. 2: Map the supplier’s SDLC phases and deliverables to the company’s SDLC expectations IT organizations deliver IT solutions using a system delivery lifecycle. Even if the project is contracted to an external supplier, the company’s SDLC may require specific SDLC deliverables--such as requirement specifications or test cases--regardless of the outsourcing decision. In a recent outsourcing contract, the supplier’s SDLC methodology was similar to the company’s internal delivery cycle, but the company expected the supplier to produce the quality management plan, test plans and requirement traceability documents. Unfortunately, these deliverables were not in the supplier’s methodology and multiple meetings were required to clarify the SDLC expectations and the supplier’s responsibility to meet them. If the supplier is delivering work products to satisfy the company’s SDLC, remember to gain buy-in from any process quality assurance group or face the wrath of the PQA police. Methodologies need to be flexible and process quality assurance needs to be adjusted to meet the methodology and sourcing decision.
Recommendation No. 3: Enforce requirements traceability throughout the test cycle Requirements traceability ensures the requirements identified at the beginning of the project are designed, developed and tested throughout the project. Requesting the supplier to provide a matrix aligning business requirements, supplier work products and test cases are an excellent approach to trace business requirements across the engagement. Without traceability, requirements are easily lost and the testing cycle suffers from ambiguity and assumption.
Recommendation No. 4: Pay the supplier upon deliverable acceptance Requiring payment upon acceptance reinforces quality management and places the burden on the supplier to produce quality deliverables. When the supplier delivers a module, report or specification, a set of acceptance criteria needs to be applied confirming the deliverable satisfies the requirement. Simply passing a milestone or project phase isn’t enough to initiate payment. The deliverables that contribute to the milestone or project phase need to be inspected and accepted. Structuring the contract to pay on acceptance rather than an hourly rate or time elapsed phases protects the company’s interests and further ensures quality.
Recommendation No. 5: Remember, a small contract price doesn’t equate to a small effort I recently intervened in a failing project where the supplier assumed the small dollar size of the contract meant small project effort. The product suffered from low product quality, with over 100 unresolved defects. The key business requirements were not properly identified and the project lacked any documented test cases or requirements traceability. The supplier underbid the work and thought the low-bid contract didn’t justify project or quality management. Reviewing the statement of work revealed over 200 screens needed modification and the statement of work lacked sufficient quality management deliverables. Quality, even on perceived small projects, needs to be incorporated into the project even if the project involves two screens or 200. Quality management starts with quality planning during the planning phase of the project lifecycle. Regardless of the IT sourcing decision, quality management needs to be included in the overall statement of work and managed through out the project lifecycle. This article was written by Andy Makar and originally published on Gantthead.com
|
