Advertisment

Constructing The Software Service Business

author-image
DQI Bureau
New Update

In the software services business, vendors provide software services such as developing or maintaining software to customers who want these services. Whenever a vendor is to develop some software for a customer, a clear understanding is needed between the two parties for transacting this business. 






In a business setup, usually all understandings between parties taking part in a transaction are formalized in a contract that forms the basis of the transaction and has legal implications.

Advertisment

Frequently the contract contains general terms and conditions, and the specific terms for a particular project for providing some software service might be specified in a proposal for

that project. Generally, a vendor proceeds with the project only when the proposal has been

accepted and the contract signed. If the customer and the vendor have good understanding and confidence in each other, the

actual work might commence, based on some oral, electronic, or other informal ‘go-ahead’ signal with the formal contract signed later.

Many issues have to be handled in a contract and a proposal, including legal concerns, commercial arrangements and intellectual property rights. These two documents form the starting point of a business transaction or relationship. Contracts and proposals are usually outside the scope of software engineering, although they do set the context in which a software project is executed. Although these do not directly implement any key process areas (KPAs)–except some aspects of the Requirements Management KPA–a clearly agreed on contract and proposal help immensely in building a good working relationship between the customer and the vendor. This, in turn, impacts project execution.

Customer and vendor interaction



One needs first to understand how an organization becomes a customer for a software vendor. The first step for the customer organization that wants some software services is to get in touch with the vendor. This contact is initiated either by the customer organization itself or by the sales staff of the vendor. The customer, through its own information network, finds out about various vendors and then contacts the most promising ones. Alternatively, the sales personnel of the vendor, through their information network, might establish contact with the customer.

Advertisment

After the initial contact is established, the customer usually requests information from the vendor about itself. This interaction is generally called request for information (RFI). The information sought might include the strength of the vendor’s organization, educational background of employees, skills set and experience level of employees, past projects done, current and past customers or references, computing infrastructure, or information about processes used for executing projects.

Based on the information, the customer might short-list some vendors and possibly visit them. These organizations are the vendors with which the customer is willing to do business. Until the short-listing is done, no business transaction or commitment for business has taken place. After the customer has short-listed some vendors, the interaction becomes more specific. Depending on the customer’s needs and the vendor organization, different models are used. The following briefly discusses some of the commonly used models at

Infosys.

If a single project is the goal, the customer typically sends a request for proposal (RFP), along with a sample contract illustrating the type of clauses to be included in the contract. The RFP specifies the scope of the project. The customer might send the RFP to multiple vendors.

Advertisment

In response to an RFP, the vendor prepares and sends a proposal. Here, there are multiple models. First is the fixed-price model, in which the vendor analyzes the RFP, roughly estimates the effort and schedule, and–based on the estimate–gives the price using some manpower rate for executing the project. This price is fixed in the sense that, unless the requirements change the customer will give only the agreed price to the vendor. If the effort estimates are lower than the actual effort, the vendor has to bear the cost of the extra effort, if the effort estimate is higher, which is rarer, the vendor effectively gets a higher profit margin.

The fixed-price model is used for making a proposal only if the requirements have a sufficient amount of detail and are precisely stated. This situation might be the case if the customer has already completed a requirements analysis. If the details are not

sufficient to make a reasonably accurate proposal, the project is viewed as consisting of two parts–the first one for doing

the detailed requirements analysis and the second one for developing the software. In the first part of the proposal, the time

and materials (T&M) model is used, in which the vendor agrees to provide one or more analysts at some agreed-on per person-month cost to the customer, without any hard estimate of how much effort it will take to do the analysis. That is, the customer agrees to pay the vendor for the first part of the project on the basis of actual effort spent by the analysts. This part ends with the analysts delivering to the customer the requirements specification document.

The proposal for the second part, which includes the detailed cost estimate is given after the first part is over. A general rate for manpower might be agreed on at the start. When the first part is over and detailed requirements are available, a fixed-price bid is given for the development part. The vendors for the first and second parts might be different.

