B2B Sales

Financial Decision Making

High Variability Operations

Leadership Paradigms

Manufacturing & Supply Chain

Sales & Distribution

Thinking Process

Listen Now

In this episode, Satyashri Mohanty, Director, Vector Consulting Group, delves into Deep Causal Thinking in management. He explains how to unravel complex problems and improve decision-making. Essential listening for sharpening analytical and problem-solving skills.

Understanding the Importance of Deep Causal Thinking in management

In the second episode of this season, Satyashri Mohanty, dubbed "The Coach" at Vector Consulting Group, will be explaining one of the facets of Vector's Thinking Processes - Deep Causal Thinking.

Understanding the Importance of Deep Causal Thinking in Management - vectorconsulting

In this episode, we discuss the reasons behind products that fail and also evaluate the underlying conflict. We talk about the key factors that make or break products in the market. Ideal for those intrigued by innovation and market dynamics.

How to ensure a successful product launch?

In this episode of the Counterpoint Podcast, we will examine the mystery behind new product failures, identify the core conflict underlying them and discuss steps to enable the success of every new product or service you launch.

How to ensure a successful product launch? - vectorconsulting

Hello and a very warm welcome to Counterpoint Podcast. I am Shubham Agarwal. This podcast is a continuation of our previous episode #42 on challenges in software product development. We discussed about Sprint based Agile approach, some of the flawed assumptions behind current methodology and its devastating effect on the overall software project. The root cause for long &amp; unpredictable release time, huge backlog of bugs, budget overrun or high stress close to product release. In case you haven’t had a chance to listen to the episode, I would strongly urge you to do so to understand the problem statement in depth.In the previous session with Anantha Keerthi we focused more about the problem statement – In today’s episode let us explore the solution part. Anantha Keerthi is a partner with Vector Consulting Group and has transformed many systems in the past. So, let’s welcome Anantha,<figure class="table"><table><tbody><tr><td>Shubham Agarwal :</td><td>Hi Anantha, welcome to the counterpoint podcast.</td></tr><tr><td>Anantha Keerthi :</td><td>Thank you Shubam, Thank you for having me.</td></tr><tr><td>Shubham Agarwal :</td><td>Anantha I can’t forget the interesting analogy you gave about Procrustes to explain the vicious loop created by Sprint cycles and also the constraints of SMEs (subject matter experts in Software teams), can I request you to quickly tell us the vicious loop for a quick revision and tell us how do we come out of this vicious loop.</td></tr><tr><td>Anantha Keerthi :</td><td>One of the key differentiators proposed by Agile was iterative software development, Iterative development by definition is the opposite of pre-planning. Isn’t it? ….. so then, how can you plan an overall project or version delivery? Any iteration can go endless! ……. So, to address this problem, there is a solution in Agile framework. i.e Sprint deadlines. Like Procrustes’s standard iron bed, the sprint cycle forces people to somehow close things.&nbsp;Every sprint becomes a deadline with pre- committed scope. As almost all resources in the team become extremely busy towards sprint closure, any planning activity of subsequent sprint is left behind. Bcos There is no time! ….Consequently, in every sprint, initial time is used up in planning work. Actual development and testing happens towards second half of a sprint cycle, this builds pressure of time towards end of every sprint. So what happens when there is pressure of time? ….it leads to skips and misses (compromise in Requirement &amp; Design), yes !. any such compromises will come backs as bugs, regressions &amp; rework, now the team becomes even more busy (especially the subject matter experts). So, there is almost no time for preparation for subsequent sprint. Now every sprint starts without adequate preparation. This vicious loop goes on.One of the assumptions of the waterfall method, which was questioned by Agile, is the ability of customers to clearly specify requirements upfront! Many times, a requirement becomes clear only when customers actually see or start using some piece of your product!!. In this situation the need to have a perfect spec from the customer can make the requirement phase completely out of control.But at same time, the agile implementations also suffer from inadequate requirements and design. Yes, we had a detailed discussion about this in the previous episode.If you carefully see, we have a generic conflict underlying the entire software development process. Can you guess what is it?</td></tr><tr><td>Shubham Agarwal :</td><td>Let me Try. Should we freeze the requirement before starting the coding or not. I am I right ? ● On one hand, we should freeze requirements &amp; design before implementation (ie. coding) because this approach ensures rework is under control and hence, time is under control. ● On the other hand, we should not freeze requirements &amp; Design because it is impossible to freeze them.</td></tr><tr><td>Shubham Agarwal :</td><td>Users get clarity on what they actually want after using or visually observing the product.</td></tr><tr><td>Shubham Agarwal :</td><td>Then how do we come out of this conflict?</td></tr><tr><td>Ananatha Keerthi :</td><td>This conflict has given us an important insight about two kinds of rework …..or errors which gets generated in any new product development process.One you can call it as Type A (or Foresight rework) and the second is called as Type B rework (or hindsight error) Type A rework is created because of skips and misses made under pressure of time or lack of synchronization between the team members. Whenever you see these kinds of errors you will say – “Oh! how can this happen, we could have prevented this”. That means the process or knowledge to prevent this error already exists within the team, nevertheless the team is committing these errors under pressure of time. Shubham Agarwal – So in a way, type A is a Preventable error.</td></tr><tr><td>Anantha Keerthi :</td><td>Yes! so Using testing team to give feedback on these types of preventable errors is a criminal wastage of capacity isn’t it? So, type A errors always causes frustration among the team or the management. Shubham Agarwal – So what is the second type of rework or errors</td></tr><tr><td>Anantha Keerthi :</td><td>The second type of rework i.e., Type B: these errors are detected only after the event of testing is done, only in the hindsight you can tell what the real cause for these kinds of errors was. That is why type B errors can also be called as Hindsight errors. No amount of thought experiment can help one visualize the Type B errors upfront. The other way to look at is, type B errors create new knowledge which was not there before. The earlier you detect, the better it is. (In fact Proto types are created for the same reason.)</td></tr><tr><td>Shubham Agarwal :</td><td>In a nutshell – Type A is an avoidable rework, this got generated because the team has violated some internal process under pressure of time, Whereas Type B error can be detected only after final testing.</td></tr><tr><td>Anantha Keerthi :</td><td>That’s right ! So, Waterfall method somewhere implicitly assumes that all errors are Type A (Preventable errors), hence it insists on adherence to process, For example – “If you want me to start the development, I will say… first sign off on the requirement, sign off on the spec, sign off on the design !! this way in waterfall approach there is lot of checks and gates before moving from one stage to another. …… Whereas Agile, somewhere implicitly assumes that all errors are of Type B, hence it considers one-time handovers between phases as a waste of time. therefore, agile propagates iterative development – The school of thought here is “I know requirement cannot frozen…. Let’s get started, with more iteration it will mature” hence in agile it’s alright to have frequent back and forth between all phases.</td></tr><tr><td>Shubham Agarwal :</td><td>Oh! This sounds really interesting – you are now clearly verbalizing the inherent assumptions of both Waterfall and Agile approach, its getting very clear and simple to understand.</td></tr><tr><td>Anantha Keerthi :</td><td>If you go back to History of Automobile manufacturing this “Agile” way is exactly how automobiles used to be manufactured in late 18th century. Have you heard of Craft manufacturing ?</td></tr><tr><td>Shubham Agarwal :</td><td>Yeah.</td></tr><tr><td>Anantha Keerthi :</td><td>A car used to get manufactured from start to end through a group of expert resources with different skills. This cross functional team is expected to cohesively work and eventually a vehicle would come out after spending lot of time in iterative work. Ofcourse ! This way of car manufacturing was very expensive and only the rich could afford it …..in that era.</td></tr><tr><td>Shubham Agarwal :</td><td>Then came Henry Ford</td></tr><tr><td>Anantha Keerthi :</td><td>When Henry Ford presented the assembly line concept with clear division of labor, The entire car manufacturing was transformed. There was a Clear sequential working with different resources specializing in different types of assembly task. The cars moved between stations (instead of the workers moving). The specialization on one type of task,… and by avoiding switching losses between different type of work… enabled a productivity jump by multiple times.&nbsp;The revolutionary idea dramatically reduced the cost of making a car. The masses could afford a car because of the enhanced productivity. In a way, the car industry gave up the “agile methodology” of car making and achieved giant strides in productivity.</td></tr><tr><td>Shubham Agarwal :</td><td>– So, Are you advocating assembly line working for software development?</td></tr><tr><td>Anantha Keerthi :</td><td>– Well, before we going there first we need to understand, under what boundary conditions the assembly line works..&nbsp;Look! an assembly line approach requires two critical conditions to be successful1. Flow backs are negligible. Work moves forward in one direction. If nature of work is such that it frequently comes back to previous workstations for rework (it is called as flowback), such flowbacks can create chaos with uncontrolled line stoppages and reduced output. (In such an environment, craft manufacturing, or the agile method, is a better way). 2. Transfer batches should be small (ideally a single piece flow). Transferring of big batch of work not only expands lead-time in every workstation but also leads to late detection of quality issues.</td></tr><tr><td>Shubham Agarwal :</td><td>Are you saying, If we meet these two conditions i.e., 1) very minimal flow backs and 2) small transfer batches then we have a solution ?</td></tr><tr><td>Anantha Keerthi :</td><td>– with this we can resolve the inherent conflict of the software development process.&nbsp;What is the desired work-flow in a software development – First you need to understand the requirement, elaborate the spec, then do a proper design, then only get in to development and finally testing.As discussed before, the major reason for flowbacks is improper Requirement detailing and Design. So, Reorganizing the team into Recruitment assessment team, Design team, development and testing teams – This helps to create the required division of labor for assembly line working.Now we have clear work centers as Requirement and design in upstream and development and testing in downstream.The question is? Who should be working in upstream and who should be working in downstream ?</td></tr><tr><td>Shubham Agarwal :</td><td>I think it is SMEs in upstream</td></tr><tr><td>Anantha Keerthi :</td><td>– Obviously ! the experienced SMEs are the best resources to work in upstream. Such expert resources are limited in every team. when your expert resources are dedicatedly work in Requirement assessment and design, the need for them to go down stream is very less. isn’t it ? – i.e</td></tr><tr><td>Shubham Agarwal :</td><td>– they don’t have to waste their capacity in development (coding, bug fixing etc).</td></tr><tr><td>Anantha Keerthi :</td><td>So, they are less busy now.</td></tr><tr><td>Shubham Agarwal :</td><td>What else is expected out of the Requirement team ?</td></tr><tr><td>Anantha Keerthi :</td><td>– This is not just about understanding the requirement from customer perspective or from development perspective, …This phase should focus not only defining what should be done in a feature but also defining what should not be done, or what will not be given. This could be the first workstation but it is also important to begin with the end in mind. after understanding the requirement also define how this will be validated in testing.</td></tr><tr><td>Shubham Agarwal :</td><td>Inputs from testing team is required.</td></tr><tr><td>Anantha Keerthi :</td><td>Yes, it is important. At times, visual prototypes can also help customers visualize what they really want.</td></tr><tr><td>Shubham Agarwal :</td><td>How about Design team?</td></tr><tr><td>Anantha Keerthi :</td><td>Surfacing the various dependencies, interaction with other functionalities, Impact analysis, Architecture, infrastructure Review, defining the Boundary conditions – all this constitutes design work which is aimed at preventing Type A errors. To a large extent we can pre-pone Type B errors as well. Regressions are minimized as dependencies are clearly defined.</td></tr><tr><td>Shubham Agarwal :</td><td>Earlier you mentioned that, when it comes to engineering of physical products, these design aspects are never ignored.</td></tr><tr><td>Anantha Keerthi :</td><td>Yes ! in physical products, the damage is visible, damage in terms material, dismantling of structure, rework, everything is visible. But most people think, software product development is more forgiving !! The reality is – The damage is just hidden.</td></tr><tr><td>Shubham Agarwal :</td><td>This is really great, we are transforming a project environment into a flow environment.</td></tr><tr><td>Anantha Keerthi :</td><td>So, far we have discussed about, minimizing the flowbacks. There is one more aspect of Rapid feature flow model, i.e., Minimizing the transfer batch In a high variability environment, if we impose rigid time buckets, it’s a clear recipe for skips and misses. Software development is a high variability environment, if we impose sprint time buckets it creates skips and misses</td></tr><tr><td>Shubham Agarwal :</td><td>it leads to Type A errors.</td></tr><tr><td>Anantha Keerthi :</td><td>That’s right. The best way is to replace the sprints with work in progress control rule i.e WIP rule. This needs to be applied across each resource group – Like you have Requirement group, Design, development &amp; testing groups. A new feature will be introduced to a resource group only when one under progress is complete. The rule of “One-Out-One-In” ensures a single piece transfer batch. This is how the second important criteria of high productivity assembly line is met – that is minimizing transfer batch.</td></tr><tr><td>Shubham Agarwal :</td><td>Oh ! this is so different ! Suppose I am in Development team, I can pickup a new feature for working only when I finish which i already have !!</td></tr><tr><td>Anantha Keerthi :</td><td>Yes ! Here, completion decides the start ! the entire focus is on completion!.</td></tr><tr><td>Shubham Agarwal :</td><td>Its means there must be a clear definition of what is complete for each stage.</td></tr><tr><td>Anantha Keerthi :</td><td>– Yes! It is called as closure criteria… Not only that,…. since you are not allowed to pickup new feature until you complete something in-hand, there is a waiting queue of features or work packets building-up outside the WIP bucket. When you finish one, …which one are you going pickup from the Queue.</td></tr><tr><td>Shubham Agarwal :</td><td>Correct ! I never thought about it ?</td></tr><tr><td>Anantha Keerthi :</td><td>There must be a clear sequential priority for each feature or workpackets Following the above principles…. will help in rapid flow of features from this system. That is why we call it as Rapid feature flow Model!</td></tr><tr><td>Shubham Agarwal :</td><td>Anantha, what kind of results can we expect from the new rapid feature flow model.</td></tr><tr><td>Anantha Keerthi :</td><td>A typical implementation must see a drastic reduction in rework (number of bugs generated, number of regressions, reopen cases), you can expect a reduction of 50% to 80%A productivity jump of 70 to 120% is not surprising – because this is the effect of high productivity assembly line; Increase in output corresponds to reduction in lead time as well, that means frequency of software release also drastically improves by 2 to 3 times.</td></tr><tr><td>Shubham Agarwal :</td><td>What kind of timeline is required?</td></tr><tr><td>Anantha Keerthi :</td><td>Around to 2 to 3 release cycles are required for the new process to mature and stabilize.</td></tr><tr><td>Shubham Agarwal :</td><td>Are there any drawbacks or limitations of Rapid feature flow model?</td></tr><tr><td>Anantha Keerthi :</td><td>The WIP rule is an anti-scheduling mechanism. While following the WIP rule, a new work packet is taken up only based on completing something in hand., not because time has come. That means you can’t follow task scheduling. Then how do you predict the release date? Implementation of flow model exposes queue at each work center, also it is easy to determine clearly the flow rate at each work center; using this combination we can compute the Expected time of arrival (ETA) not only for each feature but also for the entire release. Like a google map.</td></tr><tr><td>Shubham Agarwal :</td><td>Great! that means this model allows much better predictability without scheduling !</td></tr><tr><td>Anantha Keerthi :</td><td>Not only this. Since this a perpetual feature flow system, Single features or a set of features can be bundled into releases as and when you want. Instead of committing to a release plan upfront for a year, marketers can decide on release strategy based on dynamics of the market.This provides a lot of flexibility to react to competition strategy, you can change the queue of features in the waiting list to deal with market dynamics.</td></tr><tr><td>Shubham Agarwal :</td><td>You have much better predictability and also flexibility.</td></tr><tr><td>Shubham Agarwal :</td><td>Fantastic. Anantha it was a very insightful interaction, Thank you for introducing us to this new Rapid feature flow model. It is truly innovative. It combines the inherent advantages of Waterfall and Agile Models, while overcoming the disadvantages.</td></tr><tr><td>Anantha Keerthi :</td><td>Yes !This model 1. Allow for flexibility and speed as per Agile 2. Prevent Type A errors &amp; rework as per Waterfall 3. Also recognize the constraint of the system (as per TOC).</td></tr><tr><td>Anantha Keerthi :</td><td>– Yes !</td></tr><tr><td>Shubham Agarwal :</td><td>Thank you once again.</td></tr><tr><td>Anantha Keerthi :</td><td>Thank you, Shubham. Thank you!</td></tr></tbody></table></figure>

