QA Management – Experiences of Partha Majumdar

Very early in my working life, I was taught that the most important aspect to be able to work effectively is to be able to treat everybody as a customer. My mentor taught me that every colleague I worked with was as important a customer as was any user of the organisation’s services. I have found this advice very useful as this has taught me to respect everybody that I meet. Also, I have realised over time that every person has something which I can gain from and I needed extending certain minimum courtesy to every person that I met. I was taught the power of the word “Please” and the word “Request”. The instructions were clear, “Never ‘ASK’ for anything. Nobody is born to give me what I needed. If I needed something, I needed REQUESTing for the same. It was the discretion of the other person whether he/she would extend the favour or not”. After over 40 years of life, I have found this lesson most useful and have even extended its use when dealing with my family members.

My UNIX instructor taught me that we needed to frame our working style on the way UNIX worked. Every request should be given importance and service should be rendered simultaneously in a way that every customer felt that he/she was the only one being served. We need exercising prioritisation like the UNIX server to be able to attach more or less priority to the requests and this should be driven by the Customers, not by me.

So, it is my natural practice to find the stakeholders of any work that I am involved in. I realised that while we considered IT Development as a customer as we had to test what they developed, we never considered IT Operations as our customer. Could this have been the reason IT Operations complained so vehemently about IT QA when anything did not work?

There was another team to take care of i.e. IT Transformation Track. IT Transformation Track was responsible for the introduction of the new products in the solution stack and for the re-engineering of some of the existing products. IT Transformation Track mainly dealt with vendors. However, they needed to also work through the developers from the IT Development to integrate the solutions to the existing stack. However, they received less priority from IT Development as Business As Usual (BAU) always had higher priority.

So, it was established that the team mainly needed providing services to three departments – IT Development, IT Operations and IT Transformation. We had our team aligned to the IT Development. Though we theoretically had a team assigned for Transformation Projects, the team treated IT Development as the customer as the developer were all from IT Development. And we had no team aligned to the IT Operations.

My first action was to create a business case for setting up a team to exclusively test for all production fixes and enhancement projects. Enhancement projects were initiatives taken up by IT Development for solving problems identified by IT Operations and for other improvements identified by IT Development. It was a case I had tried selling unsuccessfully when I was the Development Manager in MIT (Mobily Infotech India Private Limited). This time I succeeded. We set up a 4 member exclusively for testing for production fixes and enhancement projects. The mandate for the team was that they would complete testing for a task with an average speed of half man day; and the team would test up to 100 tasks per month within 3 months. The primary customer for this team would be IT Operations. So, now IT Operations had an exclusive part of IT QA aligned to serve them. During the year 2012, this team took on enormous amount of load and served far above their capacity. The best aspect of this team was that it was completely hosted in MIT and worked completely remotely from Bangalore.

We assigned the task of Regression Testing exclusively to MIT. Venkojee, Maniram and Mohan set up a wonderful team who conducted regression on every day of the week for different parts of the solution stack. With just 4 members, this was the most hard-working and most accommodating team which received the least amount of attention. But then, we all just did our work and we did not work for any appreciation. Our appreciation was in the smiles created on the lips of our customers. This team also provided a very vital service for Invoice Quality Testing prior to every monthly bill cycle.

Transformation Team from IT QA was aligned to the IT Transformation Track. We beefed up this team with contractors from Maverick. We got some wonderful team members from Prime Point and Maverick whose dedication just amazed me. This team needed working on new aspects like Subex Fraud Management System, Comptel Online Charging Gateway, Oracle Order Management System, EAI Transformation and many more projects.

We set up a small SQA organisation under Naeem to gradually introduce Quality Assurance practices. The task of this team was the most difficult as processes were the last thing on anyone’s mind in Mobily. We are all about speed. We modelled this team to set up processes exclusively for gathering important facts to analyse. I calculated that I would need 2012 to gather statistics to prove the importance of processes. Using the statistics, I decided creating business case for further enhancement of this team. However, my work was made easier when I learnt that IT QA would be outsourced to IBM. IBM would bring in their processes which would be more mature than any process I could dream of introducing. IBM would, however, need all the data from us for understanding the history so that they could come up with a pragmatic plan.

For the Business As Usual, the rest of the IT QA team was aligned to the different segments – Consumer, Corporate and e-Business (The e-Business team also took care of Sales, Finance and Customer Care projects). This team’s primary customer was IT Development.

There were some more customers. They were the Corporate Audit Team, Risk Management Team, Purchase and Contracts Team, Human Resources Team, Strategy Team and (of course) the Senior Management. As I had no other part of the IT QA organisation left, I decided to handle these customers.

So, everyone in the team had their focus set. Each of us knew whom to attend to. Our only motto was the success of the IT QA as a department and thus did not need competing with each other. However, I set KPIs which set about competition among the teams. Our competing KPIs were number of escalation against the teams, number of appreciations for the team, number of knowledge sessions held and number of certifications attained by the teams. Each team offered support to the other teams when they needed any kind of support. All of these were voluntary and I never needed any lengthy negotiation.

My major task throughout the year was to congratulate the different teams for the appreciations received from their respective customers and from across the organisation. There were negligible number of escalation during the year and on each occasion I was able to prove that IT QA was not at fault. Every team member was eager to share their knowledge with the rest of the team. In fact, some members were very upset with me when I made the knowledge sessions voluntary to attend and voluntary to offer. It was proof for me that the process was now ingrained in the blood and would never fail. Many team members took to extended education.