How to displease the customer or engage the customer

Abstract

Global software product companies are outsourcing projects to services companies. The current trend within services companies is to assume that since the customer knows product requirements, they must agree to customer-proposed product features, technologies, schedule, and cost; and follow a “customer-controlled approach” to project execution. However, the highly complex and dynamic nature of the software sector questions these assumptions since product technologies, business-domain requirements, and end-user requirements are continuously changing. The product company team alone cannot strike a balance between these aspects. Hence, we suggest services companies to adopt a “collaborative approach” and continuously contribute inputs to improve product feature-set, design and technologies. Hence, the services company team should express its disagreements with the product company team to suggest product improvements. However, frequent disagreement can cause customer displeasure. We suggest multiple means to channel these differences and win customer confidence. The techniques are based on experiences of executing services projects for leading global software product majors like Novell, Cabletron, Atheros, QLogic, NEC, Hitachi, etc.

Introduction

Global software product companies (customers) are outsourcing projects to services companies (implementers). The current trend among implementer companies is to assume that the customer knows the end-users’ requirements, has conducted market research, and has studied competing products. Since the customer is the best judge on all the issues, the only option left for the implementer is to agree to customer-defined product features, schedule, and cost.

Hence, the three mantras for customer satisfaction should be – agree, agree, and agree.

Thus, implementers follow a “customer-controlled approach” for executing projects.

However, we argue that this approach fails to deliver successful products due to the highly complex and dynamic nature of the software sector. We, instead, suggest a “collaborative approach” to project execution, where the implementer proactively contributes inputs to the customer in each phase of the project. The approach is based on experiences of executing services projects for leading global software product majors like Novell, Cabletron, Atheros, QLogic, NEC, Hitachi, etc.

We start the paper by discussing the related work in this domain. We then discuss limitations of the “customer-controlled approach” and then introduce our “collaborative approach.” We then present techniques to be followed in our approach in various project phases – project bid, initiation and execution phases. We also share some interesting experiences of software services companies executing projects for global customers.

Related Work

A major risk in outsourcing has been identified as schedule overrun (Hunsberger, 2011). We suggest techniques for the implementer to proactively push back the customer on requirements changes that cause overruns.

Most of the related works (Aron & Singh, 2005; Serrador, 2009; Serrador, 2008; Serrador, 2010; Holden, 2005; Camper, 2004) recommend the control of the outsourced project to solely reside with customer team, with the implementer team purely following their instructions. We, instead, argue that implementer team can add significant value if it is given freedom over deciding project features and execution approaches. We suggest techniques using that the implementer can convince the customer to make the implementer team as peers and extension to the customer team.

Product companies are outsourcing not purely for cost savings but also due to availability of unique skills in outsourced countries (Bigelow, 2002). We also agree that highly capable talent is available in implementer companies. However, customers are not fully aware of it and, hence, are not fully utilising it. The techniques suggested herein will allow implementer companies to showcase their true capabilities to the customer right from the project-bid phase itself.

A number of works (Aron & Singh, 2005; Serrador, 2009; Serrador, 2008; Serrador, 2010; Holden, 2005) insist that since implementer teams do not have the expertise in handling complex projects; hence, core/complex projects must not be outsourtced. However, we instead argue that implementer teams have much broader expertise than customer-teams. The implementer teams can apply our suggested techniques to convince the customers to offload to them more complex and large projects than they are currently handling.

Limitations of Customer Controlled Approach

In the “customer controlled approach,” implementers are assuming that the customer is the best judge on all project aspects. However, the highly complex and dynamic nature of software-sector questions makes these assumptions:

•     Software-sector is characterized by ever-evolving technological innovations. Further, a vast pool of global knowledge is available for the business domain for which a software product is being developed. This available technical and business knowledge needs to be studied and incorporated in the product being developed.

•     Products have global focus and end-user requirements vary largely between different geographies, adding to the complexity of deciding optimal features set that can satisfy all end users.

•     End-user requirements are also continuously changing, resulting in the need for implementing continuous improvements in the ongoing product development.

