{audio:0:00:01} Kamesh, can you share a short introduction of your background, in the industry, over the last 20 years?

{audio:0:00:09} Over the last 20 years, I have held leadership roles across a handful of companies. I was the vice president of professional services and support at Firepond.  I was the vice president of worldwide applications services at Unisys. I then moved on to EPAM, to help their worldwide application managed services. Currently, I’m the digital general manager at DXC.

{audio:0:01:01} Can we take a step back to the early 2000s, when you were at Unisys. What did a typical managed service project look like, back then?

{audio:0:01:13} Managed services, by definition, are when the technology services provider is willing to put skin in the game and is willing to share the risk with the client. I identified the risks and the client and the service provider agreed to enter into an agreement to split and share the risk; this can vary from contract to contract and that’s when we enter into managed services. In managed services, typically, you have a few different flavors, when it comes to support and maintenance of either applications or infrastructure. That’s one kind of managed service. The other type is referred to as fixed bid development of very large custom application development initiatives.

{audio:0:02:20} The one thing that is clear is, when it comes to support and maintenance of a portfolio of applications or infrastructure, that hasn’t evolved much, but it has evolved in the right direction, as evolution happens. One area that has drastically changed is when it comes to these really large, fixed bid developments, where you take the risk up front and submit a fixed bid and do a custom development project. I think the industry has come to a realization that we still do not have the right tools, methodologies and technologies to do a fixed bid for a ground up development. What has happened is, from waterfall it has gone to agile. Overall, I see less and less very large fixed bid development coming on, which is very good, otherwise the relationships tend to suffer very early on in the engagement cycle. That has moved in the right direction.

{audio:0:03:34} Those fixed bid contracts are just too risky for the provider, in that you have to predict the time, the duration, the materials and labor required to fill the project?

{audio:0:03:46} Right. There are so many unknowns at the early stages of a project, when the bid is proposed. Everyone has a set of assumptions and they all hire the best project managers to manage the gig and there is a constant discussion of change. Is this in scope? Is this out of scope? The relationship tends to suffer very early on and I see less and less of that happening. I think the clients have come to a realization that it is not the right thing. We are seeing more collaborative bids and agile development where, typically, you don’t put a big estimate up front, on the table. This is a good evolution.

{audio:0:04:28} Has that changed the nature of the customer relationship?

{audio:0:04:32} Significantly. The minute you get into these very controversial discussions – this was not in scope; let me pull up my 100-page document and I can show you, on page 23, paragraph 3, look at this – the relationship is never going to be good. I believe, when that is not there and when both parties are not trying to find faults with the other, then the relationship is much better.

{audio:0:05:07} Arguably, this shift to a more maintenance or recurring revenue, plus agile development, is stickier for the providers, with clients?

{audio:0:05:18} Absolutely. It is stickier for the provider; the relationship is much better and the benefit is mutual. In some of the earlier fixed bids I have personally seen, when the providers have lost their shirts and pants, ultimately, both of them are in a business engagement and we have to create a win/win and to make sure that both are profitable. When that doesn’t happen, it’s never good. Now I love what I am seeing on that front.

{audio:0:05:50} How different is the relationship today, in a cloud environment, versus those old, on-prem, mainframe days?

{audio:0:06:04} In the on-prem, mainframe days, along with these very large bids, we would also say, hey, to do this multi-million-dollar fixed bid development, here is the hardware that you need to invest in. That’s the first thing that providers focused on. Typically, that’s not the capacity you need for day one, but that is the projected future capacity that the provider feels that the client will grow into, in the next two to three years and they would give that as the estimate. By definition, any time an estimate is given, you make sure that there is enough capacity to grow. That means that the client is not paying for what they need today; they are paying for the future capacity. That is not good.

{audio:0:07:01} Today, what the cloud has offered as a model is, pay for what you use; pay as you go. You don’t have to pay for the future capacity. What you use today, for this transaction, on Monday morning, July 1st, just pay for that. It has given us that level of flexibility. The second factor is that the whole capex model has shifted to an opex model. Capital funding is up front; I have to invest in, let’s say, $5 million of hardware fees and then I amortize it for a period of time and I have to carry it in my books. Right now, I don’t have to invest in that; I don’t have to invest in software. I can work with the provider and say, hey, I have to have my claims processed; I’m in property insurance or, I’m in healthcare payor insurance and I’m going to pay you so many cents for every claim you process.