Advertisment

Besides these two models, there is a third model which is doing the whole project on a T&M basis. In other words, the customer agrees to rates for payment and then pays based on the actual effort expended. This model is usually adopted when the customer is not very clear on the requirements or expects a continuous stream of projects, many of them small. In this context, it makes little sense to go through the RFP-proposal cycle, so a full T&M model is adopted. This model is also used for maintenance projects where a stream of requests–bug fixes or enhancement keep coming and have to be serviced. A variation is to agree on a rate for per-unit work, for example, the rate per line of code in a reengineering project. In this case, the actual payment by the customer is determined by the rate and the size of the work request.

A customer that is interested in a long-term relationship, getting many

projects done in the future, might enter into a general service agreement. This agreement, besides containing various contract clauses, specifies the rate for payment. In other words, it specifies what the customer will pay to the vendor for each person-month of effort put by the vendor on the customer’s projects. After this rate is agreed on, a work request is sent, usually informally, the purpose of which is similar to the RFP. Based on this work request, effort estimates are done and sent to the customer. After accepting the estimates, the client sends a work order or purchase order, essentially accepting the estimates and agreeing to pay for this work. The work then commences.

The various models are simplified event traces for the various approaches. In reality, depending on the situation, some activities might be done in parallel or some extra steps might be added. For example, it is common to conduct the contract preparation in parallel with the project work to avoid delaying the work. Similarly, the multiple-project approach shows work orders coming sequentially, although in reality many of them might come together and be serviced in parallel. 

Advertisment

The proposal



We have seen, the vendor might need to give a proposal to a potential customer. A proposal has two parts–technical and commercial, with the technical part basically describing issues relating to project execution. Its main sections follow.

TECHNICAL DESCRIPTION: This describes the requirements of the projects or refers to an RFP or requirements document. It also describes the methodology and tools that might be used and the vendor’s experience with the methodology, tools, problem domain, technology and so on.

ASSUMPTIONS: All assumptions made while making the technical proposal are enumerated here. These assumptions frequently form the basis of contention

between the customer and the vendor and hence it is better to specify them explicitly. It is possible to eliminate some

assumptions by resolving them and then placing the agreement in the relevant sections of the proposal.

Advertisment

PROPOSED SOLUTION: This specifies an approach for the solution. It can discuss an approach for planning, the strategy for carrying out the project, architecture, team structure and so on.

EFFORT ESTIMATE: An effort estimate is for the requirements that have been supplied. Any change in requirements that might come later does not form a part of this estimate.

PROJECT SCHEDULE: The overall schedule of the project and the schedule for milestones. 

Advertisment

CUSTOMER RESPONSIBILITY: It is well known that for the vendor to 



meet its schedule and other commitments, the customer has to play its role properly. All inputs to be given by the customer
are specified in this section, 



including inputs regarding data, manuals, access to personnel, hardware or software for development or installation, access to their sites, responsibilities for
the customer contact person, and so on.

PENALTY AND REWARD FOR TIMELY DELIVERY: If there are to be any penalties for slippage or rewards for meeting the criteria or deadlines, they are specified here.

RISK MANAGEMENT: Gives risks to the project–which of those are assignable to the customer, which to the vendor and how the vendor proposes to mitigate risks assignable to it.

REQUIREMENT CHANGES: This clause specifies that if any changes are requested by the customer, the vendor will determine the effect of the change and bill the customer for any extra effort that might be required. This important clause also affects the technical project because requirement changes always take place. Frequently, some buffer is built for requirement changes in the proposal and this clause is used only if changes exceed the buffer.

OTHER REQUIREMENTS AND ISSUES: Country-specific or miscellaneous requirements that can include escalation mechanisms for problem resolution, security issues, project management issues and so on.

The commercial part of the proposal basically deals with all of the monetary aspects. It gives the pricing details–rates for

