Cognizant vs EPAM: On-Premise to Cloud Managed Services | In Practise

We're gifting a 2-YEAR FREE SUBSCRIPTION to one user who completes this two-minute survey

Cognizant vs EPAM: On-Premise to Cloud Managed Services

Former VP at EPAM Systems and Cognizant

Why is this interview interesting?

  • 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
  • How EPAM is positioned versus Cognizant
  • Drivers of gross and operating margin for managed service contracts for the cloud today
  • The importance of driving innovation and cost savings for the customer

Executive Bio

Kamesh Chetty

Former VP at EPAM Systems and Cognizant

Kamesh has over 20 years experience delivering managed services for large global consultancies. Kamesh is the Former VP at Cognizant where he led various digital transformation projects for large healthcare payers. He also enjoyed 3 years at EPAM where he was VP of Financial Services and Application Managed Services where he was leading projects for the world’s largest banks and insurers. Prior to EPAM, Kamesh spent 10 years at Unisys as VP of Services Delivery where he was leading the delivery of application services globally. Kamesh started his career leading professional services at Firepond and is now Digital General Manager at DXC Technology. Read more

View Profile Page

Interview Transcript

Kamesh, can you share a short introduction of your background, in the industry, over the last 20 years?

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.

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?

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.

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.

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?

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.

Has that changed the nature of the customer relationship?

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.

Arguably, this shift to a more maintenance or recurring revenue, plus agile development, is stickier for the providers, with clients?

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.

How different is the relationship today, in a cloud environment, versus those old, on-prem, mainframe days?

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.

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.

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.

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.

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?

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.

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?

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.

Sign up to read the full interview and hundreds more.


Cognizant vs EPAM: On-Premise to Cloud Managed Services

September 8, 2020

Sign up to listen to the full interview and hundreds more.


Speak to Executive

Join waiting list for IP Premium
Did you like this article ?