Focusing On Outcomes, Speed And Communication With Sourav Chakraborty

A significant number of digital transformation projects fail not due to a lack of resources but simply because of wrong prioritization. Sourav Chakraborty of Crescere Analytics is here to discuss how digital leaders can increase their likelihood of success by prioritizing outcomes, executing with speed, and communicating proactively. Sharing two real-life examples, he explains how to reorganize your goals with the help of up-to-date technology and avoid investing millions in doomed-to-fail projects. Sourav also breaks down the skills every product manager must possess to deliver the best results to your business.

—

Listen to the podcast here

Introduction

Hello and welcome to a new episode of the show. As we all know, a significant number of digital transformation projects end up in failure. Others simply under-deliver and only a minority are truly successful. If you are a business or digital leader about to embark on an initiative of your own, what do you do to decrease your chances of investing millions into a fiasco? We’ve discussed in previous episodes that there is a limited number of factors that predict transformation success.

Our guest is Sourav Chakraborty, and together we cover the importance of focusing on the outcomes, executing with speed, and communicating proactively. With over twenty years of experience in technology architecture, Sourav has guided many programs from vision to realization across industries and continents.

He is truly passionate about bringing people together from business and technology functions to solve the toughest challenges creatively. His clients and colleagues recognize his expertise in areas such as decision and analytics, process automation, data management, and enterprise integrations. For his part, Sourav describes his leadership philosophy as empowering teams and stakeholders while adopting fail-fast methodologies like design thinking and agile. Without further ado, here’s my conversation with Sourav Chakraborty.

Sourav, welcome.

Thank you, Alex. Thanks for having me.

Thanks for taking the time. It’s always an immense pleasure to have practitioners with such immense experience and one that’s as diverse as yours for two decades if I’m not mistaken. You’ve been working with large enterprises, going through digital transformation, delivering, engaging directly, and also managing delivery teams. Last year, you founded your own company, developing AI applications. Would you say this is a radical break for you or it’s a natural progression?

I would say it’s neither of those. This is something that I have been meaning to do for a while, but it’s difficult to say this is the right time. Sometimes you need to take the plunge and do it. That’s what I did last year. When I work with different customers, I have seen there are certain gaps in the market. There are some white spaces. I thought this was a good opportunity for me to jump in and solve that problem.

Do you mind saying a few words about your vision for the company?

We are out to democratize analytics. I specifically say analytics and not AI because when it comes to business decisions and business intelligence, there is an entire spectrum of analytics starting from pure arithmetic, roll ups, roll downs to statistical, stochastic analysis to probabilistic and predictions, and then more complex machine learning based algorithms.

The gap that I have noticed in the market, is that there are a lot of practitioners, particularly in the corporate finance space, supply chain, and internal audit, who have a number of use cases that can benefit from different analytical tools. What they struggle with is how to do this. Number one is the lack of a data science skillset, which is fair. You don’t expect them to be back to college and do a data science PhD, but also at the same time, they’re like, “Which tools do I need to get? Do I need to get a team, Do I need to get data out of my ERP and who’s going to help me do that?”

Outcomes: A lot of practitioners, particularly in the corporate and supply chain, struggle to use various analytical tools.

There are a lot of technical challenges and our goal is to make that analytics accessible. We focus on exactly the way people work. They work with their Excel. If you have data in your Excel, fantastic, just load the data. We work with guiding our users. You load the data and the system will tell you, “This is what I’m seeing in your data.” Does it make sense? Is it something that you’re interested in?” We take you step by step to help you get where you want to be. I’ll be frank that in our current version, it’s not completely hands-off. Again, we started only a year ago. It’s not that iPhone that you just unwrapped and started using. We still get involved. That’s the general direction that we want to be in a couple of years.

For me, it does sound like a little bit of a natural progression because, in the digital transformation world, that desire to work together with business people and make the technology easier to use, not hidden behind a number of large groups of engineers and IT people had, even if it’s not always been possible, but it’s been an aspiration for years now.

This is one of the themes that I have seen throughout my career. One of the primary criteria for a transformation program to be successful and for a business to be successful is to focus on the outcome.

Echoes Of Innovation