In this 2nd part of the 2-part series, we dive into solving software development challenges. The episode explores solutions to issues like long release times and bug backlogs. Discover the Rapid Feature Flow model, blending the best of Agile and Waterfall methodologies for more efficient software creation.

Not so Agile: Part II – How to transform the software development process?

In this latest episode of podcast on ‘Not so agile’, Anantha Keerthi describes the new ‘Rapid Feature Flow Model’ innovated by Vector and how by adopting this ‘flow principles’ companies can increase productivity and reduce rework.

Not so Agile: Part II - How to transform the software development process - vectorconsulting

Do calendars filled with back-to-back meetings hinder productivity or foster vital decision-making? Explore the dilemma of managerial meetings in this insightful podcast. Uncover strategies to differentiate beneficial meetings from futile ones and learn how to transform the meeting culture for optimal efficiency.

Meeting Fatigue: How can we make meetings add more value?

Many managers talk about endless meetings in their organizations. In fact, a lot of team members also feel their bosses do not give them time because they're always busy in meetings. In this episode we will learn how do we get out of this dilemma of doing meetings or not doing meetings?

Meeting Fatigue: How can we make meetings add more value? - vectorconsulting

<figure class="table"><table><tbody><tr><td>Shubham Agarwal :</td><td>Hello and a very warm welcome to the 43rd episode on Counterpoint podcast. I am Shubham and we are going to talk about improvement projects on the podcast today</td></tr><tr><td>Kiran Kothekar :</td><td>It is not uncommon for companies to have multiple improvement initiatives/transformation programs underway at the same time. Most of these are initiated by leaders with a clear view of their benefits to the company. But at the end of the day most of these projects don’t finish, take too long or don’t deliver the results they want! So does that mean the company leadership should not initiate any improvement projects? Of course not! Lets ask our guest today, Kiran Kothekar why so many improvement initiatives fail and what leaders should do to get quantum improvements to happen in their organizations in the shortest possible time?</td></tr><tr><td>Shubham Agarwal :</td><td>– Hi Kiran. You are a founding director of Vector Consulting Group and everyone knows that Vector has helped many companies successfully take up transformational projects. But tell us first why so many improvement initiatives don’t deliver results? Is it a leadership failure?</td></tr><tr><td>Kiran Kothekar :</td><td>Leaders have to take decisions and many times many people think that leaders are born. They have this natural talent or natural instincts to take correct decisions. Can this whole process be converted into a scientific way of thinking? That means we don’t require natural leaders. Can normal leaders also take the correct decisions? There is a way of looking at it this. I was on a flight and sitting next to a MD – owner of a very large company.</td></tr><tr><td>Shubham Agarwal :</td><td>We got talking. So I asked him, “How do you know that your company’s making progress?” – a very innocuous question. And he said, “Of course, when the numbers are better, the profits are going up, sales going up, ROC get better etc..” I asked him, “Is there any period during which your numbers are not going up, they’re flat or even they are declining? Are you worried about that period”?</td></tr><tr><td>Shubham Agarwal :</td><td>That’s an interesting question. What did he say?</td></tr><tr><td>Kiran Kothekar :</td><td>– He said, “Yes, there are periods -some of them are bad but some of those periods I’m not really worried about because I know where we are doing something and that should give us results. Sometime later”</td></tr><tr><td>Kiran Kothekar :</td><td>– “Essentially what you’re saying is that there is some projects that you’ve taken up and when they finish, you will get better results?” he said. “Yes.” “So that’s my definition of how I decide when a company is making progress or not. It’s when important improvement projects are finished. By important projects I mean new markets launch of new products reorganizing the company a new ERP new CapEx etc.. When these projects are finished there is an effect on the company- company’s numbers”. He said, “That’s a very interesting definition and I like it.” So the next question I asked him is, “ If this is what you like then probably you are making fantastic progress on improvement projects? So how many projects did you finish in the last week?” He said, “None”. “How many projects got completed in the last month?”. He thought for a while and said, “None!”. “Last quarter?”. And he said “None!!”. And then he went silent for a minute.</td></tr><tr><td>Shubham Agarwal :</td><td>Oh, oh, what happened then?</td></tr><tr><td>Kiran Kothekar :</td><td>Then I asked him “How many projects did you start in the last management review that you had with your senior management?” He said “ya, I think we started two of them. One is to improve the forecasting and other is to change the way we are organized in sales because we are not actually getting good numbers in sales”. “Okay, what about the last management review meeting?” He said, “Yeah. We must have launched some projects and in the one before that as well”. But then he said, “That’s not the only time I launch projects you know I go meet some colleagues of mine in the fraternity or I go to expos or conferences or I read something and then I get ideas and then I launch projects”. “So, essentially you are launching a number of projects, is it?”. “Yes”. “So, the rate at which projects are flowing into your system is significantly higher than the rate at which the projects are coming out? And what if you had completed these projects- you would get fantastic results?” He said “Yes, of course”.</td></tr><tr><td>Shubham Agarwal :</td><td>hmm</td></tr><tr><td>Kiran Kothekar :</td><td>– “Have you experienced that when you focus on a project and you relentlessly push it -that means you review nearly every day, – the project finishes in abnormal times? He said, “Yes, six months project finishes in one month!” “Which essentially means that if you don’t do this, all the projects are getting delayed and you get the results after a year or two years. (scenario 1) But if you push a project finish in one month, you’ll start seeing the benefits, the revenues, the numbers after a month So what is a better way of doing things?</td></tr><tr><td>Shubham Agarwal :</td><td>How did he respond?</td></tr><tr><td>Kiran Kothekar :</td><td>– He said, “Ya, Now I understand. If I take one project finish it off, I get some money then I take another project finish it off, I still get some money rather than waiting for a year or two years.Then the next question that comes up is if I want to stop all the other projects which is the only project that I should take? Hmm. That’s tough question, can he stop all but one project? what did he say? He said, “No, I can’t do that because each and every project is a very important project! I don’t launch a project just for the sake of launching projects. There is an important idea or an important issue or an important obstacle that I’m solving. That’s why I launch these projects”. “Oh! Okay”. So, I said, “Let’s do a small simulation”. And fortunately for me he was from an FMCG company. So, I said “Okay your sales are not growing. What projects should you launch? Do more schemes? do more marketing? give your salespeople more incentives?”“Yeah. This is something that we are thinking about” “What if you are losing 20 percent of the orders because of your supply chain? The forecasting accuracy is at 80 percent your fill rates are at 80 percent. What should we be doing?” “Then I think first project I should do is in supply chain”. “So now you get my point? If I know this logical thinking, I can decide what not to do and what I should be doing”.Hmm.ok “So in this case we are talking about doing a supply chain project before getting into sales because if I don’t improve the supply chain and launch a marketing campaign I still will not get the increase in sales because my product is not there at the retail shop”. “Yeah, I understand”</td></tr><tr><td>Shubham Agarwal :</td><td>Hmm “So, now we decided that we launch an improvement project in supply chain. Now, what is it that you want to change? You have inventory issues, you have availability issues, your freight cost is not satisfactory, a month end spike and half truckloads going all around the places, firefighting… What is that project you will take up?” He thought for a while and said, “As a matter of fact we have actually taken a project for each of these cases and we have so many projects going on”.</td></tr><tr><td>Shubham Agarwal :</td><td>Hmm, what he has said is what most companies do. Is there a different way to approach this decision?“Yes.” “Now let’s start thinking scientifically just like physicists or say doctors think. You go to a doctor you talk about some problems of yours. The doctor asks you -do you have any other issues, and he collect all set of problems. But ultimately what does he decide? He decides there is one disease that you have and gives you one medicine. Say, it’s like malaria. He’ll give an antidote for malaria and he doesn’t try to treat your headache by giving a crocin. So, this is the approach we should bring into management. This is based on the principle of convergence.</td></tr><tr><td>Shubham Agarwal :</td><td>: Could you please explain the principle of convergence? What is different about the doctor’s approach?</td></tr><tr><td>Kiran Kothekar :</td><td>He believes that all these problems are linked to one another and there is one core problem or a root problem which results in all this. What I’m saying is that what we are seeing around us is are symptoms they are not the problems- inventory delivery issues, freight cost going haywire, trucks not being available, spike at month end- these are all symptoms. The problem is that you are following a forecasting system and the market is very dynamic that results in all these other issues. Now what if you take one project which is to build a system which does not use forecasting but uses a method by which you are reacting to market demand. Then you have solved all the issues. So that should be the first project to take”.</td></tr><tr><td>Shubham Agarwal :</td><td>It is starting to make a lot more sense now. What you are saying is that like the doctor linked up all the symptoms and found the real disease to treat, symptomatic issues in companies can be eliminated if the core problem is addressed. “Yes.”</td></tr><tr><td>Shubham Agarwal :</td><td>Ok what should be done once the supply chain project is done, can the same approach be used to improve sales?</td></tr><tr><td>Kiran Kothekar :</td><td>“Many people say let’s improve the incentive structure; Let’s launch better schemes and so and so forth. But if you look at where the maximum sales is leaking, you are a universe a one lakh retailers and you are present at 30000. And, your customers walking in into all those retailers! The first project should be how do how do I get there. How do I get into the 70000 retailers? All other projects don’t matter! So, this is what I mean by bringing in the scientific way or a logical way of deciding what you need to do.) This essentially means that we have to find out that one thing we need to do which is getting more with less”.</td></tr><tr><td>Shubham Agarwal :</td><td>This is great Kiran. Your story has given us a completely different perspective to how improvement projects should be looked at. I am sure this would help the listeners and they can start to analyze the projects currently running with this line of thought to do more with less.</td></tr><tr><td>Kiran Kothekar :</td><td>Thank you.</td></tr></tbody></table></figure>