{audio:0:08:13} Look at the flexibility in the model that has evolved. No more capex; it is all opex. You don’t have to estimate your future capacity. There is also no question of, did I estimate incorrectly, or if you are able to get the hardware resources on demand, and that elasticity is built in the cloud. I think what we are seeing today is just awesome.

{audio:0:08:47} The other thing I would add is that, because of all this flexibility, I see companies spending more on their IT. Because they are spending more, I think they are embracing the digital transformation journey in a much bigger and faster way, due to these enabling technologies. If the cloud was not there as an enabler, I think the adoption and advancement of some of the technologies would have been far slower.

{audio:0:09:28} As you said before, in the mainframe days, the provider would almost price a contract where the client would grow into the capacity. This means that the client is paying for capacity that they are not using today. Whereas in the cloud environment, they might be paying less up front, in the early days, but because it’s recurring revenue or it’s pay as you go, that would grow in line with the supply and demand? It’s almost like the on-prem to SaaS pricing shift, where the accounting may mean that you earn less revenue up front but, in the long run, it’s a better model for the provider?

{audio:0:10:17} In the longer run, it is a better model for both the provider and the client. Firstly, you’re not stuck with the specific platform; you’re not stuck with the specific technology. You haven’t had to invest in all of that in your on-prem environment. It helps the client to embrace a newer platform. They are not bound to this platform for the next five years, because they have had to invest so much and that is the time it takes for them to break even. I believe that this cloud model is better for both the provider and the client.

{audio:0:11:04} Focusing specifically on cloud, what’s your view on the potential future of multi-cloud or public versus hybrid? How do you think this is going to shake out and how do you look at the consultants and their positioning, in different environments, like public versus hybrid versus multi?

{audio:0:11:30} In the short term, I feel it will continue to be hybrid. But in the long run, it will go more towards a public cloud. In companies like Amazon and Microsoft, the rate at which they are pumping into these technologies, which they have clearly recognized as game changers, is significant. I would say, in the short to medium term, it’s going to be hybrid; in the long term, I personally feel, it is going to be public.

{audio:0:12:16} The taint on the public cloud is the perception of security. It is nothing more than a perception, at this point in time. The very fact of prefixing cloud with the word public, it is out there, in the open. There is a perception that it is not as secure as if it is within your own four walls. But l believe that the perception is going to be short-lived and people are going to realize the benefits of it.

{audio:0:12:53} Do you think there will be one public cloud, for most companies, or do you think it will be multi-cloud?

{audio:0:13:00} My personal feeling is that it will be one per company. To have the right level of expertise, within your company, even to manage some of these discussions. If you have both Azure and AWS on your premises, then you need to have two teams on cloud work; one on Azure and one on AWS. Consciously, they say, I’m not going to get into a vendor lockdown situation; I’m going to have both Azure and AWS. But everywhere you go and you look under the hood, you will see that, if it is an Amazon shop, the primary cloud provider would be Amazon and Microsoft Azure will be in a very small corner, with one or two applications in that cloud.

{audio:0:14:02} Personally, I feel they will have one or two in their landscape, but they are going to pump all their energy and their strategic business sensitive applications onto one cloud.

{audio:0:14:19} This is mainly to reduce the complexity of the infrastructure?

{audio:0:14:27} How does a mainly single cloud environment position the consultancies, versus a multi-cloud environment? For example, would you suggest that the consultancies are better positioned in single cloud or multi-cloud?

{audio:0:14:57} For the consultancy, it’s a different thing. They need to have competencies in multi-cloud. As an example, companies like EPAM and Cognizant, should have skill set competencies, capable for these accelerators. As an example, let’s consider the two major players, Amazon and Azure. I need to have capabilities on both. Maybe one of my clients is an Amazon shop and one of my clients is a Microsoft shop; we see that over and over again.

{audio:0:15:31} From a client perspective, I think I seen an alignment more with one cloud but, as a service provider, it doesn’t make any sense for a typical systems integrator to focus on one. They are going to have competencies and capabilities across both.

{audio:0:15:52} In a multi-cloud environment, it would seem as if the providers would be more valuable to the clients than a single cloud provider?

{audio:0:16:05} I’m not sure that would be the case. Let’s take a use case. If a client has AWS and Azure in their landscape and, as a Cognizant or EPAM, am I going to be more valuable if I have competencies in both versus just one? Actually, the more I think about it, you’re absolutely right. They can work with one larger site. The more I think about that use case, you have a point.