Sourav, in this segment, we use storytelling to bring our audience authentic insights. However, I always have to advise my guests to use discretion with names and specifics to honor confidentiality agreements and most importantly, respect the privacy of the individuals involved. With that in mind, can you think of a story that you can share with us that would illustrate how focusing on the outcomes leads to success?

I’ll talk about maybe two stories. The reason I want to talk about two stories is that we always focus on stories of success. History is always written from the winner’s point of view, but it’s also important to understand stories of failure because stories of failure are where we learn. They’re easier to learn from things not to do.

We often focus on stories of success and the winner’s point of view. However, there is so much to learn from stories of failure.

I’m going to talk about two different stories. These are both two large financial institutes in the world and anybody would have known them even if I mention the color or country. The transformation programs that I’m going to talk about, they’re all about compliance and global change. In one particular case, both were driven by regulatory demand. In both programs, I was engaged in the span of about five years. The first one was with one of the organizations, and afterward, four years with the second organization.

The typical tensions in a story exist in both organizations. You have tension around, “Why are we finding this? What is the outcome we want?” Just like any large program, there are multiple stakeholders and everybody wants something slightly different. There is always somebody who is trying to coral everybody into an outcome that’s beneficial for the organization. In the first instance, a couple of things that made the story work out well is that there was a very clear sense of outcome and this is what we want and the things that we do not want.

Was it like that from day one?

It happened pretty early on during that program. It happened within the first quarter of that program because we started to realize that there were too many stakeholders who wanted different things or their own benefit. In many cases, their goals were slightly off route from where the program should be from the initial goal. Of course, managing that conflict was one of the key aspects. Again, focus on the outcome, focus on the goal.

Focus on the goal typically has a couple of aspects. 1) What is it we are trying to do? 2) The prioritization. What is it we’re going to do first? What is it we’re going to do next? Also shared the understanding that anything that we are saying we’re going to do next is not about winning or losing. It’s making sure that we are validating at different steps in the program.

Coming back to compare and contrast, the key difference is one organization was successful is that they were able to prioritize.

We set a goal early on saying that we need to deliver the first phase within X number of months and we need to start engaging our stakeholders across the world. Because we started doing that, we started to prove value early on. Also without concepts, design patterns, or processes that were not adding value because the moment you go out, you start to get feedback from the actual users. You see what’s working and what’s not working.

Doing that was key. The second one is that you think of it as a top-of-the-program pyramid. The program director and the product owners are in charge of defining and prioritizing requirements. They were empowered to make a decision. I can make a decision. I can prioritize, and I know this is what’s going on in the first chunk of delivery. It requires some negotiation. You need to negotiate with your stakeholders because I wouldn’t be happy if you told me my requirements would be delivered in the third phase, but everyone needs to understand what is beneficial for the business.

Those are the few key factors that were differentiating, compared to the second example where we had a fantastic team. We had a fantastic enterprise architect who knew everything about all the key systems across the organization and the end vision of the target state where they wanted to be. The big difference was that there was always this vision that one fine day, we’ll turn on the switch and the world will be different. That never happened.

I guess it was because the organization did not have enough appetite or there was too much risk to do that switch at some point.

It’s a combination of all of those. Number one, purely from a stakeholder’s point of view, they did not see the result in production changing the business even after three years. They were ready to pull the plug. They’re like, “I don’t know if it is real.” That’s number one. Number two, this program ran for close to about three years. You can imagine in three years, technology has evolved and it was a constant conversation every year of, “Are we still okay to use the technology from last year or two years ago or three years ago or shall we change?” It was always shifting sand, but it could have been different if we said, “Let’s put something in production and then see if it works, and then let’s figure out whatever comes in the next evolution of technological capabilities, and how we’re going to use it.”

Why was it so much more difficult in that second example to prioritize and focus on the outcomes?

There was a sense of fear of missing out that if I don’t get my stuff in the first release or second release, I don’t get it. Let’s put everything in one release. There was a sense of fear of having a difficult conversation about why something needs to go before something else. Ideally, it should be driven by business prioritization, but when you get emotional, “My requirements are equally important.” It then becomes a question of let’s do one and figure out if it works or not, but people were afraid to have those difficult conversations.