We delve into the complexities of organizational improvement projects in this episode. Kiran Kothekar, Director, Vector Consulting Group, explains why many initiatives fail to deliver results and how leaders can effectively drive transformative changes. Gain insights on prioritizing projects scientifically and ensuring impactful outcomes in the shortest time.

All improvement projects may not add value

In this episode, Kiran Kothekar explains why so many improvement initiatives fail and what leaders should do to get quantum improvements to happen in their organizations in the shortest possible time?

All improvement projects may not add value - vectorconsulting

In this first part of a 2 part series, we dive into the world of Agile methodology and shed light on why Agile might not be as 'agile' as it seems and what may be causing its effectiveness to falter in today's dynamic software environment. We explore its core assumptions and their practical implications. Tune in for an insightful discussion on reshaping Agile for sustainable success.

Not So Agile: Part I – Challenges in Software Development

Vector Consulting Group - Counterpoint Podcast: Visit the challenges posed by Waterfall & Agile, wrong assumptions & the core conflict in software development

Vector Consulting Group | Counterpoint Podcast | Challenges in Software Development

<figure class="table"><table><tbody><tr><td>Shubham Agarwal :</td><td>What are the major problems faced in agri-equipment businesses that make this environment very challenging?</td></tr><tr><td>Mr. Antony Cherukara :</td><td>In the agriculture scenario there is always ups and downs. There is an issue of good rainfall, good monsoon. There is an issue of crop prices, so these are uncontrollable and hence, there is a fluctuation in terms of demand.</td></tr><tr><td>Shubham Agarwal :</td><td>hmm</td></tr><tr><td>Mr. Antony Cherukara :</td><td>…. the unpredictability of the market plays out onto the manufacturing front because there is a sudden demand which goes up in certain parts of the country and …if you are not able to supply on time, we’ll lose sale. So, manufacturing is under pressure and you can also not keep manufacturing inventory… too much of manufactured inventory with you because then if the season doesn’t play out, you will have to carry that inventory to the next season as well.</td></tr><tr><td>Shubham Agarwal :</td><td>Ok</td></tr><tr><td>Mr. Antony Cherukara :</td><td>There is also the whole push pay system that a… we work on in terms of ensuring that the collections come in and they… Typically, the collection comes in early in the month end and then the billing is skewed towards the month end. This create-This creates a problem with the supplier end because the raw material is already bought, and the inventory is laying at the supplier end and this queue creates a problem of cash flow for the supplier as well, wherein he cannot procure raw material for the next month’s demand. So, this creates a problem not only at the company level but at its suppliers as well.</td></tr><tr><td>Shubham Agarwal :</td><td>What was the impact of these problems on the business?</td></tr><tr><td>Mr. Antony Cherukara :</td><td>I think the-the the biggest factor was the loss of sale itself. When you have such unpredictable demand and then you’re not able to supply on time, customers move on to competitors and then you lose sale. So that is number 1, and number 2 is the efficiency of the organization in terms of a… the time spent on shortage meetings, the time spend on scurrying to ensure that supplies are maintained.</td></tr><tr><td>Mr. Antony Cherukara :</td><td>…, People had to be rushed to the supplier in to sit overnight and somehow manage the material and bring it to the company for the-for the next day’s production.</td></tr><tr><td>Mr. Antony Cherukara :</td><td>Thirdly, the aspect of losing inventory rotations a… not ensuring a… the right models are available at the right time at the… a… at the Market place that kind of stops your rotation from happening so that creates a problem that a… that also translates to problem with the supplier end, and which creates, especially with the Corona Pandemic on. Suppliers were short of cash and there were issues with the MSME’s. So, a… I mean there were problems not only in terms of a… the supply constraints, also in terms of the pandemic itself where they were lockdowns, where they were you know.. people not turning up for work because they got infected. So, all these kinds of magnifies itself when the when the-when the Inventory flow is not maintained. So it creates a… double the issues along with the Pandemic, yeah.</td></tr><tr><td>Shubham Agarwal :</td><td>How can these issues be solved?</td></tr><tr><td>Mr. Antony Cherukara :</td><td>For this, we need what are the inventory that we should carry into a season. There should be an ability to optimize inventory if the season does not play out as expected</td></tr><tr><td>Shubham Agarwal :</td><td>How did you do that?</td></tr><tr><td>Mr. Antony Cherukara :</td><td>. So fundamentally, what we have been able to create is the buffer at various levels and ensuring the buffer is more at the back end than the front end where the variation in demand is the highest closer to the consumer. So, what we have done is ensuring that the a… variation in demand is taken care of by the buffer that we have kept at a… various locations, including the warehouse and the factory, and this kind of ensures that there is no last minute rush and ensuring that the sudden… rise in demand or at the same time if there is a falling demand buffer is controlled through a dynamic buffer system,. The other aspect is you know in the last one and a half years we have faced a lot of commodity inflation and it was important that the suppliers also had a good view of what raw materials they should carry and what kind of buffer they should carry to manage this inflation so it has been an immense help in terms of not only for the company but the suppliers as well to manage their inventory in an efficient way during this fluctuating commodity inflation</td></tr><tr><td>Shubham Agarwal :</td><td>As I said in the introduction, You have lead implementation of ‘pull systems’ in the supply chains of two companies. Can you share your experience?</td></tr><tr><td>Mr. Antony Cherukara :</td><td>. See as a-as a Business Head at KOEL (Kirloskar Oil Engines) and now is CEO of VST Tillers, see one of the fundamental things that a CEO has to deal with or a business head has to deal with is the amount of resources that is… at his a… behest to garner growth for the company. So what happens is, if you create efficiency with the current resources and if you can free up resources to do work that garners growth, and that is what TOC enables us to do because we are out of the firefighting mode, because we are able to focus on stuff which is long term, and important because we are able to save time away from the daily firefighting that we are a… we used to do. This enables the same resource to work towards growth and other of-other opportunities the market throws up. So that is one big factor that I’ve seen. The second aspect is in terms of creating complete visibility and the ability to manage with a… agility in a situation where things are out of your control in terms of. I spoke about the commodity inflation aspect. For example, this system enables you to, you know… monitor raw material inventory to ensure that your inventory is optimized for the coming season, and manage this kind of volatile commodity inflation pressures that keeps happening in the industry. So that is the second aspect, and the third aspect is what we have seen is in anomaly people used to sit around, work late into the night, prepare for the you know.. kind of shortage meetings which they would have to do in the morning next day. So those kinds of meetings are avoided and people can actually get back home on time, and I think that creates a great work life balance for people. So, all in all, I think it kind of creates a social engine in the company which is about people, about the culture and how you go after growth.</td></tr></tbody></table></figure>