{audio:0:16:46} I guess, that’s down to the complexity of stitching the infrastructure together with multiple clouds? Surely, for the likes of EPAM or Cognizant, if they have deep expertise in both AWS, Azure or GCP, they can be more valuable to the client?

{audio:0:17:07} Absolutely. I agree; good point.

{audio:0:17:11} Can we just walk through a typical project today? Let’s say that I am a US bank, for example, looking to move to the cloud and build some new applications or move my old applications to the cloud. What is the process?

{audio:0:17:34} Let’s put it into two buckets of activities. One is the bid process and the sales cycle. The second is, the contract is signed and then you get into the delivery phase.

{audio:0:17:57} When it comes to the bid process, typically, the client is going to engage their procurement. The business/IT will engage with their own procurement with the requirements of the bid and procurement will manage the bid. All these very large clients and IT shops have their preferred vendors. They would say, I’m going to circulate this RFQ, with these five providers. They distribute the RFQ, the response is populated by the providers and is submitted back to the clients. The clients shortlist call them for a client discussion. Based on various factors, including the quality of the solution and the price, the client picks the winner. Then you go through the contract inking process.

{audio:0:18:57} What do I care about, at that point? When I’m choosing between EPAM, Cognizant, Infosys or most of the big players, what is my decision-making process, if I’m the bank?

{audio:0:19:11} While there can be specific criteria for each and every RFQ, there are two or three that play a significant role in determining the result. The most important one is the quality of the proposal, the quality of the solution. The second is an extension of that. These days, clients check for references; they call the references. For every single RFQ, the clients ask for references and the providers give them the references. I go through my reference checking and I also determine, not just from the sales cycle, have they delivered, end to end, a very similar implementation, on other client sites? I want to make sure. The third thing, obviously, is the price point. There is a significant variation in the price point. It’s not that I ask for something and it always comes in with a 3% variation, which would mean that price is no longer a factor. I think that price is a significant factor, which determines what kind of a mature, hub and spoke delivery model that each one of the service providers has.

{audio:0:20:39} While there may be some very specific cases, if you peel the layers of the onion and look at all the underlying factors, you can see that what the clients look for are these three things; The quality of the solution, the quality of the reference checks and the price point.

{audio:0:20:58} In terms of the quality of the solution, is it a prototype or a plan? What do you need to provide to the client?

{audio:0:21:07} It can be all of the above or one of the above, as part of the sales cycle. Maybe they would say, as part of the client discussion, come and demonstrate a prototype. But for example, my RFQ could be, I have 1,000 applications, as part of my legacy IT. I want you, the provider, to take over these 1,000 applications, do a support and maintenance for them and, in this case, a prototype may not make sense. When I talk about the quality of solution, it’s a multi-year deal, a three-year deal, what is my approach? How do I start automation? How do I increase automation in year two? How am I passing on the benefits of these automations to my clients? Can I show them the price point difference? In year one, let’s say it’s $10 million; in year two, it is $9 million and in year three, because we will have made so much progress on all these fronts, and automation is going to increase so significantly, it is going to be $6 million.

{audio:0:22:24} That’s another example of the quality of the solution. How am I bringing in automation? What is my mind share? It depends on a case by case basis, but some of the examples you gave, such as a prototype, are also very relevant.

{audio:0:22:42} How do different companies approach that proposal part of the bid, in your experience?

{audio:0:22:51} Sometimes, the procurement is able to handle this. In many, many cases I have seen that the procurement does not have the skill set to handle a very specific proposal. They will hire a third-party consultancy organization, just to manage the proposal process. They would ensure that they don’t have the opportunity to bid for it. For example, Cognizant, as an example, would be brought in, to manage the entire proposal process. But because they manage the proposal process, they would say, we can’t let you bid.

{audio:0:23:41} So it’s a combination. In some cases, the procurement and the business expertise are very strong and they have sufficient bandwidth. Procurement is very labor intensive as you need to pull together the RFP itself, bring in the responses and evaluate. As long as they have the right skill set available, they would be able to manage it. Otherwise, they would choose to have a consultancy come in, just for that process.

{audio:0:24:09} I guess my question was more around, do the pure play consultancies have an advantage in bidding for this more cloud-focused infrastructure work, because they have more expertise and they can provide a better proposal, up front, regardless of the price? I imagine they are both intrinsically linked, in terms of the fact that a better proposal probably links to a better price, to a certain extent. Do you find that EPAM or Cognizant or even the old, traditional consultancies, approach this phase any differently or have an advantage in any way, to provide the best proposal?