manpower for various seniority levels, travel costs, special hardware costs, data communication costs, consultancy costs. It also specifies the payment schedule–of the total cost, how much is to be paid when. Typically, some payment is released at each milestone. Alternatively, payments might be made monthly. A part of the payment is withheld even after delivery and installation and is paid only after the warranty period is over.

The proposal is generally prepared by the project leader, in consultation with the salesperson who is in direct contact with the customer. Although the project leader prepares the technical part, inputs are taken from the salesperson regarding the commercial part. There might be negotiations on effort estimate, schedule, or rate before the proposal is accepted finally.

The contract



A contract is a legal document and generally covers areas not directly related to software development. Although a contract is usually desired before the work, sometimes there is a protracted negotiation on the terms of the contract. In such a situation, a ‘letter of intent’ might be given to start the project work, with contract preparation done in parallel. If the contract agreement is taking a long time, the vendor might require a purchase order or a work order from the customer. A purchase order implies that the work can start and if an agreement cannot be reached on the terms of the contract, the customer will pay for the amount of work done. 

Generally, a contract has the following types of clauses:

SCOPE OF SERVICES: Essentially it specifies that the contract is for providing software services and the general scope of work. The details of the work are not a part of the contract.

ESTIMATES: This specifies what estimates imply for the T&M and fixed-price models. In T&M, if effort estimates are done they are only a guideline. If they are exceeded, the customer has to pay for the extra effort. In the fixed-price situation, the price remains fixed unless the requirements change.

RATES AND PAYMENT: The agreed-on rates, based on which actual costs are derived are specified here along with the duration for which the rates are valid and any increase that might be there after the duration.

HARDWARE AND SOFTWARE: They specify in general terms what 



the vendor will provide and what the customer will provide. For example, it might say that
generic hardware and software will be provided by the vendor, but any special software or hardware needed for executing the project will be supplied by the customer.

CONFIDENTIALITY: It specifies that all business–personnel and technical–information provided by the customer to the vendor will be treated as confidential and care taken to properly handle such information.

SECURITY: This indicates that security measures will be taken to ensure that security of the customer’s computer systems and network is not breached.

RIGHTS ON DATA: Assures that the vendor has no rights to specific data or information provided by the customer. However, the vendor has rights to use, for future projects, the general knowledge or know-how acquired by executing this project. This section also specifies that all programs, documents for the project belong to the customer.

NONSOLICITATION: Both parties agree not to try to recruit people connected to the project for up to some period after the project expires. This clause is to prevent the customer from recruiting the vendor’s personnel during or soon after the project.

WARRANTY: The vendor gives a limited term warranty for the software it supplies. Generally, the warranty implies that the defects found during the warranty period will be fixed by the vendor free of cost.

LIMITATION OF LIABILITY: This clause limits the vendor’s liability due to malfunction of software or any similar reason. The liability for damages that might be related to the software, is generally limited to the total cost of the software provided.

INDEMNITY: Essentially it says that neither the client nor the vendor is responsible for any improper or illegal acts by the other party, in case a third party is affected by it and seeks damages.

SERVICE-LEVEL AGREEMENTS: Sometimes, particularly in the production of support systems, service-level agreements might be agreed on in terms of response time, for example. The customer might set up some reward or penalty clauses, depending on whether the service levels are met.

Excerpted from 



CMM in Practice 


By Pankaj Jalote


Published by Addison-Wesley


For queries:


jalote@cse.iitk.ac.in 

Besides these options, there are clauses on jurisdiction, arbitration, termination of contract, payment defaults and more. The clauses might need negotiations between the client and the vendor, or between lawyers of the two organizations. The clauses that tend to be contentious are the ones in which the interests of the customer and vendor differ. They include such clauses as limitation of liability, rate, nonsolicitation, penalty and warranty. 

Dr Pankaj Jalote is Professor and Chairman of Dept of Computer Science and Engineering at the Indian Institute of Technology,

Kanpur.

Advertisment