The demand for Agri-equipment products is significantly dependent factors like seasons, level of rainfall, festivals, etc. In our conversation with Mr. Antony Cherukara, CEO, VST Tillers Tractors Ltd., we learn about fluctuating demands, inventory woes, and implementing 'pull systems' for efficient supply chain management.

Conversations with Business Leaders: Mr. Antony Cherukara, CEO, VST Tillers Tractors Ltd.

Agri-equipment manufacturing companies tend to have a major challenge in managing operations since demand is significantly dependent on seasons, level of rainfall, festivals, etc. In this episode, we discuss the problems faced in agri-equipment businesses that make this environment very challenging and how these issues can be solved.

Conversations with Business Leaders: Antony Cherukara, CEO, VST Tillers Tractors Limited - vectorconsulting

Explore pharma operations' unique challenges in the latest Counterpoint Podcast. Uncover complexities of high lead times, variability, and the need for dynamic scheduling in pharma manufacturing. Dive into solutions for balancing customer demand and operational efficiency.

Pharma Operations

In this episode of the Counterpoint Podcast, we bring into focus the challenges that the pandemic has caused on the already disrupted supply chains of pharma companies in India and across the world.

Pharma Operations - vectorconsulting

In the last episode on Mystery Analysis, we set the groundwork on how and why to analyse to uncover the causality behind our post-implementation results. Now, we delve into 'regression discontinuity analysis' with Satyashri Mohanty, Director at Vector Consulting Group, for insights into complex scenarios like sales schemes. A must-listen for practical data analysis.

