Managing Reliance in the Initial Days


 

I joined Siemens on 01Jun2005 and by beginning of Jul05, was assigned to complete the project for SmartPay integration with eServ IN apart from handling the other Telco Clients supported from Kolkata. At that point of time, the product should have been supplied and implemented. However, I found that there was no clarity of scope and no work had begun. Reliance could not really get at us as eServ delivery was also delayed. So, we clarified the scope and documented it and committed to supply the project by Dec05.

The SmartPay was a Pre-Paid Solution (which had all components including a CRM, Inventory Management, Integration with ERP, etc.) which was for CDR based Rating. We had to remove the charging part as this function would be done by the eServ IN while the remaining functions remained in SmartPay. At the outset, the job looked simple. However, that was not the case as SmartPay was a reasonably large software and could serve a Tier II Telco very efficiently. Also, SmartPay was largely written in Visual BASIC & ASP & some portions in C/C++ & some part in Java and almost nobody in the team knew much about the part of the existing code in ASP (and this was the largest chunk). As it was very difficult to alter this code, after 2 weeks of effort I decided to write the software afresh using ASP.Net keeping the C/C++ & Java components which were mainly for handling the SMSC and IVRS and some more interfaces. This was a huge risk and my boss did not approve of the same as he was not sure of a new software and he trusted SmartPay. However, in spite of not being in agreement, he did not stop me. I found that I had very competent people to alter the C/C++ & Java portions and I found Indranil, who had joined a month earlier than me, to complete the eServ IN interface with SmartPay (the ticket handling part. Later, Indranil was known as Ticket Babu in Reliance). To build the ASP.Net portion, I got support from Somenath and 2 new college recruits in the team (who joined a month later than me).

Somenath had joined Siemens a few days earlier to me. He was extremely energetic and very enthusiastic. This made up for some of his lack of skills. As all the developers were new, I took the load for developing the bulk of the software. This was tough as I had to manage the customers during the day time besides internal departments like marketing and quality assurance and others. So, I used to sit to write my part of the code in the evening from around 5PM and carry on till 12 midnight or later. Somenath used to always keep me company, no matter how late it got.

We completed the software by Dec05 and decided to call it INIS for IN Integrated SmartPay. Then, my boss told me that we should leverage the SmartPay brand name and thus stick to the same. We started the deployment knowing very well that there were a number of flaws. However, my conscience was clear that I knew where the problems were and we would fix all of that in the due course of time. Till we were able to fix the problems, we would give unconditional support in running the software. This was to advantage of Reliance as well as they could launch new services and products. As was expected, once the software went live, problems started to surface and Reliance spared no opportunity in abusing us. However, they also did not throw us out. Sandip was our primary front end for the support and I positioned Somenath to be the primary help for Sandip. This was because Somenath knew how to handle the Front-end systems newly written in ASP.Net and also because he had an enormous amount of energy and commitment. He would rush to Reliance at any hour of the day or night when there was any issue. Also, he carried a Reliance phone, with which he would routinely check the system (whether he was brushing his teeth in the morning or during any other time of the day).

Now, when a problem surfaced, which was almost every day, I would meet the team and we would work out solution strategy and get to work on the same. We supplied routine updates as all testing was done in our labs as Reliance did not have a test bed. Now, Somenath would be part of our discussions and heard all that we discussed. As he would spend so many hours in Reliance Office, Reliance Managers got in talks with him to know what was fixed and when it would be deployed, etc. In his innocence and in his enthusiasm, Somenath would blurt out all the truth about what we would have discussed in the office including how much was a patch work and how much was a long-term solution. The Reliance Managers found this very interesting and started to get back to me with even greater vengeance. This was becoming a real challenge to manage. There were severe escalation and it was getting more and more difficult to manage our Management, especially the Marketing & Sales unit (Reliance was the largest account for Siemens Telecom Division in India).

