Achieving Delivery Excellence in Very Adverse External Project Environment

A Global Case Study



This paper presents the success story of a global multimillion-dollar program acquired in the most adverse business environment. The first part of the paper explains the key challenges, which included concurrent development and upgrade of several software product applications in a different line of business with non-negotiable and very tight delivery timelines; a non-cooperative key software product vendor; and a limited first-hand experience of managing such end-to-end mega programs by the system integrator. The second part of the paper explains how these challenges were met with aggressive use of innovation and intense internal collaboration. Some of these included multi-skilling, creation of techno-functional experts, very quick ramping of talents, collaborating with internal academies, the use of newer technologies like “Wiki,” frequent but focused and short communications with clients, directly connecting to end-users of the system, and so forth. Finally, the paper will discuss achieving excellence in delivery culminating in a formal appreciation letter from the customer.


This paper discusses, as a case-study example, the successful win and subsequent execution of a multimillion-dollar global program by a globally respected multi-national IT service provider in the face of several new and conflicting business challenges. The program was taken up by the IT Service Provider (hereafter referred to as “SI”) to manage the end-to-end delivery of a business application package software system to manage and automate the Service Fulfillment and Service Assurance processes for a major Europe-based multi-national Telecom Company. The system was built by extensively customizing a packaged application.

The primary focus of the project was to design and deliver software solutions to reduce the total cost of new product launches and of fault resolution of its telecom products and services. This system was to be the heart of the service management platform of the end-to-end solution stack of the client. It also played a role of coordinating with other software component systems of the stack to achieve the end-to-end business objectives of the solution stack. Moreover, it was also part of a bigger program that was mission-critical to the client's future in terms of its market positioning and overall business success and hence the risks involved from the client side and SI side were very high.

This system was initially being commissioned by another vendor who also happened to be the software product owner of the packaged software solution, which was selected as a part of overall solution to be implemented, but with lots of customization built-up to take care of the client's specific and new requirements toward the business solution. However, the client was not very satisfied with the quality and high development cost of the application being developed by the product vendor. So, in the middle of one delivery cycle, the client recommended the project could be done by the SI, if the SI could provide the same service, with no compromise on the earlier agreed deliverables (by the software vendor) of that quarter.

Because of these reasons, this program was under a constant microscope of all the senior management of the client and it became a system with very high visibility. Any non-performance would instantly be highlighted across the client's top management.

Against this background, the SI accepted the challenging program and started work. There were various other challenges that came along the way. But each of these was countered successfully with innovation, and internal collaboration of several internal departments, leading to a well-deserved success story.

In the light of these conditions, the following were considered as the critical success factors for this program:

  • Maintain high quality standards in every delivery with non-negotiable timelines
  • Maintain the skewed onsite offshore ratio of 10:90
  • Improve end-user acceptability of the system
  • Reduce cost of ownership of the application
  • Reduce “time-to-market” and cost of new product launch
  • Maintain a healthy operating margin for the project.

The following paragraphs explain these challenges in greater details and how were those overcome.

Key Challenges Faced

An Un-Supportive Software Product Vendor

An immediate challenge heading into the project was taking over from the incumbent software product vendor, in the middle of a delivery cycle, who was earlier responsible for the service deliverables also. At the same time, there was no letup from the client in terms of delivery expectations. The client expected the SI to complete the committed deliveries for that quarter also, as any slippage in deliveries of any one system could prove to be a major setback for the entire program at the client's end. This meant that the SI had to not only work hard on delivery but also had to obtain the knowledge transition (KT) from the incumbent vendor to ramp-up its skills, which was obviously so very difficult under these circumstances.

Moreover, the sudden loss of business for the incumbent vendor turned them hostile toward the SI. The KT sessions planned were with little or no cooperation from them. The incumbent vendor also being the product owner meant that similar non-cooperation was to be expected in resolution of any bugs/defects in the product, on a continuous basis in the future.

Inexperienced Team With Need for Sudden Ramp-Up

Taking up the project in the middle of a delivery cycle meant that the core team to work on the project was very small—about 40 people at that point. Most of the team wasn’t experienced with client processes and requirements. Also, it was a first-of-its-kind experience for the senior project managers of the team to manage such a mega end-to-end program, under the new circumstances.

With a huge inflow of business in the pipeline from the client, there was a need to ramp-up the team size manifolds (from 40 to 200) in a period of two months to meet all the business requirements of the client. The resourcing challenge was to inject new resources and groom them for roles such as designer, developer, tester, domain experts, delivery manager, and quality manager.

Working in Agile—Short Project Visibility

The client mandated the program to be executed in an Agile Methodology. Thus, the project delivery demands were aggressive, with production drops being every six weeks. This required a large amount of functionality to be developed and deployed regularly. This was made more challenging because of the program involving a multi-vendors environment leading to injection of complex development dependencies and an implicit competition. Working in Agile Methodology meant that activities of development, design (high and low level), deployment, testing, and test support were to be going at the same time. This has been depicted in Exhibit 1.

Overlap of Multiple Project Tasks in Agile

Exhibit 1: Overlap of Multiple Project Tasks in Agile

In order to reduce their risks the client also reduced the delivery cycle from the earlier 12-week iteration to a 6-week iteration. This agile implementation strained the resource management processes further. This not only demanded higher productivity/deliveries in a shorter time frame but also decreased the resource requirements visibility. The team size could potentially vary dramatically between two consecutive delivery cycles based on the business requirements and priorities of the client.

Multi-Vendor Environment Across Multiple Geographies

It was a new environment in which the program was to be executed. As previously mentioned the packaged software system was one of the many software systems across the end-to-end stack of the client. So, all the work for this program had to be done interacting with these multiple software systems, some of which were owned by other competitor vendors. This multi-vendor environment posed its own unique challenges. There was a pressing need to achieve the right balance between collaborative and aggressive attitude with the other vendors.

The system was to be used by the client for 12 of its products. This posed the challenge of communicating with multi-faceted customers of different roles from different products.

Also, because of the Global Delivery Model (GDM), the internal teams of the SI, the other component vendors, and the clients were located at multiple locations in multiple geographies across India and Europe. At the same time, the client also had collocation centers setup for the “Independent Validation and Verification Testing.”

The challenges here included ensuring all project activities were happening on schedule, the coordination with other vendors was smooth, and the client was always kept updated with the developments.

Stakeholder Identification

Early into the project, it was apparent that the most important stakeholder was the operational end-user of the application and it was critical to address his or her concerns while developing the system. Getting acceptance of the new system over the legacy system was another daunting task.

The previous vendor had ignored this community of users leading to non-acceptance of the system, which could have resulted in premature termination of this program.


The client had defined and strict quality standards and had elaborate processes in place to ensure quality of deliverables at each phase. Adherence to these quality standards was of utmost importance to the client and was a prime vendor evaluation parameter. The client also imposed strict punitive measures with severe financial implications for lack of quality in the final code delivered. Any lapse on this parameter resulted in very fast escalations to CxO level of the client and also had long-term business implications.

Also, as stated in the introduction, with this system being the heart of the client solution stack, there was no scope of any non-performance of the system in live or in the testing environment. Any slippage in system availability would result in downtime of the entire stack leading to financial loss to the client and unnecessary effort spent in getting the system up. So, it was critical to ensure a bug-free code.

Cost Reduction and Faster “Time-to-Market”

One of the primary objectives of the client was to reduce cost of delivery. So, the client regularly pushed the SI to deliver on this objective. One such step was to get most of the work done from offshore. The client also wanted to extend the solution to other products in its offerings and launch them into the market in as quick as possible with as little cost as possible.

The distributed nature of the project teams introduced complexity and higher risks in terms of code management, code merge process, deployments management, and testing. It increased the chances of defect injection during code merge activities.

Testing is critical in any development project. Early on in the project, the testing was a manual activity. But with the increase in requirements and a need of regression testing because of an iterative Agile delivery, manual testing would have been the difference between success and failure. Also, manual testing would have needed an army of testers working inhuman hours to achieve this kind of quality.

Skewed Onsite-Offshore Ratio

The conventional onsite-offshore ratio for the SI was traditionally an optimal 30:70. However, the client mandated a ratio of 10:90 to reduce the program cost. This put a lot of strain on the project manager to ensure quality with a skewed resource ratio. It also introduced complexities and accordingly higher risks in terms of sharing of work between offshore and onsite, the core attribute of GDM implementations.

Innovations to Resolve Challenges: Methodologies Followed

Being Agile

Multi-Skilled Onsite Team

Working in Agile with the skewed onsite-offshore ratio was countered by utilizing onsite resources to fulfill multiple roles that were required to be executed from onsite, thereby reducing the onsite resource numbers. For example, roles like design, delivery management, and testing support were combined into one for the purpose of this program. The onsite (in Europe) and offshore (India) time zones overlap of 4 ~ 5 hours made this model very convenient to work with. It enabled active participation of the offshore team in client interactions. This not only helped in managing parallel activities but also facilitated balancing of work between the resources and finally in enriching the skills of the resources. The time overlap especially helped during the design phase, one of the prime shared activities. The involvement of the customer with the team during the design phase is the crux of any Agile delivery.

Use of “Wiki”

The program used an innovative tool for knowledge sharing. A common “Wiki” was launched that worked as a single snapshot view of the project from a non-engineering perspective. This was used commonly by both onsite and offshore resources. It was a “first-of-its-kind” initiative across the practice.

“Wiki” is a quick collaborative tool for communicating among the relevant team members. Whenever a new requirement from the customer was discussed, the designer would add a new page to the “Wiki” related to that scenario detailing out the requirement for all to understand and work with. The delivery manager could add all the delivery related details there and so on. All the necessary documents related to that scenario could be uploaded and stored for all to access at any time in the project history.

Without the “Wiki,” maintaining this kind of information would have been a very cumbersome and slow task. This bypassed the need of circulating multi-versioned documents/e-mails among teams for knowledge sharing.

Balancing Quality with Reduced Cost

Ensuring lower defect rate in production was not an overnight step, and instead it needed a strong process to meet the end objective. A series of new initiatives were taken up to ensure a high quality code. The best coding standards were followed during the development phase. An innovative and novel approach of deployment was followed. The skills of the testing were improved to catch all possible defects. Some of these are elaborated as follows:

Techno-Functional Testing Team

A strong testing team was essential to maintain the quality of the system. So, the testing team needed to have resources that were not only application development experts but also had sound knowledge of the business and client working model. This was necessary to improve the quality of the test cases and also increase the testing coverage. So, techno-functional testing teams were setup, which proved very successful.

The techno-functional teams were also placed at collocation centers to work closely with other components. This ensured closer inter-team communication, minimizing the defect resolution time.

Reusable Artifact Development with Automation of Coding Practices

A number of reusable artifacts were created that critically reduced the time taken for a number of manual activities. Also, tools and scripts were developed for facilitating development, deployment, and testing teams. The design team was assisted by publishing a number of quick reference guides and documents, resulting in reduction of system study and research time noticeably.

A number of reusable artifacts were created leading to a cost saving. It translated to more than 150 person-months of effort saved per annum. Automation of code deployment reduced the application downtime by 60% and improved the cost saving. Exhibit 2 shows the improved data after the automated code deployment was implemented.

Pareto Chart

Exhibit 2: Pareto Chart

Automated Testing Scripts/Tools

Automated testing scripts were developed. This reduced the chances of manual errors during the exhaustive testing process. Also, it decreased the amount of time required while performing regression testing. The test automation tools resulted in 40% improvement. As depicted in Exhibit 3, the number of defects raised (per function point) also reduced by 26%.

Defects per 100 FPs

Exhibit 3: Defects per 100 FPs

Configurable Code Development

The enhancements requested by the customer were made as close as possible to a configurable change. This meant that the customer could extend this solution to other products in its offerings with minimum code change. This helped reduce the time-to-market for the customer's newer products.

Collaboration to Resolve Challenges: Methodologies Followed

Excellence in Project Management

Critical Delivery Management with Shared Responsibility

Handling the multiple internal teams spread across locations was managed by a very strong and robust delivery team at both offshore and onsite. This team was responsible not only for managing scope delivery but also ensuring that all project activities were adhering to the timelines. Daily standup calls were conducted, with regular updates being published to the client. These were focused calls lasting up to a maximum of 60 minutes with only relevant managers on the call. This helped in managing the delivery critical dependencies and forecasting delivery timelines, and resolved any issues the same day, without any further delay.

Shared Resources Strategy

The challenge of “short project visibility” was countered by a combination of a “multi-skilled, shared resources strategy.” The resources working on the project were groomed to being multi-skilled so that for any delivery cycle, if the load on this project decreased, then these resources could be utilized on other projects with the same or other client where they were needed.

The project manager planned a resource capacity for this program, which was discussed with and approved by the client. Any work-stack that came in the project's way was analyzed keeping this resource constraint in mind. This was a very successful approach that has been further extended into similar engagements within the practice.

Quality Anchors

To ensure compliance to the various quality metrics of the client, senior resources in the project were made quality anchors to ensure that the guidelines laid down by the client were very strictly adhered to.

Stakeholder Identification—Established Customer Experience Team

Keeping in mind the importance of the end-user as a primary stakeholder, a special customer experience team was formed, which unilaterally focused on improving the user experience of this set of customers. The mistakes of the previous vendor weren’t repeated here and every effort was made to gain the acceptance for the system. The main job of the team was as follows:

  • To understand the main areas of the end-users from the legacy systems
  • To understand their expectations/requirements from the new system
  • To demo and get approval of newly delivered functionality
  • To ensure quick resolution of their queries/issues.