It’s not easy.

Those three principles always come back. Are you purely focused on the outcome instead of being pedantic about your technology? Number two is speed. When I say speed, it’s always proven along the way. Don’t wait until the end of three years. I’m not just talking about the technology landscape. It’s also the business. I’ll send you more. The number three is communication. It’s always the key to make sure that bad news travels faster than good news.

Blueprints Of Innovation

Thank you very much. Before we move on to the next segment, if you find this story valuable, please like and subscribe to help us reach a wider audience. We’re having this shorter segment. Usually, we focus on the tools methods, or other concepts that we might have mentioned previously. You’ve been giving us good examples of organizations either managing to focus on the outcomes or failing to focus on the outcomes. Would you mind defining that term for us?

If you are spending money on something, you’re trying to achieve something. What is it that you are trying to achieve? Is it a better experience for the customers? Is it cost-saving from your operations? Is it making your processes more efficient? Is it bringing more automation? Some of those may not be the end goal by themselves. I give a few examples and you can pick which one is not. Bringing automation. Why are you bringing automation? What is the outcome that you’re trying to achieve? I’ll give you a simple example.

This is something I have been working on with one of the clients fairly recently. They have this concept of four eyes check. Somebody fills up a form, and somebody else looks at it. I can talk about ten different digital tools that can make the process digital, faster, and more controlled, but it’s not going to benefit the business in the long term. As a business owner, you need to ask the question, why? From four eyes check, do I want to go to two eyes check, but why?

The goal at the end of the day is to reduce risk. You want to reduce risk at a lower cost. What is the best way of doing that? Which technology can you use? For some of those conversations, you may not have a clear idea of what is technologically possible. What is the limit of the available technologies? That’s where you may hire consultants from outside to tell you what is possible, but focusing on the outcome is key. Many times, you end up digitizing the same process that you had for the last ten years and it benefits nobody. You spend a few million dollars and it benefits nobody.

Another term you’ve mentioned and that I guess is related is the role of a product manager. Is it fair to say that a good team of product managers is there to ensure that you’re focused on the outcome?

It is, but it’s also one of the least understood terms in all the work that we do for different clients. I think that calling a role product manager, particularly when you are not developing a product, is very misleading. It should be called a business czar with a degree in prioritization. Somebody who needs to understand how business works, somebody who needs to have a clear sense of what is possible and how fast something is possible, something with a good sense of prioritization.

This is another skillset that we typically overlook. It is somebody with a good negotiation skill because product owners that I have seen understand everything. They understand the prioritization technology. They’re like, “This is what we are going to do 1, 2, 3, 4, 5.” When they give the message back to their business stakeholders, everything changes because they cannot negotiate.

A product manager should be a business czar with a degree in prioritization, how fast certain tasks can be accomplished and possesses good negotiation skills.

For me, it’s four things. Do you understand the business? Do you understand what outcome you are trying to achieve? Do you understand from a technology point of view what is possible and how fast something is possible at what cost? Number three, can you prioritize based on the first two? Number four, can you sell your list of priorities back to your stakeholders?

Innovator’s Playbook

Sourav, in this third and last segment, we aim to provide practical advice to our audience. You’ve given us great stories about the importance of focusing on the outcomes and executing with speed and communication. Let’s try and unpack this for our target audience. Let’s say from the perspective of a business leader, what kind of strategy should they be looking at to ensure that they’re focusing on the outcomes?

The primary strategy needs to be always to ask five whys. Why am I doing this? The first why could be for yourself. The second why will be for the boss. The third why will be for your boss’s boss. The last one could be for the market if you’re a listed company. One of the things that I do advise my clients, and I’m talking about my clients right now, is that any business case that we put together always needs to address where the business wants to go.

Whatever I’m doing, is it going to help with the top line? How does it help with the top line? Is it going to help with the bottom line? How is it going to help with the bottom line? At the end of the day, is it going to help the share price? Is it going to help the employees? Is it going to help the other stakeholders, customers, and suppliers? Those questions are always key. Many times we get into the nitty-gritty of doing technology stuff, which I love, but I always ask myself the question why am I doing this?

