For the exclusive use of C. Tun, 2022. IIMB INDIAN INSTITUTE OF MANAGEMENT BANGALORE IMB 833 EXCEED: IMPROVING PRODUCTIVITY AND RELIABILITY IN DELIVERY OF SOFTWARE SOLUTIONS SIVAKUMAR S AND B MAHADEVAN Sivakumar S, Assistant Professor of Operations Management & Decision Sciences at IIM, Tiruchirappalli and B. Mahadevan, Professor of Production & Operations Management, prepared this case for classroom discussion. Exceed Communications LLC cooperated and provided information to the Indian Institute of Management Bangalore in connection with the preparation of this case and it was reviewed and approved before publication by a Exceed Communications designate. No funding was sought or received from Exceed Communications LLC for the development of this case. This case was also developed from available and permitted sources of information. This case is not intended to serve as an endorsement, source of primary data, or to show effective or inefficient handling of decision or business processes. Copyright 2021 by the Indian Institute of Management Bangalore. No part of the publication may be reproduced or transmitted in any form or by any means - electronic, mechanical, photocopying, recording, or otherwise (including internet) - without the permission of Indian Institute of Management Bangalore. This document is authorized for use only by ChawSu Tun in OPMT 620 - Winter - Case study 1 taught by Farnoosh Bagheri, University Canada West from Feb 2022 to Aug 2022. For the exclusive use of C. Tun, 2022. Exceed: Improving Productivity and Reliability in Delivery of Software Solutions IIMB It was a chilly Monday morning on February 6, 2017. Mohamed Karamathullah (Karamath henceforth), Managing Director, Exceed Communications LLC (ECL) was on a visit to their offshore development center in Bangalore. He was immersed in thoughts as he walked into his office in the buzzing industrial suburbs of Bangalore, India. ECL was always proud of its track record in development and maintenance of integrated hardware and software solutions and associated services. ECL was known for its reliable deliveries in line with their commitments. However, recently, one customer account had been bothering Karamath. He began the workday by checking his e- mails, a routine he diligently followed. He glanced through the weekly status reports sent on the previous day by his client engagement manager. The e-mail on an escalation alert from one of his client managers caught his attention. It was yet again the same customer account. The latest complaint was about the slow progress of system testing of a software package being developed for that client. Furthermore, the e-mail pointed to several defects found during the ongoing system testing phase. This particular client was demanding and tended to jump the gun at times. What bothered Karamath was that the frequency of escalation e-mails from this customer was high compared to their other customer accounts. Was this latest complaint another one-off issue or was there a larger pattern behind this? What could he do to improve the productivity and reliability of their deliveries to this client? COMPANY BACKGROUND Exceed Communications LLC (ECL) was a specialist hardware and software solutions' company that provided reliable, high quality, customized business solutions to clients based out of the Middle East, Africa, and South Asia. The company was founded in 2013. As of January 2017, they had a team size of 36 members spread between their offices in the Middle East and Bangalore. ECL was rated by the industry analysts as one of the fastest-growing hardware and software solutions' company in the United Arab Emirates. They prided themselves on a solution- based approach to understand the business ambitions and technological requirements of their customers, to uniquely craft a techno-business solution customized to their clients. They provided a variety of network and security solutions, hardware cum software development and maintenance services, and digital marketing solutions to their clients. ECL had a technological partnership with a wide array of global product labels including 3M, Avaya, Bosch, Cisco, HP, Dell, Microsoft, Samsung, Schneider, and Xerox. As of January 2017, ECL had over 30 marquee clients spread across the Middle East, Africa, and South Asia. SOFTWARE DEVELOPMENT PROJECT FOR H&K ACCOUNT H&K (name disguised) was a market leader in providing real estate and integrated business management solutions to its clients. Its relationship with ECL began in October 2015. ECL was developing a bespoke software package for customer relationship management of the clients of H&K. The project was being executed on a Time and Material basis, where the client closely monitored both staffing volumes and staff productivity. The project followed a V- process model in the software development lifecycle (Exhibit 1). This model was an improved version of the waterfall process model that started with requirement gathering and ended with user-acceptance testing. In this process model, the test cases for the various testing phases were developed alongside the requirements, higher- level, and detail design documents. The current project started in August 2016 and on February 6, 2017 was into the system testing phase in the client's test environment. The project had experienced its ups and downs, but the dedication and capability of ECL team members had played a significant role in the progress of the project. Although the project was delayed at the start due to delay in collecting business requirements, the team had made good the delay during the development phase. However, in the extremely competitive environment that ECL operated in, clients such as H&K were increasingly demanding higher quality and quicker deliveries. 1 Time and Material is a common billing model prevalent in professional services where the vendor bills the client for the effort incurred (as recorded in a timesheet) and actual cost of materials used to service the client. Page 2 of 8 This document is authorized for use only by ChawSu Tun in OPMT 620 - Winter - Case study 1 taught by Farnoosh Bagheri, University Canada West from Feb 2022 to Aug 2022. For the exclusive use of C. Tun, 2022. Exceed: Improving Productivity and Reliability in Delivery of Software Solutions IIMB Karamath telephoned Mohammed Aslam to discuss the latest customer complaint. Aslam was the head of operations, responsible for all services provided to H&K and was based out of their Dubai office. Aslam sent his spreadsheet tracker that meticulously recorded all the customer complaints received from H&K since the start of the project (Exhibit 2). Karamath quickly glanced through the tabulation but was not sure if there was any pattern behind the complaints. The customer appeared to have frequently complained about the team working too slowly (productivity complaint) and too many errors (quality complaint). The complaints on excess staffing were a result of the client micromanaging the project based on the timesheet submitted by the project personnel. However, Karamath was not sure as to which of these categories of complaints required immediate attention. PRODUCTIVITY DATA Karamath had also asked Aslam to send him data on the progress of system testing activity that was underway. The activity involved the execution of system test cases to verify the conformance of the developed software package to the specifications. Aslam had collated the statistics of test case execution for every two-hour window for the past 4 weeks (Exhibit 3). Karamath quickly calculated the average of test cases executed. He felt it was better than the company average. There were some days when the numbers were low, but according to him, there appeared nothing alarming to complain about. When he inquired Aslam about the reasons for customer complaints, Aslam had the following to say: The latest customer complaint was perhaps referring to testing performed on 12th January, 17th January or on 1st February; those were the days of lower productivity. These were one-off discrepancies, and everything was under control. According to me, there was nothing that required further action. But was it? wondered Karamath. TEAM MEETING Karamath arranged a conference call with the entire project team to discuss the various concerns raised by the client. All the senior members of the client engagement, development, and testing teams were invited to this conference call. Karamath listed the summary of the concerns reported by the client and particularly raised the issue of inconsistent productivity in the execution of system test cases. The attendees came up with various explanations for this issue. One senior testing team member stated: Execution of test cases is not easy, because we have to identify suitable test data for testing the identified test scenarios. It sometimes requires a complicated SQL code to identify the relevant test data for execution. This takes a lot of time! The head of system testing team remarked: We are not always operating at our full potential. We have an agreement that the development team will deploy a fresh software package before 9 AM, after fixing of the bugs. But many days their deployment finishes only by 11 AM and our testing productivity is impacted on account of this. The other members of the system testing team complained that their computers had insufficient RAM slowing down the testing process. There was also latency in the network forcing slow access to the client's test environment. Karamath had earlier heard complaints about the latency in accessing client network, but he was not sure whether that was the primary explanation for low productivity. Page 3 of 8 This document is authorized for use only by ChawSu Tun in OPMT 620 - Winter - Case study 1 taught by Farnoosh Bagheri, University Canada West from Feb 2022 to Aug 2022. For the exclusive use of C. Tun, 2022. Exceed: Improving Productivity and Reliability in Delivery of Software Solutions IIMB One of the technical experts in the team called Dashrath who had a background in the automation of testing processes stated: Sir, our testing is bound to have low productivity as it is being done manually. We had test automation in the previous project for H&K and they are perhaps expecting the same standard now. In manual testing when we have to re-test failed test scenarios, it requires data entry once again. This involves a significant time overhead. Although testing automation was an expensive proposition, Karamath thought there was merit in the argument made by Dashrath. Manual testing relied on the testing personnel to enter the test case/test data on the software package and verify the results against the specification. On the other hand, testing automation relied on special software programs called test scripts for automated entry of test cases and verification of test results. However, testing automation cannot be recommended to H&K as a solution without a proper business case on the cost- benefits involved. During the informal chat after the meeting, some members made a casual remark about the ongoing cricket series involving India and how it could be a productivity dampener. Some members also whispered that on the days when Aslam left office early, offshore team members tended to relax. This was for the first time Karamath that became aware of the issues of distraction and shirking. At the end of the meeting, Karamath was more confused than before. There seemed to be several causes to explain low productivity. However, he started to wonder which one needed his immediate attention. WAY FORWARD Karamath walked back to his cabin with mixed thoughts on proceeding further. He had asked Imran Sheik, the head of the network division in their Bangalore office to provide him with network response time statistics for the first week of the corresponding period. The report had just arrived in his mailbox (Exhibit 4). The inconsistency in the network response times was evident. But was that the primary explanation for low productivity? What about the other issues such as infrastructure, coordination, communication, and discipline then? Which among these issues needed immediate attention? Would testing automation solve all the productivity problems so that he could recommend that to the customer? These questions remained unanswered and Karamath knew the nature of the challenge that lay ahead. Page 4 of 8 This document is authorized for use only by ChawSu Tun in OPMT 620 - Winter - Case study 1 taught by Farnoosh Bagheri, University Canada West from Feb 2022 to Aug 2022. For the exclusive use of C. Tun, 2022. Exceed: Improving Productivity and Reliability in Delivery of Software Solutions IIMB Exhibit 1 V-Process model for software development Requirement Specifications "Verification" User Acceptance Testing High Level Design System Testing Detail Design Integration Testing Program Specification Unit Testing Coding "Validation" Source: Compiled from https://www.tutorialspoint.com/software testing dictionary/v model.htm in May 2019 Page 5 of 8 This document is authorized for use only by ChawSu Tun in OPMT 620 - Winter - Case study 1 taught by Farnoosh Bagheri, University Canada West from Feb 2022 to Aug 2022. For the exclusive use of C. Tun, 2022. Exceed: Improving Productivity and Reliability in Delivery of Software Solutions IIMB Exhibit 2 Customer complaints tracker Serial # Complaint Category 1 Team Working Slowly 2 Too Many Errors 3 Communication Issue 4 Excess Staffing Date raised 10-Aug-16 19-Aug-16 Requirements 19-Aug-16 Requirements 24-Aug-16 Requirements Project Phase Requirements 5 Excess Staffing 26-Aug-16 Requirements 6 Too Many Errors 16-Sep-16 High-Level Design 7 Excess Staffing 22-Sep-16 High-Level Design 8 Excess Staffing 26-Sep-16 High-Level Design 9 Domain Knowledge 12-Oct-16 High-Level Design 10 Communication Issue 12-Oct-16 High-Level Design 11 Team Working Slowly 22-Oct-16 High-Level Design 12 Team Working Slowly 26-Oct-16 Detail Design 13 Team Working Slowly 28-Oct-16 Detail Design 14 Team Working Slowly 11-Nov-16 Coding & Unit Testing 15 Team Working Slowly 16-Nov-16 Coding & Unit Testing 16 Team Working Slowly 25-Nov-16 Coding & Unit Testing 17 Excess Staffing 28-Nov-16 Coding & Unit Testing 18 Team Working Slowly 16-Dec-16 Integration Testing 19 Too Many Errors 21-Dec-16 Integration Testing 20 Team Working Slowly 25-Dec-16 Integration Testing 21 Too Many Errors 29-Dec-16 Integration Testing 23 Excess Staffing 22 Team Working Slowly 24 Domain Knowledge 02-Jan-17 System Testing 05-Jan-17 System Testing 06-Jan-17 System Testing 25 Team Working Slowly 06-Jan-17 System Testing 26 Team Working Slowly 10-Jan-17 System Testing 27 Team Working Slowly 19-Jan-17 System Testing 28 Excess Staffing 23-Jan-17 System Testing 29 Communication Issue 23-Jan-17 System Testing 30 Too Many Errors 27-Jan-17 System Testing 31 Too Many Errors 31-Jan-17 System Testing 32 Too Many Errors 01-Feb-17 System Testing 33 Communication Issue 01-Feb-17 System Testing 34 Too Many Errors 02-Feb-17 System Testing 35 Team Working Slowly 03-Feb-17 System Testing 36 Too Many Errors 03-Feb-17 System Testing Source: Company Records 2 Project phase indicates the incident phase in the V process model (as explained in Exhibit 1) when the issue was raised. Page 6 of 8 This document is authorized for use only by ChawSu Tun in OPMT 620 - Winter - Case study 1 taught by Farnoosh Bagheri, University Canada West from Feb 2022 to Aug 2022. Exceed: Improving Productivity and Reliability in Delivery of Software Solutions IIMB Exhibit 3 System test case execution statistics Time 3 09-Jan-17 10-Jan-17 11-Jan-17 12-Jan-17 13-Jan-17 16-Jan-17 17-Jan-17 18-Jan-17 19-Jan-17 20-Jan-17 9:00 AM 81 82 81 74 75 81 83 86 88 82 11:00 AM 73 87 83 81 86 86 82 83 79 84 1:00 PM 85 88 76 72 83 82 76 82 86 89 3:00 PM 90 78 84 73 84 88 77 79 84 83 5:00 PM 88 83 82 83 78 81 78 85 85 80 Time 23-Jan-17 24-Jan-17 25-Jan-17 26-Jan-17 27-Jan-17 30-Jan-17 31-Jan-17 01-Feb-17 02-Feb-17 03-Feb-17 9:00 AM 86 86 88 73 84 76 74 85 82 88 11:00 AM 83 83 79 86 85 82 86 85 83 79 1:00 PM 81 78 83 81 81 84 83 82 83 92 3:00 PM 81 80 83 79 87 85 89 77 90 83 5:00 PM 87 83 82 87 81 79 83 77 84 77 This document is authorized for use only by ChawSu Tun in OPMT 620 - Winter - Case study 1 taught by Farnoosh Bagheri, University Canada West from Feb 2022 to Aug 2022. Source: Company Records 3 Time refers to the start time of a time window of 2-hour duration for the execution of system test cases For the exclusive use of C. Tun, 2022. Page 7 of 8 For the exclusive use of C. Tun, 2022. Exceed: Improving Productivity and Reliability in Delivery of Software Solutions IIMB Exhibit 4 Source: Company Records 4 Network response time metrics Response times Date Time (in milliseconds)4 09-Jan-17 09-Jan-17 09-Jan-17 09-Jan-17 9:00 AM 11:00 AM 1:00 PM 3:00 PM 222 234 214 211 09-Jan-17 5:00 PM 211 10-Jan-17 9:00 AM 221 10-Jan-17 11:00 AM 215 10-Jan-17 1:00 PM 210 10-Jan-17 3:00 PM 226 10-Jan-17 5:00 PM 218 11-Jan-17 9:00 AM 218 11-Jan-17 11:00 AM 219 11-Jan-17 1:00 PM 229 11-Jan-17 3:00 PM 218 11-Jan-17 5:00 PM 221 12-Jan-17 9:00 AM 235 12-Jan-17 11:00 AM 222 12-Jan-17 1:00 PM 236 12-Jan-17 3:00 PM 230 12-Jan-17 5:00 PM 221 13-Jan-17 9:00 AM 230 13-Jan-17 11:00 AM 215 13-Jan-17 1:00 PM 221 13-Jan-17 3:00 PM 217 13-Jan-17 5:00 PM 230 Response time is the time taken for a request and response of data packet to travel between the offshore servers of Exceed and H&K client network. It is a measure of latency in data communication between the two networks. Page 8 of 8 This document is authorized for use only by ChawSu Tun in OPMT 620 - Winter - Case study 1 taught by Farnoosh Bagheri, University Canada West from Feb 2022 to Aug 2022.