Excellence in Communication Management

Communication Matrix

Being an Agile project implemented in a GDM resulted in presence of members distant from each other. On the other hand, Agile makes it mandatory for all the team members to be collocated. To mitigate any risks, all the activities that spanned across multiple internal teams were carefully sequenced. The cycle used to start with designers gathering the requirements from client, designers discussing with other component designers to sort out any dependency issues, designers then communicating the designs to development and testing teams, And development and testing teams communicating for bug fixes and clarifications. (Refer Exhibit 4 for communication matrix.)

Communication Matrix

Exhibit 4: Communication Matrix

Unconventional KT from a Non-cooperative Product Vendor

As the program was taken over in the middle of the delivery cycle, the SI had to address multiple concerns:

  • Meeting the delivery commitments
  • Obtaining project-related knowledge from the unwilling vendor
  • Knowledge transfer to new members of the team.

To resolve this, a KT plan was formulated identifying the areas where transition was required. This plan was shared with the client and a formal invite was made to the incumbent vendor through the client to have SMEs to conduct knowledge sessions for the new team. These sessions were conducted at onsite and offshore locations to scale up the resources. In order to have a satisfactory KT, regular feedbacks were also provided to the client.

An elaborate internal training plan was developed. This included syncing up of the offshore team with onsite at frequent intervals, division of the day in knowledge activities, and project tasks.

Other than this cooperations was sought of other internal experts of the SI, not engaged in this project but knowledgeable of the product or the client's processes. Such support came from the Enterprise Solutions Academy and some other peers working partly in other groups. The KT sessions with the incumbent SI were discussed with them once a week to answer further questions and acquire more knowledge.

These KT sessions were balanced with the delivery-related work.


Quantified Benefits to Client

  • There was a reduced cost of implementation for the client (fewer MUSD/Annum over earlier vendor)
  • The deliveries of the solution in various delivery cycles met the right first time mark of 97%. This reduced the costs for the customer in terms of unnecessary rework.
  • Effective cost management lead to a constant decrease in the application development cost (cost per function point) as depicted in Exhibit 5.
    Cost per FP

    Exhibit 5: Cost per FP

  • There was a 26% reduction in defects in system.
  • It was an end-user-friendly application with high user acceptance.
  • Successful delivery of the project was instrumental in the customer being able to launch its flagship product to its end-users as per their aggressive timelines.

Quantified Benefits to SI

  • Successful delivery of this project helped the SI bag a similar implementation project with the same client.
  • CxO level references were generated out of this project, which were leveraged to win deals with other telecom companies in different geographies.
  • Healthy revenue generation boosted the finances of the SI.

This program demonstrates how the use of aggressive collaboration with the right internal partners and innovative solutions can achieve a win-win situation for all stakeholders.


We would like to extend our sincere gratitude to the following for extending their support in the preparation of this paper:

Mr. Prashant Kondi  
Consultant, Enterprise Solutions, Mr. Rohit Kaushal
Infosys Technologies Ltd. Associate Consultant, Enterprise Solutions,
Infosys Technologies Ltd.  


Kerzner Harold. (2004). Project management: A systems approach to planning, scheduling and controlling. New York: John Wiley and Sons Inc.

© 2009, Ravi Kumar S, Naveen Kumar, Dr. Subhash. C. Rastogi
Originally published as a part of 2009 PMI Global Congress Proceedings – Kuala Lumpur, Malaysia



Related Content

  • PMI White Paper

    Agile Regulation member content open

    By National Academy of Public Admiistration | PMI The National Academy of Public Administration recently presented the results of a year-long effort to identify the Grand Challenges in Public Administration.

  • PM Network

    O próximo despertar do ágil member content open

    By Parsi, Novid Durante a interrupção total da pandemia global, o agile tem sido um reforço e uma revelação.

  • PM Network

    A certeza da incerteza member content open

    By Fewell, Jesse Por mais que ansiamos por um retorno pré-pandêmico, é ingênuo pensar que as velhas formas de trabalho um dia voltarão - mesmo para o ágil.

  • PM Network

    La certeza de la incertidumbre member content open

    By Fewell, Jesse Por mucho que anhelemos un regreso antes de la pandemia, es ingenuo pensar que las viejas formas de trabajo volverán alguna vez, incluso para lo ágil.

  • PM Network

    El proximo despertar agil member content open

    By Parsi, Novid Durante la interrupción de todo vale de la pandemia global, Agile ha sido tanto un refuerzo como una revelación.