ISO_8

How to Displease the Customer, to Engage
the Customer

Vimal Kumar Khanna – Managing Director, mCalibre Technologies

Contents
1. Abstract ........................................................................................................................................... 4
2. Introduction...................................................................................................................................... 4
3. Related Work................................................................................................................................... 4
4. Limitations of Customer-Controlled Approach ................................................................................ 5
5. Collaborative Approach ................................................................................................................... 5
6. Project Bid Phase ............................................................................................................................ 7
7. Project Initiation phase .................................................................................................................... 9
8. Project Execution Phase ............................................................................................................... 10
9. Conclusion..................................................................................................................................... 11
10. References .................................................................................................................................. 11
10. Author’s Profile ............................................................................................................................ 13

3 Page

1. Abstract
Global software product-companies are outsourcing projects to services-companies. Current trend
within services-companies is to assume that since customer knows product requirements they must
agree to customer-proposed product-features/technologies/schedule/cost and follow a “Customer-
Controlled Approach” to project execution. However, highly complex and dynamic nature of 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/technologies.
Hence, services-company team should regularly express disagreements with 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.

2. Introduction
Global software product companies (Customers) are outsourcing projects to Indian services-
companies (Implementers). Current trend among Implementer-companies is to assume that Customer
knows end-users' requirements, has conducted market research and has studied competing products.
Since, 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/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 highly complex and
dynamic nature of software sector. We, instead, suggest a “Collaborative Approach” to project
execution, where Implementer proactively contributes in each phase of project.

We start the paper by discussing Related Work in this domain. We then discuss limitations of
“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 Indian software-services
companies executing projects for customers like NEC-Japan and Hitachi-Japan.

3. Related Work
A major risk in outsourcing has been identified as schedule-overrun [1]. We suggest techniques for
the Implementer to proactively push-back the Customer on requirements changes that cause
overruns.

Most of the related works [2,4,5,6,7,8] recommend the control of the outsourced project to solely
reside with Customer-team, with the Implementer-team purely following their instructions. We,
4 Page

instead, argue that Implementer-team can add significantly value if it is given freedom over deciding
project features and execution approaches. We suggest techniques using which Implementer can
convince the Customer to make Implementer-team as peers and extension to Customer-team.

Product-companies are outsourcing not purely for cost savings but also due to availability of unique
skills in outsourced countries [3]. 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 above works [2,4,5,6,7] 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 them
more complex and large projects than they are currently handling.

4. Limitations of Customer-Controlled Approach
In “Customer-Controlled Approach”, Implementers are assuming that the Customer is the best judge
on all project aspects. However, highly complex and dynamic nature of software-sector questions
these assumptions-

Software-sector is characterised by ever-evolving technological innovations. 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.

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

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

All the above complex and contradicting requirements make a centralised “Customer-Controlled
Approach” fail to deliver. Customer alone cannot strike a balance between all these aspects.

5. Collaborative Approach
We, instead, suggest a “Collaborative Approach”, where the Implementer contributes its inputs to
Customer at each stage of product development-

5 Page

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.

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 companies are end-users of similar products. Implementer can
gather requirements of these end-user companies and provide significant inputs to product
features, to make the product globally more acceptable.

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 projects in a range of business/technology domains.
Implementer can utilise 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 software sector.
Thus, a long-duration project may require multiple changes in its
requirements/features/design during the execution phase. 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 his 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 Implementer can channel these differences and win Customer
confidence by–

Generating supporting data
Performing Cost-Benefit analysis
Prototyping
Using negotiation and other soft-skills.

6 Page

6. 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 Customer of its delivery
capabilities.

We suggest Implementer to adopt a number of measures in this phase, to win Customer confidence-

Suggest Enhancements to Product Features
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. Firstly, by identifying mistakes in a document that has been
comprehensively prepared/inspected by Customer-team, the Implementer can demonstrate
that it has comprehensive command over the product domain and technology. Secondly,
identification of these mistakes early can significantly reduce the time and effort to correct
them during project execution phase.

Implementer should next study competing international 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, 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-teams 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 its first meeting with Implementer-team, Customer-team is also unaware of the
Implementer-team’s capabilities. Hence, Customer is unlikely to accept the fact that
Implementer-team would be able to suggest improvements to its product features.

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

6.1 Case Study

I was managing teams in a services company that had been successfully following the above steps
during project-bid phases for multiple projects. We used to study the Customer’s product-

7 Page

requirements document, find mistakes/missing features, suggest feature-enhancements and convince
the Customer of our capabilities by providing supporting data during our discussions.

However, once we encountered a peculiar situation. Instead of receiving detailed requirements
document, we 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, I asked my 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 we had about the problem. We were disheartened.

However, the incorrigible polemic within us refused to relent.

"Fine. Agreed, that the Customer has the correct solution. We can, at least, suggest an alternative
solution to the same problem", I announced and urged our team to go back to drawing board.

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

Our meeting started with a presentation by the Customer on the project requirements and their
suggested brief solution. We responded by presenting our alternative solution to the problem. This
act, expectedly, stimulated a detailed discussion. Their team 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. We presented detailed supporting data for our 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 us of the
correctness of their solution. We agreed with them and the document remained unchanged.