All the above complex and contradicting requirements make a centralized “customer-controlled approach” fail to deliver. The customer alone cannot strike a balance between all these aspects.

Collaborative Approach

We, instead, suggest a “collaborative approach,” where the implementer contributes its inputs to the customer at each stage of the product development:

•     Extensive global research is being conducted in various software domains, resulting in innovative technologies being developed. The “requirements gathering” phase of the project requires the customer to conduct extensive research in such information available globally: in competing products, in published work in journals/conferences, etc. The implementer can significantly contribute in this phase by independently conducting additional research to gather more information.

•     The customer decides the product features by gathering end-user companies’ requirements from a limited number of geographies where it has major presence. The implementer has extensive experience of executing services projects for companies from a wider range of geographies, some of which are end users of similar products. The implementer can gather requirements of these end-user companies and provide significant inputs to product features to make the product globally more acceptable.

•     The customer is usually a “domain specialist” and has a narrow focus, since it has been developing products for a single business/technology domain. The implementer, on the other hand, has experience of executing services projects in a range of business/technology domains. The implementer can utilize its broad focus to improve product design, to make it more efficient and competitive.

•     Technologies and end-user expectations are known to change frequently in the software sector. Thus, a long-duration project may require multiple changes in its requirements/features/design during the execution phase. The implementer can add value to the product by proactively keeping on top of such changing requirements and suggesting enhancements during the execution phase.

Hence, the key to successful project execution is that the implementer must participate in, and contribute to, each phase of the project. The implementer needs to clearly express its disagreements with the customer to suggest product improvements. In case of any difference of opinions, the loyalty of the implementer should be with the product, and not with the customer. The implementer could deprive the product of genuine improvements if it agrees to the viewpoint of customer on all issues.

Hence, the three new mantras for customer satisfaction need be – differ, disagree with, and displease the customer.

We suggest techniques by which the implementer can channel these differences and win customer confidence by:

•     Generating supporting data

•     Performing Cost-Benefit analysis

•     Prototyping

•     Using negotiation skills and other soft skills.

Project Bid Phase

In the project bid phase, the customer sends project requirements/features document to multiple prospective implementers. The implementer needs to prepare a project proposal suggesting technical solution/schedule/cost, etc.

The customer meets prospective implementers and awards project to one of them, based on the contents of the proposal and the ability of the implementer to convince the customer of its delivery capabilities.

We suggest that the implementer to adopt a number of measures in this phase, to win customer confidence.

•     Suggest Enhancements to Product Features

The implementer should study customer-proposed product features in detail with the aim to find mistakes in these features and to determine any missing desirable features. The purpose of faultfinding mission is manifold. First, by identifying mistakes in a document that has been comprehensively prepared/inspected by the customer team, the implementer can demonstrate that it has comprehensive command over the product domain and technology. Second, identification of these mistakes early can significantly reduce the time and effort to correct them during the project execution phase.

The implementer should next study competing international/local products. A comprehensive study of competition could reveal some important features required by business users from the product, which were not covered in the customer proposed feature set.

Finally, the implementer should suggest some other innovative features on its own, based on its past experience of executing projects in that business domain.

•     Present Corroborative Data for Suggested Enhancements

Customers are not very receptive to suggestions from the implementer team in their very first meeting for a number of reasons. The customer is an expert in the product domain and has been developing such products for long time. Its confidence in its own capability makes it difficult for it to accept that its team could have missed some features. Further, since it would be the first meeting with implementer team, the customer team is also unaware of the implementer team's capabilities. Hence, the customer is unlikely to accept the fact that the implementer team would be able to suggest improvements to its product features.

Hence, the implementer must present corroborative evidence to justify its suggestions (e.g., some other clients of the implementer may be end-user companies of similar products). The implementer can gather detailed information on their interest in its suggested features to convince the customer of the importance of these suggested features. In the absence of such corroboration from external established sources, the customer can even reject some good suggestions.

Case Study

A manager was managing teams in a services company that had been successfully following the above steps during project-bid phases for multiple projects. His team used to study the customer's product-requirements document, find mistakes/missing features, suggest feature-enhancements, and convince the customer of its capabilities by providing supporting data during their discussions.