{audio:0:24:48} Excellent question. Companies, like Accenture and Cognizant, are full stack. When I say full stack, I mean that they have the upstream consultancy, backed by the downstream delivery infrastructure capabilities, as well. In some cases, looking at PwC, they are very strong in consulting, but they don’t have the delivery capabilities. In many cases, if it is PwC led, they would try to partner with someone who brings the delivery capabilities to the table. That’s one factor.

{audio:0:25:35} Secondly, if you take a look at Accenture, they started with consulting. Their DNA and genes is consulting. Over a period of time, they built their delivery capabilities. Whereas if you take a look at Cognizant, they started with the delivery capabilities and, over a period of time, they acquired and built up their consulting services. Even if you just take these three companies, PwC, Accenture and Cognizant, they all bring in varied flavors and all have their pros and cons. But what is really required, from my viewpoint, is going to be a complete stack. Pure play consulting is not going to be enough and, in which case, you can only bid for part of the proposal – unless it is a very defined, solely consulting gig – and then you will have to bring in a delivery partner.

{audio:0:26:35} I would recommend that players who have this instrument, are going to be the ones who would be able to do well, sustainably, moving forward.

{audio:0:26:47} So full stack is key to providing the best solution?

{audio:0:26:53} How about the relatively smaller players, the pure play consultancies, like EPAM?

{audio:0:27:02} EPAM is small but they have carved a niche for themselves. Their primary focus is, consciously, digital transformation services, which is all around cloud and mobile and those kind of technologies. They have made a very conscious bid not to get into any kind of legacy, mainframe rewriting. They have carved a niche for themselves and then they grew at 30% in that niche, year over year, for the last 15 years. Today, it has become a size that can stand, head on, with the Accentures and Cognizants of the world and they have made a mark for themselves.

{audio:0:27:56} When it comes to the overall stack, EPAM has also done well in bridging their gaps. They started off with pure play, as an engineering company. EPAM’s DNA and genes is not in consultancy, but in high powered, complex engineering jobs. If you want to write a complex trading platform, to the tune of nanoseconds per transaction, then EPAM know how to write and execute that code. That’s how they created they niche and they have expanded in that and built a very full consultancy service.

{audio:0:28:45} Do you think it is easier for Accenture to transform from consulting to delivery, or for Cognizant from delivery to consulting?

{audio:0:28:58} Given that I haven’t worked for Accenture but I have worked for Cognizant, I’m a bit biased. I believe it is easier to acquire delivery than building consultancy. Cognizant has struggled to build a consulting leg on top of their delivery stack. They have made several acquisitions and struggled with getting them integrated. I would say the toughest skill set to acquire is the consultancy skill set. If you have that in place, then your technical stack and delivery skill set falls into place much more easily than the other way around.

{audio:0:29:45} Is that just a culture difference?

{audio:0:29:50} It’s a skill set difference. It’s the client-facing skill set that is a big difference. Delivery, by definition, is to me, a very back office kind of a thing. You have some client-facing folks and you have a lot of people in call centers and development centers and so on and so forth. The client-facing becomes a premium and that is not the skill set where you can go on a one-month Java class and acquire Java. You can’t go on a one-month class on how to handle your client better, unless you go through it and get your battle scars. It’s more time-consuming than acquiring the technology skill set, that’s my view.

{audio:0:30:37} If we go back to the process then. You sent out an RFQ, receive some proposals, and now I’m making my decision based on, as you said, quality of proposal, the reputation and references and the price. What is that sales process?

{audio:0:30:58} These days, salesforce.com has done a phenomenal job. If you move from EPAM to Cognizant to Accenture, the common thread that ties these three together, as an example, is salesforce.com, which is your sales cycle management tool. Obviously, each and every company has the option to customize it. But this process has been so institutionalized; it is a six-page sales cycle. Stage one, know your customer. Stage two, propose the solution. This tool has helped to institutionalize it, across the board. It’s a very standard sales process. Typically, it goes anywhere from six to nine stages. Are you at a point of proposing the solution? Are you still understanding the problem statement? Are you very early on in a conversation with a client?