Although, the overall result of the discussions was a status quo on product-requirements and
Customer-suggested solution but the detailed discussions gave multiple benefits to us. Firstly, the
Customer-team got a positive impression that we had the domain knowledge to think in innovative
fashion and suggest an alternative solution. They gained faith that we could execute the project.
Secondly, the detailed discussions provoked the Customer to reveal much more details about their
product-requirements. We became privy to information that our competitors did not possess. This
information was quite valuable to us when we submitted the detailed proposal to them later. Needless
to say, we 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, we 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 our team. There would not have been any opportunity for our
8 Page

team to display their knowledge to the Customer, to convince it of our ability to execute the project.

7. 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 inter-dependencies 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 tas 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 product 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.

7.1 Case Study
We won a software services project and our team went to Japan for discussions to initiate project. In
one of our meetings with the Customer team, an interesting development took place. Their Assistant
Manager suggested enhanced user interfaces to the product. We realised that the enhancements
being suggested were considerable. I immediately protested mentioning that since we had already
mutually finalised the features, any changes now would impact our project plans. I presented analysis
of impact of proposed changes on project plan and tasks inter-dependencies to show that project
schedule and quality may suffer. More arguments followed. Suddenly tempers of their 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.

We were suddenly tense since the issue seemed to have taken a serious turn. Further, due to their
limitation in comprehensively understanding spoken English, we were not sure if they had clearly
understood our reasons for not agreeing to their demand. However, as they had their mutual
discussions in Japanese, which we did not understand, we still hoped that they might not have taken
the issue so seriously.

The eternal optimist within us hoped that perhaps the Manager was suddenly reminded of the time to
attend another meeting and hence left in a hurry! Perhaps...

However, one of their team members re-entered the room and reassuringly allayed any doubts we
had. He informed us, in clear and distinct English, that the Assistant Manager had said to the
9 Page

Manager in Japanese that we were refusing to agree to their demand. He further informed that it
seemed to him that their Manager was quite upset by our stand, which was the reason for their
ending the meeting abruptly.

The only thing we could now do was to wait to see what happens next.

As we were suspecting, the same evening an e-mail from their Manager was sent to our Japan
Regional Office regarding this discussion. What we 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.”

We were pleasantly surprised at their deep understanding of our viewpoint. This positive response
resulted in development of a cohesive professional relationship that resulted in both teams
successfully tackling all the future project problems through mutual discussions and agreements,
resulting in success of the project.

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

8. 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
Implementer should continuously keep track of improvements occurring in the technology and
business domains of the product and suggest enhancements to product features/design-
- Study journals/conference proceedings that discuss new improved software
technologies being developed in that technical domain.
- Study new features of competing products being released in the market.
- Be aware of the changing needs of the business domain for which the product is
being developed, by seeking inputs from its other clients who are end-users of
products in this business domain.
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

10 Page

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, Customer is generally not receptive to such
suggested changes. 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. 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
Customer may not be fully able to appreciate the utility of suggested feature enhancements.
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. 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.

9. Conclusion
We have suggested software services-companies to adopt a “Collaborative Approach” to project
execution where they can collaborate with customer to add significant value in all project phases. Our
techniques can be applied by services-companies to gain customer confidence and be given freedom
and control to improve project requirements/design/execution.

10. References
1. Hunsberger, K. (2011). The Risks of Outsourcing – Know them and what to do about them, PM
Network, November 2011.
2. Aron, R., and Singh, J. V. (2005). Getting Offshoring Right. Harvard Business Review
(December) 135-143.
3. Bigelow, D. (2002).Will Outsourcing Relationships rule the New Millenium? PM Network (May) 22.
4. Serrador, P. (2009). Far Flung. PM Network (November) 28-29.
5. Serrador, P. (2008). Offshoring for the Project Manager: Globalization is here. Are you ready to
take advantage of it? PMI Global Congress – Denver, USA.

11 Page

6. Serrador, P. (2010). Offshoring: How to keep your Western Clients coming back. PMI Global
Congress – Melbourne, Australia.
7. Holden, A.D. (2005). Evolving the Paradigm: Leading Multicultural Teams. PMI Global Congress
– Toronto, Canada.
8. Camper Bull, R. (2004). International Projects and Off-shoring: A New Paradigm. PMI Global
Congress – Anaheim, Canada.

12 Page

10. Author’s Profile

Vimal Kumar Khanna is Founder and Managing
Director of “mCalibre Technologies”, a Knowledge
Processing software startup. He has over 27
years industry experience and has won multiple
international honours. He is listed in “Marquis
Who’s Who in the World”. He is also among 50
select experts in the world to be on “IEEE
Communications” (pub. New York) Editorial Board
(invited honorary position). His multiple
independently-written papers have been
published in leading international
journals/conferences, including PMI Global
Congress 2010 - Asia Pacific, Melbourne; PMI
Asia Pacific e-Link; PMI India Conferences 2010
and 2011. He has been interviewed in “PM
Network” magazine.

Email: vimal_k@ieee.org

13 Page

ISO_8

More Related Content

What's hot (20)

Similar to ISO_8 (20)

More from PMI2011 (20)

Recently uploaded (20)

ISO_8