However, once they encountered a peculiar situation. Instead of receiving a detailed requirements document, they received only one-paragraph requirement of the project accompanied by a brief software solution suggested by the customer to meet the requirement. The customer's aim was to have initial discussions with multiple prospective implementers to evaluate their skills, while its team was still formulating comprehensive product-requirements/features. The brief solution suggested was a broad framework that had to be developed further by the implementer to propose a comprehensive solution to the problem.

On receipt of the document, as usual, the manager asked his team to find mistakes and gaps in the requirements and the solution suggested therein. The team had a detailed brainstorming session but came back dejectedly. Apparently, with the limited information available about the requirements it was not possible to find any mistakes in the document. Further, the solution suggested therein seemed to be the correct solution for the limited information they had about the problem. They were disheartened.

However, the incorrigible polemic within them refused to relent.

“Fine. It is agreed that the customer has the correct solution. We can, at least, suggest an alternative solution to the same problem,” the manager announced and urged the team to go back to the drawing board.

Another long brainstorming session followed, resulting in the team being able to suggest a totally different solution to the same problem. Armed with this information, they decided to confront the customer.

The meeting started with a presentation by the customer team on the project requirements and their suggested brief solution. The implementer team responded by presenting its alternative solution to the problem. This act, expectedly, stimulated a detailed discussion. Customer team members immediately started aggressively defending their choice of the solution. Their team presented further details of the problem and gave reasons for the choice of their solution. The implementer team presented detailed supporting data for its proposed solution. Both teams went deeper in the discussions, with each presenting detailed pros and cons of their solutions. At the end of the discussions, the customer was able to convince the implementer team of the correctness of its solution. The implementer team agreed with them and the document remained unchanged.

Although, the overall result of the discussions was a status quo on product requirements and the customer-suggested solution, the detailed discussions gave multiple benefits to the implementer team. First, the customer team got a positive impression that the implementer team had the domain knowledge to think in innovative fashion and suggest an alternative solution. They gained faith that the implementer team could execute the project. Second, the detailed discussions provoked the customer to reveal much more details about their product requirements. The implementer team became privy to information that their competitors did not possess. This information was quite valuable to them when they submitted the detailed proposal to the customer later. Needless to say, they won the order.

Hence, the key learning was that it is important to stimulate a detailed discussion to create the first positive impression on the customer. If, instead, the implementer team had submitted a standard proposal for their requirements, the discussion may have petered out to being a one-way talk by the customer followed by insipid usual technical queries by the implementer team. There would not have been any opportunity for the implementer team to display their knowledge to the customer to convince it of their ability to execute the project.

Project Initiation Phase

After the project is awarded, the customer and implementer teams generally have a series of meetings to initiate the project. A major concern in this phase is that the customer team can change the project requirements that were initially agreed upon. We suggest the implementers to push back on these changes.

•     Refuse Changes Unless Unavoidable

Once a project bid is decided, the implementer plans for project execution. The manpower allocation, schedules and interdependencies of tasks are decided. Any change in the requirements at this stage would require a change in this project plan. An increase in the number of features would require the implementer to move engineers from some other task of the project to implement these additional features. This action would cause that task and all its dependent tasks to suffer. The plans can go haywire and project schedule and quality can suffer. Hence, the implementer should take a firm stand and refuse changes at this stage by presenting the above argument with supporting data.

An exception should be made only if both the parties are in full agreement that these changes are unavoidable (e.g., if technology to be used in the product itself has advanced after the features were frozen then incorporation of this improved technology can make the product more competitive in the market).

Case Study

An implementer company won a software services project from a Japanese product company and its team went to Japan for discussions to initiate the project. In one of their meetings with the customer team, an interesting development took place. Their assistant manager suggested enhanced user interfaces to the product. The implementer manager realized that the enhancements being suggested were considerable. He immediately protested mentioning that since they had already mutually finalized the features, any changes now would impact their project plans. He presented analysis of the impact of proposed changes on project plan and tasks interdependencies to show that the project schedule and quality may suffer. More arguments followed. Suddenly tempers of the customer team rose. Their assistant manager and manager talked to each other in Japanese. The manager rose and announced, “So you will not implement what we are asking for?” and walked out of the room immediately. Their team followed him.