{audio:0:32:22} Right now, the rigor and discipline which all organizations are beginning or wanting to create is, it doesn’t matter what happens. Even if you have accommodation, can you can bring it as an opportunity in salesforce.com. You start cracking the wall, over a period of time. When you submit a proposal, you change to the next sales stage, then there is a pricing that goes on. Then the final stage is negotiating and closing. It’s a very defined, structured sales process.

{audio:0:32:58} Let’s talk about the contract structure then. Taking a step back and looking at these fixed bid contracts, in the mainframe days, how were they structured, versus typical projects today?

{audio:0:33:19} In the contract, you take out all the frills. In any contract, you have only three or four sections, if you simplify it. Typically, the contract says what the problem is, what the solution is, how the solution is going to be delivered, what the cost for the solution is, what the duration of the solution is and what the governance structure is.

{audio:0:33:58} We can leave governance aside, where we talk about sending a weekly or monthly status report, or sending something quarterly. So taking the governance out, in the end, you come down to these five sections, whether it is mainframe or cloud, that haven’t really changed. I would say, 20 years ago, I could take an SOW and could very well use it as a template, even today, because you have these five sections and it fits in very well.

{audio:0:34:31} The big difference is, yes, today, it’s no longer waterfall, where I would have said, by this date, I would have come and got my requirements signed and by this date, I would come and get the design signed. Now we talk about sprints. Each sprint is going to be two weeks and, for that sprint, I’m going to deliver five use case points on each sprint. Some of the inner constructs change, but the major sections of the contract, they have remained the same. I have not seen a significant shift in that area.

{audio:0:35:09} Is the pricing still set on time and materials?

{audio:0:35:15} There are two kinds of pricing. One is time and material; the other is any other form. I had this conversation with someone and they said, these analysts have confused the hell out of us. You go to an analyst, like Gartner and so on and you Google and you look at the number of engagement model types that they create. There are a dozen and they have really confused the space. In reality, there are only two kinds. One is, is the provider sharing the risk with you? If they are not sharing the risk with you, it is time and material; that’s it. If you want Amazon skilled people, I will give you five Amazon skilled people, the best ones; let me know if you are not happy with the people and I will change them.

{audio:0:36:13} The second kind of contract is when the provider is willing to share the risk. These are the only two models available. Over a period of time, the second model has evolved into different areas. They fix the capacity monthly; they fix the payment. How do you assess your risk? What kind of payment do we use? If you succeed in your risk, do I pay you extra? There are all these different flavors but, at a very high level, it is time and material when the risk is not shared and, when the risk is shared, it is a deliverable based engagement model. Typically, it is not based on the number of hours they spend in a month, but more like, this month, I am going to give you these five deliverables and, once I make the deliverables, I can invoice the client for payment. At a very high level, these are the only two, with slight variations, given the specificity of the client and the engagement.

{audio:0:37:22} You are seeing the clients preferring the second, shared risk model?

{audio:0:37:27} The shared risk model is always good for both. Yes, the client prefers that, absolutely. Having said that, for a shared risk model, the client has to invest a lot. The reason I am saying this is because, in my last job, with some of the very largest clients, where we got more than $100 million from a specific client, they were very mature, when it comes to outsourcing. Their outsourcing budget is over half a billion dollars. If you were to look at the portfolio, you would see 60% or 70% are time and material contracts. Time and material gives dividends, on day one, to both. If all I want is, hey, I’m going to do this; I need an additional .NET developers who I don’t have. I can ask my partner for two .NET developers to start from tomorrow. I can do a simple contract, get it over with and manage this internally.

{audio:0:38:49} If I had to go into a shared risk model, I have to understand the scope, I have to figure out what the risks are. It takes so much upfront preparation for the client that they don’t have the bandwidth for. So it’s true; while they prefer the shared risk model, in reality, you go to each of the clients, open up the hoods and take a look at their contracts. You will be surprised to see that 70% of them are staff augmentation.

{audio:0:39:21} To me, one of the best things that has happened in this industry, is the invention of the time and material staff augmentation model. It is so cool; on day one, it gives returns to both the parties. But if they have the right preparatory time and the right information upfront, the shared risk model is the right model to go with.

{audio:0:39:49} Would you say that most of the new cloud transformation or architecture projects, at the likes of EPAM, versus the older mainframe ones, are more shared risk models?

{audio:0:40:07} Which also, potentially, leads to high margin?