Mystery Analysis - Part II

In the last episode on Mystery Analysis, we set the groundwork for why and how to do an analysis that would help us reveal the causality behind our post-implementation results. This episode goes into details of these methods and subsequent steps to be followed.

Mystery Analysis Part II - vectorconsulting

In the last episode of the Thinking Process series, we had promised to discuss 'Mystery Analysis'. Join us as we unravel the secrets of 'Mystery Analysis'. Learn how unexpected business outcomes are dissected for deeper insights using advanced methods. Essential for those keen on turning surprises into strategic wisdom.

Mystery Analysis

How to decipher new knowledge using rigor of scientific thinking when solutions in organizations don’t deliver as per expectation. In the last episode of the Thinking Process series, we had promised to discuss about 'Mystery Analysis'.

Mystery Analysis - vectorconsulting

Dive into the fusion of data and storytelling, uncovering how numbers and narratives intertwine to drive innovation and change. Join us at the forefront of this exploration, shaping the future of how stories are told and understood in a data-driven world.

What drives effectiveness in communication: Data-first or Narrative-first approach?

BA Podcast

Vector Consulting Group primarily focuses on implementing pull-based systems across sectors in operations, sales, distribution, engineering and project domains. In essence, it implies that the creation and movement of inventory of physical goods or knowledge across work centres or warehouses are based on immediate demand pull rather than predefined forecasts, project plans or targets.&nbsp;The management styles which support push-based operations are not conducive to supporting pull-based operations. Pull-based operations require different leadership and people management paradigms to sustain the process. Very few organizations run on pull systems, while a vast majority have push systems. Hence, the conventional experiential know-how of most managers is from the traditional world of push systems.&nbsp;Counterpoint is a series of animated videos explaining management leadership paradigms essential to supporting and sustaining pull-based operations. They are common sense but are contrarian to the standard practices in organizations. Each video provides a unique insight and can be viewed in isolation. However, the insights across videos are dependent on each other. It provides a viable alternative to a typical top-down pyramidal organization, prone to chronic conflicts across departments and hierarchy.&nbsp;Three chapters have been released, and the subsequent ones will be realized soon. Watch this space for updates.&nbsp;

Ba Video

CounterPoint Podcast

Video

A video series to explain paradigm changes essential in Leadership to support and sustain pull-based operations in operations, sales, distribution, engineering, and project domains.

Let's Empower Growth