The implementer team was suddenly tense since the issue seemed to have taken a serious turn. Further, due to the customer team's limitation in comprehensively understanding spoken English, the implementer manager was not sure if they had clearly understood his reasons for not agreeing to their demand. However, as the customer team had its mutual discussions in Japanese, which he did not understand, he still hoped that they might not have taken the issue so seriously.

The eternal optimist within him hoped that perhaps the customer manager was suddenly reminded by the assistant manager of the time to attend another meeting and hence left in a hurry! Perhaps …

However, one of the customer team members re-entered the room a little time later and reassuringly allayed any doubts the implementer team had. He informed them in clear and distinct English, that the assistant manager had said to the manager in Japanese that the implementer team was refusing to agree to their demand. He further informed them that it seemed to him that their manager was quite upset by this stand, which was the reason for his ending the meeting abruptly.

The only thing the implementer team could now do was to wait to see what happens next.

As they were suspecting, the same evening an e-mail from the customer manager was sent to the implementer company's Japan Regional Office regarding this discussion. What they were not expecting were the contents of the e-mail. The e-mail said:

“We understand that your team has accepted ownership of the project and is equally concerned about the success of the project, as we are. Hence, your team had raised genuine concerns about schedule of the project being impacted by our suggested modifications. This act of your team has affirmed our faith that the project would succeed in your hands.”

The implementer team was pleasantly surprised at the customer team's deep understanding of their viewpoint. This positive response resulted in development of a cohesive professional relationship that resulted in both the teams successfully tackling all the future project problems through mutual discussions and agreements, resulting in success of the project.

However, the implementer manager was sure that their Japan Regional Office Head would have never been able to figure out how the team was able to extract such an appreciative response from the customer, within only a week of their stay in Japan. The Office Head may have guessed that this success would have been due to the team's hard work, responsiveness to customer sensitivities and personal relation building with the customer team. However, even in his wildest of imaginations he could not have thought that the team had, instead, been able to devise a much simpler approach to achieve this objective – by simply picking up a quarrel with the customer team.

Project Execution Phase

We consider the case of execution phase of large software projects, which can usually take many months to be completed. Since, technologies and business domain requirements change very fast in software domain, we suggest the implementer to be proactive to such global changes.

•     Suggest Changes to Product Features

The implementer should continuously keep track of improvements occurring in the technology and business domains of the product and suggest enhancements to product features/design:

Interestingly, at first look, the recommendation to the implementer to suggest changes to the product features seems to contradict the recommendation given in the last section, to refuse changes to the product. However, the key here is the duration of the project execution. In case of small duration projects, such changes in features should be avoided. However, for long duration projects the changes need to be incorporated to keep pace with the ongoing developments in the market during the time the project is being executed.

•     Present a Cost-Benefit Analysis

Any feature or design additions/improvements suggested during the execution of the project would result in increase in project schedule and cost. Hence, the customer is generally not receptive to such suggested changes. The implementer should perform a cost-benefit analysis of each suggested feature enhancement. The analysis should list the possible benefits to the product by the feature enhancement, like the expected additional monetary returns due to wider market acceptability of the product. The cost analysis should detail the expected delay in delivery of the project, and the additional cost to be incurred for implementing the feature. The customer can then decide on a subset of features that are critical to the success of the project and can also be implemented without causing a high impact on the project schedule and cost.

•     Develop a Prototype

The customer may not be fully able to appreciate the utility of suggested feature enhancements. The implementer should develop a “prototype” for the product enhancements being suggested to convince the customer.

A prototype is a small piece of software that models the functions of the final software product being developed. On execution, the prototype broadly shows how the features would work in the final product. The customer can then accept some of these features and can give a go-ahead to the implementer to implement them. Hence, a prototype can be developed in a short duration with minimal cost and effort, and can still help in taking critical decisions about the project.