{audio:0:40:10} Absolutely. That is a huge benefit for the service provider. Now, they are willing to take the risk because they have done it multiple times and they know how to mitigate the risks. For companies who do it for the first time, they need to learn by the risk, the cost of the risk. It’s going to eat the margin away because you haven’t used the right mitigation factors and your margin is going to come down. You’re absolutely right; if someone knows what they are doing, then the shared risk model is the right one. Fixed bid, based on deliverables, is the right thing and it can really benefit someone who knows what they are doing.

{audio:0:40:54} How did the duration of the contracts change, as we shifted from mainframe to cloud?

{audio:0:41:03} During my Unisys days, five and seven year contracts were reasonably common; you signed a five year or seven-year deal. In the last two, three, four, five years, the maximum I have seen is three years. Even in the three-year deal, these large clients have an out clause at the end of two years. Clearly, people are beginning to realize that a viable technology is not going to last for five or seven years. At best, it will last for three years. I think that there is a level of recognition on that front and it is getting reflected in the contracts.

{audio:0:42:08} So we’re seeing shorter duration contracts, which actually increases the renewal risk for the providers?

{audio:0:42:14} Absolutely; because any time the renewal risk comes in, the incumbent, by definition, is under pressure. The incumbent is always under pressure. There are going to be 10 things that they are going to point out. You promised so much innovation; you promised so much automation. The incumbent is going to be under pressure. I would say, in any renewal contract, the incumbent is the underdog.

{audio:0:42:44} The client pushes for a big discount, I assume?

{audio:0:42:51} Have you seen that change, as we shift to cloud, where running the applications is probably much cheaper and, therefore, clients are pushing for much higher discounts, much shorter contracts?

{audio:0:43:06} In the cloud, the overall situation in contracting has become less complex and more simple. The negotiations are becoming less taxing on both sides. There is a level of transparency that the cloud brings, by definition. What does the hardware use? What do the cycles use? How many of them are used? There is no black box. Whereas, in the on-prem, there is so much black boxing. In many cases, even the provider didn’t know exactly what was happening. The transparency has helped significantly.

{audio:0:43:55} How would you explain how the stickiness of customer relationships has changed, from mainframe days to cloud, today?

{audio:0:44:09} There was a time when you kept up your commitment to the contract. You delivered what you promised and you could walk high, with your chin up and be assured that the renewal would come your way. Today, that has changed significantly. To me, the one and only thing that is going to keep the providers and the clients together, is the amount of innovation that the provider brings to the table. Nothing else. Delivering to the contract is a given, but that has become so accepted and expected, that that is never a criteria when it comes to contract renewal.

{audio:0:45:12} What is going to be a criteria for contract renewal is, how much innovation did I bring in? How much was I able to cannibalize my own footprint, for the sake of the customer? I’ll give you a very interesting example. Some years back, we were with a client who had a three-year support and maintenance agreement, with a portfolio of over 1,200 applications. Then there was a breakthrough in the level of automation that we could achieve and we realized, in the 18th month of the contract, that if we were bid for this, this is how we would have bid and we would have done all this increased automation and it would have saved the client so much more.

{audio:0:46:09} There were two options here. One option is that you sit and wait saying, we have another 16 months left on the contract; why would I go and tell this to the client. The second option is, saying to the client, we have found a better and smarter way to solution it and we are going to redo this contract and it’s going to cost you so much less burn every month. Trust me, when you know about something, there are five other sides, at the same time, who know about it, who are most likely in the same premises as your competition and they will be having that conversation with the CIO the next day. I think that is a significant thing that has changed.

{audio:0:47:01} Innovation linked to cannibalization are two big things that are going to determine the stickiness with the clients, moving forward.

{audio:0:47:11} Can we talk about how, specifically, the contracts are priced? Let’s say, I’m a US bank, shifting to the cloud, with a portfolio of applications. How do you, as a provider, such as EPAM or Accenture, look at pricing? If we are on the shared risk model, versus time and material, how do you look at pricing that contract?

{audio:0:47:37} Pricing is more an art than a science. One pricing approach is, typically, in this very specific example, I would ask the following questions. For all these applications, what is your ticket volume, per month, by application? I will know which applications require more support which, by definition, tells me which is a better return. Some will not return because, in certain areas, it is very error prone. I will ask a lot of these questions. How long has it taken, on average, to fix some of these issues? I will do a lot of this analysis and will do a bottom up pricing. That is one very common way to do pricing.

