Outsourcing: Being the System Integrator

Understanding The Reason

The customer is hiring the system integrator because they are lacking the resources to build the product or they desire to offload the risk. Resources can be people, knowledge, time, or other such item required to build the product. They are replacing this with a financial investment. The reasons must be understood. For instance, offloading risk will increase the price. On the other hand, if they are lacking knowledge or the people to complete the work, the system integrator should understand how the product is going to be maintained after it is released. Understanding these constraints dictates each party's work and may point to gaps in the responsibilities.

Completion Criteria

The contact must clearly define completion criteria for the project. The system integrator must insure:

1. The deliverables are inside their capabilities. Bidding a contract beyond their skill-set ultimately leads to failure. The integrator must be honest to themselves and others about their capabilities.
2. The deliverables for the product are sensible. It is the customer's responsibility for defining the deliverables; however, the system integrator has to validate their clarity. (Deliverable definition will be discussed in the future article "Hiring a System Integrator.")

Failing to have this basic starting point is bound to lead to frustration and failure.

Throughout the project, the system integrator must keep the project within scope. Unfortunately, there are many times when a customer wants to continue to haggle over a deliverable's state. This can drag the project into what seems like an interminable state. The customer has the leverage of withholding payment. Luckily, failing to pay for the product also means it cannot be used in production. If it is production worthy, it must be acceptable. The system integrator should always make sure the contract contains a clause that if the product is used in production there is defacto acceptance. All payments are due and any additional work must be conducted under a change order.

Force Majure

The system integrator should make certain the contract contains a force majure clause. A force majure clause is put in place to account for catastrophic actions that are outside the realm of the project. These include acts of God, such as earthquakes, flood, and fire, but should also include bankruptcies, foreclosures, and other situations outside the project's control. This clause allows for project termination without holding either party responsible. A fair force majure turns all work performed on future payment milestones into time and materials.

The Customer Relationship

Too often, the customer knows what they want, not what they need. The system integrator is their partner in creating the solution that meets the customer's needs. Transitioning the customer toward their needs requires that the system integrator gain the trust of the customer. If trust cannot be built between these two parties, the endeavor should not be undertaken.

Critical in this is understanding everyone's roles and responsibilities. Ultimately, a failed delivery affects the customer more than anyone else. They will be left with the unsatisfied business initiative, the excess cost, and the missed opportunity. The pain for the system integrator will be financial; however, in most cases progress payments will lessen the blow. In rare cases, when a system integrator over promises their capabilities, the only retribution is a lawsuit. No one wins in litigation.

Work Breakdown Structure

To help with this, the statement of work (SOW) should have a high-level work breakdown schedule (WBS). This provides two functions. First, it provides a picture of the how the work will proceed and second, it shows who has the responsibilities for certain tasks. This goes a long way in setting expectations.

Setting Expectations

As a system integrator, it is paramount that customer expectations continually be monitored and maintained. This starts prior to the contract. In many sales cycles, claims of what can be done get confused with what is actually contracted. The contract, and its accompanying statement of work, must provide clear expectations on what will be delivered and each party's responsibilities. As mentioned above, a work breakdown structure is the best method to address this. This is often considered an early deliverable of the project. PMI's PMBOK^® includes this as part of the Scope Planning and uses requirements as an input. However, waiting to that stage of the project is too late. Other definition material that should be included in the contract or SOW that are often delivered in the project-planning phase are the roles and responsibilities matrix and a communications plan. Including high-level versions of these, sets the tenor for how the relationship will work.

Working With Vendors

Vendors supply products that are integrated into the project deliverable. Contractually, managing the vendor could be the responsibility of the integrator or the customer. Both have their advantages and disadvantages. The party that has the responsibility has greater risk, however not all the risk. For instance, if the customer has the responsibly for the vendor, the system integrator must work through the vendor to escalate vendor problems. Lack of customer action can reflect on the system integrator and cause significant strain on the relationship. The contract and SOW should clearly define this responsibilities and escalation path.

Note: This is the first in a series of articles on outsourcing that will appear over the summer of 2010. If you are interested in an in-depth study of the subject, Todd will be teaching a class at various universities and colleges. For more information check out the course description and find a college or university near you.