So, I struck a strategy. I created assignments at the Reliance site and assigned them to Somenath so that he would be there for most part of the day. In that time, I would convene the rest of the team and work out solution strategies which we would develop. Somenath would come back to our office after all Reliance staff had left their office in the evening. By this time, most of our team members would have also left the office. So, there would be Somenath and I in the office. I used to seat Somenath in my workstation and tell him half-truths about what we would have developed to solve the immediate issues. And as per my calculations, next day Somenath would go and blurt out that much in Reliance. Within a week or two, I found the aggressiveness of Reliance Managers reducing and this was most comfortable for me as now we had more time to work out proper solutions.

Till Mar06, we kept vigil of the system for 24 hours a day with us taking turns to spend the nights in Reliance. Around end of Mar06, the system was sort of stable and we were more in the office working on future releases. Reliance always called our system “Kachra System” (Junk System). However, they never threw it away and the system took them from handling 3 million subscribers to 12 million subscribers. From Apr06 till Dec09, there was not a single escalation to even my boss from Reliance. This apart, we got orders for many change requests between 2006 to 2009 and they continued to be the biggest source of earning for us. When ultimately, Reliance Telecom merged with Reliance Communications and all systems & people were moved to Mumbai and our system was scrapped, we were definitely sad. However, we also had the satisfaction that what we had developed had served its purpose and definitely it had earned many times more than what it cost.

 

Advertisements

Comments

  1. Yes Praveen. This was true for the IVRS and USSD. The remaining components were on UNIX. The main component of eServ to SmartPay connection was on a huge Solaris Box. Later, we made it redundant by adding one extra box.

  2. Praveen Gaur says:

    I think the biggest problem with the project was that it was not on Unix. Socket connections were really unreliable for quiet a long time.

  3. It was fact that every new product deployment in Reliance was met with severe issues in the initial days of the implementation. However, this needs considering in the context of Reliance from the software delivery unit’s point of view.

    The fact was Reliance used to manage 8 Circles of Operation across a large part of North India and East India using this one installation. Each Circle is an individual PLMN. For this, Reliance did not have a test bed at their site. Whatever our software delivery unit produced was tested entirely using simulators at our labs and then directly deployed in the production environment of Reliance. The UAT was conducted by Reliance with live customers using the fresh deployment. Some of the critical deployments were controlled as they would be only exposed to internal staff for a period of time prior to being exposed to the complete customer base.

    When an operator has such a set up, they have in any case calculated the risk involved. I justified this strategy of Reliance as they would have definitely calculated that the cost of this risk and found that it was less than the cost of setting up the needed additional infrastructure.

  4. Hello!!!

    In my opinion, a project is not successful if it does not meet the reliability factor among others.

    Speaking in the context of this particular project, the success factor was how long the product would survive for the purpose it was built for. This is because the revenue generated by the project execution was just about 2% of the total revenue generated by the installation of the solution through the license fees charged to the customer and from the annual maintenance contract. The AMC would be about 1% of the license fees (considering 1 year AMC. Considering that the system supported from 3 million to 12 million, we received license fees for 9 million additional licenses. AMC over 4 year for this license fees was 1% of the net license fees received).

    However, delivering the product on agreed timelines was equally vital as otherwise there be a bigger impact on the Customer in terms of loss of opportunity.

    The next enquiry could be regarding whether it was wise to risk the total redevelopment knowing the risk of overshooting the schedule. The fact was that if we decided to modify the existing ASP code, my judgement was that time required would be equal or more time (as anyway expertise did not exist and also the tool was more cumbersome to develop with compared to ASP.Net). Also, even if we developed on the ASP, it was a horrendous task to extend the solution beyond that point. Our main earning from the software for the Delivery Unit was from the change requests as the license fees is the earning of the Marketing Department.

    So, in this context, delivering a solution which was known to be less reliable at the point of time of delivery, was still prudent as long as we were sincere that we would improve the reliability within a reasonable period of time. In my evaluation, this was the best solution in that situation for the Customer and for our organisation.

    I could say, it worked that way as well, as definitely the Customer earned huge revenue from the different products and services launched (which is evident as the customer base grew more than 300%). Also, we used to earn an EBIT of around 45% from the different changes and new additions for the solution and the earning from the license was a total bonus.

Request you to kindly leave a reply.

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: