Start with the Problem, Not the Methodology with Prem Krishna

You hold Master and Black Belt in Lean Six Sigma.

You have an MBA from Copenhagen Business School, a TOGAF Enterprise Architecture qualification.

You also have certifications in Signavio and process mining.

So you have a lot of tool to choose from when you're trying to solve a problem.

Could you explain maybe what a few of those things are, and then also which ones do you see as the most relevant today? And are any of them maybe not as relevant as they used to be?

I think for me, it is all these are the skill set which help me in solving my day-to-day problem in my roles.

And when I go and work with my stakeholder, I try to still focus on what are the values they would like to obtain.

And then depending on that value part, I think about what tool sets I know and how I can utilize those knowledge and tool sets.

For example, if I talk about MBA.

In MBA, I got a chance to interact with people coming from finance, coming from operations, coming from marketing, so many different perspective, right? So when you talk about problem, sometimes we've become very narrow focused and look into how I'm going to save some cost and money a- and make things more efficient.

But how it is going to impact in our sales, how it is going to impact in our culture and values, how it is going to impact, uh, in terms of transparency in the organization.

So we sometimes forget because we become so narrowed in our problem-solving approach.

So that is something which I use on day-to-day basis whenever I'm going and solving something around any of the problem.

When I talk about Lean and Six Sigma, irrespective of I'm running a Six Sigma or Lean project or not, but that taught me how to break the problem, okay? So whenever there's a problem, I try to figure out how big the problem is, where I would like to be, what actually good looks like, so that I can measure from A to B.

And then I try to figure out what are the root causes, because as I told you earlier on the process, process itself is not a problem.

But sometimes people say, "Oh, I don't like process," or, "Process is making things more bureaucratic." I try to understand why it is making or creating certain problem for them.

I try to understand what is the root cause for that.

Maybe we are emphasizing our documentation of certain things which is not necessary and which is also not the need of the organization.

So figuring that out is very important, and that's something which I'm using Lean and Six Sigma.

Then a lot of people are right now focusing on Agile, for example, and I was talking with one person other day, again, in which kind of scenario we can use a normal software development life cycle versus an Agile scenario.

If, let's say, you're working on a space station project where you need to launch a satellite to the orbit, you're not going to launch a Agile project that, "Oh, let's launch the, uh, satellite, and then we keep on fixing the bug on the go," right? So that is also a thing we need to understand.

You need to develop the, your skill set and then use that skill set in different environment.

All those things have been important and crucial for my journey.

It is not one thing which is better than other.

It is depending on the scenario, depending on the value which I am trying to drive, I might be using different skill set.