I think it is very important. At the end of the day, I’ll give you a simple example of optimizing your input. A very practical example is one of my clients. Why are we doing this? We are doing this so that we can reduce the inventory capital. Why? Because it is going to help us reduce the working capital commitments. Why? If you add the cost of capital, it is going to help you reduce the capital. How does it help? It helps you with the bottom line. It helps you with the share price. You need to ask yourself those questions

You take the focus away from what is technically I’m doing and more on why I’m doing that. When you focus on why, the technology becomes a sideshow. For me, the question becomes what tools can I bring in to solve this problem? Whether that’s simple analytical tools or working with a professor at a university on a supply chain to design a new algorithm doesn’t matter. We bring in those to help with the outcome.

When you were defining what a product manager does, there are a number of skills you’ve mentioned. It’s not that business leaders don’t want to focus on the outcomes. It’s just sometimes very difficult to have the ability to understand the art of the possible, to understand what the business does, and by the same person, to know how long something is going to take to be able to sell it. Do you always recommend that organizations acquire those skills internally to start having their product owners or product managers? Is that something that can be relied upon with an external partner?

I think the answer is 2.5. The answer is not 1 or 2. I’ll tell you the reason for that. Acquiring skills is not a realistic recommendation for most organizations. Unless you are big with deep pockets, hiring the right skills may not be the answer all the time. The alternate answer is to hire people that you trust. If you don’t know that person or if you don’t know that organization, I’ll send something small to validate. There’s another aspect. Even if you cannot hire, the organizations need to think of how to take the red tape off from innovation.

Depending on your workforce, most people are very inquisitive. That makes us humans different from AIs. It’s our curiosity and our inquisitiveness. If you let people use technology and if you let people experiment with technology and see what outcome they get, that will bring the innovation in-house. In most organizations I have seen, it’s not that they don’t have the right people with the right mindset, they have the wrong red tape.

Because they have the wrong red tape, they stop innovating themselves until somebody from outside comes in and shows them, “This is what you could have done.” That becomes a wow moment. The answer is a combination of 1 and 2. One, you cannot hire, but you can always let the red tape go and let people innovate, let people experiment, but also bring in extra health because they will always tell you what else is going on in the market.

As we approach the end of the interview, are there any final messages you’d like to leave our audience with?

The name of this show is Innovation Tales. There is a specific type of mindset that you need for innovation. That mindset starts with curiosity and less affiliation to how things have been because how things have been was only defined by the limit of imagination of people who heard your role before you. It’s always a matter of curiosity. How do you use all the tools that you have available, whether that’s manpower, technology, budget to spend, or whatever it is, to achieve the outcome? That’s practical innovation.

Innovation requires a curious mindset and a fascination with how things have been.

Very good point to finish on. Sourav, it’s been a pleasure.

Thank you, Alex. Thanks for having me.

—

That brings us to the end of this episode. This conversation highlighted once again that the hardest challenges we face when working on digital transformation initiatives are rarely technical. The two examples shared by Sourav illustrate perfectly three of the human factors involved. If you’re watching this on YouTube, don’t forget to like and subscribe. You can rate and review the show in your favorite podcasting app. We look forward to your feedback. In the meantime, we have more episodes lined up, so stay tuned for more tales of innovation that inspire, challenge, and transform. Until next time, peace.

Important Links

• Sourav Chakraborty – LinkedIn

About Sourav Chakraborty

A veteran technology architect with over two decades of experience, Sourav has successfully delivered digital transformation programs, from defining vision and strategy, through design, deployment and benefit realization – across industries and continents.

He is a passionate collaborator across business functions, operations, technology and technology ecosystems – to solve toughest challenges creatively, and adopt best practices.

His clients and colleagues recognize Sourav as an expert in enterprise capabilities, such as – Decision and Analytics (Rule Based Decisioning, Business Intelligence, Artificial Intelligence, Machine Learning, Natural Language Processing), Process Automation (Business Process Management, Workflow, and Robotic Automation, Process Intelligence including Process Mining), Data Management (Operational, Analytical), and Enterprise Integrations.

His work philosophy and leadership evolve around empowering teams and stakeholders; and adapting to fail-fast methodologies like Design Thinking, and Agile.