{audio:0:48:44} The other approach is that you use heuristic modelling and do a top down approach. Typically, when you do a bottom up and top down approach, and you give it to two different teams – and we have done this exercise – and let’s assume it’s 1,000 applications and the support contract for year could be $20 million. For a three-year period, it’s a $60 million contract. What they would do is, they would call two teams, internally. One would do a top down pricing and the other would do a bottom up pricing and then they would bring both teams pricing approaches together. They would make sure that these two teams don’t communicate too much with each other, to share the details. Then they would normalize these two approaches and find some median approach. There is always going to be ground level intelligence, which is important, where they will say, what is the price to win? Your sales guy is going to come back and say, guys, it doesn’t matter whether you do top down or bottom up, we know this is the price to win, which is a very important data factor.

{audio:0:50:01} So you use these three approaches, the top down, bottom up and the price to win and the service provider would bid for that. In many cases, this would seem ridiculous, but it is almost like throwing a dice. It depends on the year end, quarter end, how hungry you are for deals and what is your bench strength and are you willing to take this risk? We will take this risk and we will invest in the first three, six months to bring things under control. All these are typical discussions that happen in the boardroom, in the leadership room, about these bids, when they go out, before the deal is submitted.

{audio:0:50:49} Would you not have a target gross margin or operating margin, for a project?

{audio:0:50:55} Yes; typically, it is 40% to 50% and, in many cases, they would drop it. How much they drop it will vary case to case. Sometimes they drop it to 10% or 15%, depending on how strategic it is. Is it in a place that I want to grow and this is my first implementation of, let’s say, Velocity, and I’m going to learn how to implement it this year, so I’m willing to break even? Factors like that come into play. But typically, in a good, healthy services margin, it is 40% to 50% and I have seen many cases where they don’t drop below 30%, in a very regular environment. But it varies, case by case.

{audio:0:51:48} If you’re sharing the risk there, you have to have a good handle on the delivery model, the cost of labor and the utilization of the labor, to deliver that margin?

{audio:0:52:01} Absolutely. They have such sophisticated tools and all these modelling tools are Excel-based tools. But over the last three or four years, they have evolved to be very sophisticated and you can do a lot of analysis with just those tools. What happens if I realize X, Y, Z? What will my margin look like in year one, two, three? I can do all that analysis and make a really informed decision. You can price each risk and judge which risk you think has a higher chance of becoming reality, during the execution of the project. Then you can see what impact the risk realizing will have on the project.

{audio:0:52:57} Does any provider have pricing power, today? Does any provider have a competitive advantage, where they can persistently charge a higher price to customers and retain customers?

{audio:0:53:22} No. I very passionately believe that those days are gone. I think we would have heard like, in the past, where on several cases how large companies, like IBM, were charging such a premium for the customers; those days are gone. Today, reasonable price and stickiness is determined by innovation and your abilities to cannibalize. With these constraints, gone are the days when you can put on a hefty premium and sit back and enjoy.

{audio:0:54:01} I think the systems have become very open. One of the evolutions is, in the last 20 years, from a very closed proprietary system, like Burroughs and IBM and so on, to how a much more open stack is getting deployed. The skill set is available, out in the market, as well as the ability to crowdsource the skill set. All of these are tangible, very meaningful ways of executing a project today. Bigger companies do this, both crowdsourcing and crowd execution. That is a level of openness which is awesome. It gets the best for innovation and the best for the clients, as well. Today, I don’t believe that that scenario truly exists.

Cognizant vs EPAM: On-Premise to Cloud Managed Services

How large enterprise customers choose managed service providers for mainframe and cloud application services

Typical contract structures and how pricing is set for projects

The impact of shorter contract durations and renewal risk

Drivers of gross and operating margin for managed service contracts for the cloud today

Cognizant vs EPAM: On-Premise to Cloud Managed Services

Former VP at EPAM Systems and Cognizant

inpractise.com/articles/ctsh-epam-application-services

Why is this interview interesting?

Executive Bio

Kamesh Chetty

Former VP at EPAM Systems and Cognizant

Interview Transcript

Related Content

Accenture: A Culture of Client-Centricity

Former Head of Sales, Financial Services at Accenture

Cognizant Technologies: BPO to BPaaS

Former VP, North America at Cognizant Technology Solutions

Audio

Cognizant vs EPAM: On-Premise to Cloud Managed Services(September 8, 2020)

PARTNER

Speak to Executive