loader

On-Time Delivery, a misnomer in New Product Development

Hi, I am Dr Shashank. I lead Product Development at Imperial Motors, an Auto OEM. Few years ago, we embarked on a journey of transformation in our new product development department, using the guidelines and philosophy of Theory of Constraints (TOC). Subsequently, we’ve achieved substantial improvement in both product delivery (a whopping 400% jump in… Continue reading On-Time Delivery, a misnomer in New Product Development

Management by Tactics

Why targets are needed Organizations have goals to achieve. Overarching goals such as profits and ROI are cascaded into goals around sales, costs and capital employed in business. Towards achieving these, companies make an annual budget or plan at the beginning of the year. In this, the company lays out the targeted revenue for the… Continue reading Management by Tactics

Wandering bottleneck

Introduction:- This paper describes how wandering bottleneck(s) emerge in manufacturing plants, inadequacy of existing simplified drum buffer rope (SDBR) methodology to address these, the ramifications of continuing to use conventional SDBR and ways to smoothen flow while handling wandering bottlenecks. It also discusses possible reservations for the proposed direction of solution along with suggestions to… Continue reading Wandering bottleneck

Managing the COVID 19 crisis: A supply chain approach

While it is more deadly than the common flu, Covid-19 is less lethal than many diseases known to man. Yet, the global march of the novel Coronavirus is raising serious concerns. The human immune system had not experienced this organism before November 2019, when this virus is believed to have made the leap from animals… Continue reading Managing the COVID 19 crisis: A supply chain approach

Leadership styles and organization culture

Organization culture is mostly shaped by the way its leaders interact with the people in that organization. At times, we come across leaders, who believe that the company’s most chronic problems – stagnant sales, delayed projects or inefficiency in production or quality issues – exist only because people aren’t good enough. They blame managers reporting… Continue reading Leadership styles and organization culture

Too many cooks spoil the ..growth!

Running too many initiatives simultaneously may be counter-productive. A reality check: It is not uncommon for companies to have multiple improvement initiatives/transformation programs underway at the same time. In fact, this is considered a good sign. It shows that these companies are forward-looking and raring to grow. But these progressive initiatives might not be telling… Continue reading Too many cooks spoil the ..growth!

Balanced scorecard: A promise unfulfilled

In most companies the fundamental expectation from the annual financial budget is that it will guide and control the many managerial decisions that determine the companies’ steady progress towards its long-term goals. But, this standard practice of drawing up only financial measures undermines the companies’ interests. This is because measures like sales, inventory costs etc.,… Continue reading Balanced scorecard: A promise unfulfilled

The ‘Leap Year’ at Raymond

In an interview with Outlook Business, Satyashri Mohanty explains on how Vector team identified the real problem faced at Raymond’s textile division .

Published
Categorized as News

Raymond revamps supply chain

By implementing “pull” manufacturing and distribution, Raymond is dynamically improving its ability to react quickly to demand. .

Published
Categorized as News

Drum-Buffer-Rope: Resolving the Capacity Utilization vs Reliability Conflict in Manufacturing Schedules

Conventional Operational Methodologies The concept of ‘division of labor’ was THE single idea, which revolutionized industrial manufacturing. This idea of having each step of entire production process dedicated to a type of operation is still how manufacturing plants are organized (Heizer, 1998). With the evolution of new manufacturing techniques, manufacturing plants became increasingly complex in… Continue reading Drum-Buffer-Rope: Resolving the Capacity Utilization vs Reliability Conflict in Manufacturing Schedules

Not so Agile

In Greek Mythology, Procrustes, a bandit, killed his victims by force–fitting them into a standard iron bed. If the victims were shorter than the bed, he would forcefully stretch them; if taller, he would cut off their limbs as per the size of the bed.

This torture technique can be compared to how a predefined standard scale is used to forcefully “size up” work in an environment of high variability.

Sprint-based agile methodology of software development is suffering from the Procrustes Phenomenon. This concept’s boundary conditions of applicability are highly limited in the real world. To understand why and how, one needs to go back to the history of software project management processes.

The Dubious History

The history of software projects delivery performance is dubious. Probabilistically speaking, as per the annual Chaos Report , software projects are most likely to fail in terms of cost, quality and timelines. Interestingly, the1 trend has remained the same through the years.

There is now wide spread consensus to declare Waterfall Methodology of software development as a major reason for the poor track record.

Problem with Waterfall Methodology: Process Over Speed?

The waterfall methodology meets two main objectives in software development projects

  • Ensure clear accountability in relationship between supplier (one who is developing the software) and the customer (one who will use it)
  • Ensure process is highly stable, and that level of rework is minimal

For the first need, freezing requirements before starting the project is an absolute must. Once requirements are frozen, the accountability for any effort or time overrun can be clearly traced back to either of the stakeholders.

The second need requires one to approach software development like one would development of a new physical product. Developing a new physical product requires the design to be complete before start of the actual building. Allowing the design to remain fluid during implementation leads to uncontrolled rework and interruptions.

Borrowing from these principles, a waterfall methodology requires one to move the project into following phases sequentially with clear “gates”, marking completion of each phase

  1. Requirements
  2. Design
  3. Development
  4. Testing

Strict change management processes are to be put in place as a “deterrent” against any rethink late in the process. As a result, one of the overheads of this methodology is lot of documentation and sign-offs.

However, when the customer-testing phase comes at the fag end of the entire project, “hindsight” clarity issues create severe conflicts between customer and developer on what was “told” initially in the requirement phase and what was “understood”. So, practically speaking, a strict change management process becomes difficult to implement, more so when the relationship between customer and supplier is that of unequal. Resultant effect is scope rework detected too late in the process, leading to uncontrolled delays. It is no surprise that contractual conflicts, delays, effort spiking and associated stress towards the end of the project are chronic to software development projects.

Agile Development: Speed over Process?

In sharp contrast, as the proponents claim, Agile Methodology takes a viewpoint that scope and design cannot be frozen upfront. Hence, it adopts a flexible working approach, which can embrace change much later in the development cycle. Instead of taking a “one perfect project delivery” viewpoint of software development, Agile believes in the principles of delivering usable features, good enough for customers to start using, and then keep improving based on frequent feedback. The idea is to deliver workable software as soon as possible and get feedback for further iterative development. This way of working also takes away the need to freeze requirements and design upfront.

So, in the agile world, one can move away from sequential working between phases of software development. The team can work as a self-organizing group, which can design, develop, test and deliver workable features in an iterative manner. Time is managed by using concept of sprints (widely used version of Agile called Scrum) – a “time box” of 15/30 days, is used to deliver small batches of usable software features. While the ongoing sprint is frozen, subsequent ones can be changed based on customer feedback.

The “Not So” Silver Bullet

The silver bullet has been found. Or so, it seems. However, no conclusive, transparent and nondebatable study is available to establish the supremacy of Scrum Methodology

Beyond the data, what is of concern about Scrum in specific are growing voices of practitioners against the methodology. Numerous blogs have been highlighting the increasing stress of developers, the ever-lengthening list of bugs’ backlog and customer dissatisfaction on usability of software. Surprisingly these effects are exactly opposite of what Agile had promised!

As a counter argument, proponents of the methodology have pointed out that implementation gaps, not conceptual gaps, are the primary reason for the woes.

The argument of implementation gaps puts the onus of the problem of poor results on the abilities of the implementer rather than the inventor. (“They couldn’t implement – they were not disciplined!”). This narrative allows some management theories to stay as fads, longer than they really deserve to. So it is important to verbalize the hidden assumptions (or the boundary conditions) of a theory and check its validity in the practical world.

Flawed Assumptions

A widely cherished principle of agile is “self-organizing teams over strict processes”. The signoffs/handovers/checks or any kind of formal control for sequential movement as per a process is scoffed at, as self-organizing and iterative development becomes the guiding mantra.

The resultant effect of any agile intervention is the re-organization of a functional structure of design, development and testing into many small self-organizing teams, which are expected to be self sufficient in terms of skills of design, development and testing.

This assumption of self-sufficiency of small divided teams in terms of adequacy of high-end skills, particularly designing and requirement assessment is highly questionable in vast majority of environments. High attrition rates, with many developers changing jobs every two to three years are hard realities of the industry, which is obsessed with outsourcing and reducing cost of development. The high attrition rate does not impact availability of generic skill resources like expertise of a programming language. But environment specific skills like design and requirement analysis which is only acquired with adequate experience, are never available in full strength as required by the multiple decentralized agile teams. These skills (also called SMEs or subject matter experts) are always part of a miniscule minority in most environments.

So it is highly likely, with skills decentralization after an agile intervention, that many agile teams will fall short of skills, particularly those contributed by experienced SMEs. Even though, each team may have the required numbers to be declared “self-sufficient” as per records.

This leads to a situation where some agile teams depend informally on others, outside of their team, for help. With decentralization, some teams also become ignorant that they need help outside of their structure! Without a formal process to control sequential movement, the first casualty is adequacy of design and requirement assessment. Hence, testing becomes the primary source of feedback on design and development gaps.

Consequently, frequent re-work becomes inevitable. The lines of codes for same functionality are written many times over in an agile environment. At the same time, continuous “flow back” from testing causes frequent interruptions with developers. The problem of interruptions and rework further aggravates when different small agile groups are working independently on different sets of features in parallel; design decisions, at times, become “local” which cause conflicts between teams and create further rework.

The few SMEs or designers in some self-organizing teams become overloaded. These scarce resources are forced to multi-task beyond their capacity; they have to not just work within their team but also get into issue management of other teams. This further deteriorates the productivity of the system as everyone waits for feedback from heavily loaded resources. End result is an uncontrolled development process.

Agile has an antidote for this inherent chaotic working approach – sprint deadlines. Like Procrustes’s standard iron bed, the sprint cycle deadline force-fits open work fronts into closures. Effort spiking close to sprint end pushes everyone to somehow drive closures and complete the sprint. But the efforts spiking compels compromises – some testing is skipped or some bugs are kept aside, some scope is set aside for later sprints – the same way Procrustes force-fitted human bodies into beds. As almost all resources in the team become extremely busy towards a sprint closure, any planning activity of subsequent sprint is put off to the start of the next sprint.

Consequently, in every sprint, initial time is used up in planning work. Actual development and testing happens towards second half of a sprint cycle, thus building pressure of time, followed by skips and misses. Testing resources stay less utilized during beginning of a sprint and then get overloaded at the end, where all planned features land up together. Sprint end rush and compromises becomes inevitable! The damaging effect of “forcing” a standard sprint cycle is not just seen in execution but also in planning. The arbitrary “cut” of deliverables based on a standard time, at times, lead sprint managers to size out work, which may not be usable at the end of the sprint.

When execution is chaotic, and features coming out from a sprint cycle are not “usable”, the predictability for end customer is lost, particularly for those who might want a firm release schedule for a set of usable features to plan their own projects.

So, in many environments, it is not uncommon to find a hidden waterfall methodology-based project management imposed upon agile working. The resultant effect of this dual environment is a situation, which imbibes the worst of both solutions in terms of productivity losses.

The Hybrid Solution

Typically, an overall project plan is created for “final release” for customer commitment. The longer-term plan is broken into “sprints” with every sprint having its own predefined scope plan. The commitment to end customer is the final release. Sprints turn into typical milestones of an overall project schedule.

When many series of consequent sprints are pre-defined with scope, flexibility to re-scope or repeat a sprint based on feedback of previous sprints becomes nearly impossible. So after every sprint, the pressure is to work on scope of next sprint rather than to deal with feedback/issues of the previous one.

This creates an ever-increasing bug list and leads to massive effort spiking towards the end of the “final release”. Some companies leave aside a time box of “final sprint” before final release to clear all the old mess of previous sprints. So in the real sense, customers don’t get anything usable till the final release.

At times, even the “buffer” of one sprint is not enough to make up for all the past sins. Less available time, pressure to deliver and overload of pending work is a perfect recipe for more compromises. Bad quality products are likely to be delivered to customers who report the bugs back to the development team. Pressure to expand the team to tackle the huge list of bugs of previous releases while developing for new releases increases the cost of development. Stress, poor productivity, delays and bad quality cannot be a rare phenomenon in such an environment.

At the same time, when an overall release project is super-imposed on agile cycles, the typical initial waste of time and development capacity spent in assessing the entire project efforts, scope and plan, negotiations becomes a reality. Software development companies lose out from all sides.

Agile Vs. Waterfall: Solution of Extremes?

One the assumptions of 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 something. At the same time, the need for perfection or the “best” can make the requirements phase go out of control. Hence, Agile did away with the overhead of trying to be perfect in design and requirements gathering.

But at same time, Agile implementations also suffer from bane of inadequate designs. What we have now is a more generic conflict underlying the software development process.

  • On one hand, we should freeze designs and requirements before implementation because this approach ensures rework is under control and hence, time is under control.
  • On the other hand, we should not freeze design and requirements because it is impossible to freeze them. Users get clarity on what they actually want after using or visually observing the product.

The only way out of the above conflict is to understand that there are clearly two types of rework which gets generated in any new product development process.

Type A (Foresight-led rework): They are misses and skips made under pressure of time and lack of synchronization between team members. Some people in the team know about these inputs. Due to pressure of time, these inputs are not incorporated in time; this leads to rework later in the process. These errors cause frustration among team members for missing the obvious. Using testing resources to get feedback on Type A errors is a criminal waste of time and capacity.

Type B (Hindsight-led rework): This is rework created due to new knowledge generated after an event of testing or clear visualization. It is in a way value adding, because new knowledge is generated in the process. Prototypes generate Type 2 value-adding rework. Type B rework is inevitable and no amount of thought experiment can help one visualize the Type B errors upfront. The only way out is to devise a process to generate Type B errors early in the development cycle.

Waterfall Method implicitly assumes that all errors are Type A and hence should be prevented. This school of thought has inspired the manufacturing slogan “First Time Right”. Process rigidity with checks and “no-go” gates becomes the key to avoid Type A lead errors. Agile assumes all errors are Type B, hence it considers one-time handovers between phases as waste of time. Hence agile propagates frequent back and forth between all phases.

Learning from History of Automobile Manufacturing

Interestingly, this “Agile” way is exactly how automobiles used to be manufactured in late 18th century. It was called the craft manufacturing method. A small group of mixed skill resource groups were each given a car to be assembled from start till end. The cross-functional team had skills of design, fitting and even machine operations. The not-so-perfect parts could be filed and adjusted to fit with each other, and eventually a vehicle would come out with arduous rework. This way of car manufacturing was indeed very expensive and only the rich could afford it in that era.

When Henry Ford presented the assembly line concept with clear division of labor, car assembly was transformed. Clear sequential working with different resources specializing in different types of the assembly task, defined the assembly lines of Ford Motors. The cars moved between stations (instead of the workers moving) for continuous flow of output. The specialization on one type of task, along with avoidance of switching losses (of craft manufacturing) between different types of skill work enabled a productivity jump of close to five times.

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.

However, an assembly line working approach requires two critical conditions to be successful

  1. 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, then it can create chaos with uncontrolled line stoppages and reduced output. (In such an environment, craft manufacturing, or the agile method, is a better way). In case of Ford , assembly line working was enabled by standardization of parts, which could fit any car, without the need to file and adjust ill-fitting parts for a specific car, thus preventing the flow backs
  2. Transfer batches should be small (ideally a single piece flow). Transferring of big batches not only expands lead-time in every stage but also leads to late detection of quality issues.

Rapid Feature Flow Model

Let us examine how we can get above two critical conditions to resolve the inherent conflict of software development process.

1. Minimizing Flow Backs

Organizing resource groups into requirements assessment team, design team, development and testing group help create required division of labor for assembly line working. This allows the limited expert resources to be centralized in the requirements and the design groups. This grouping also helps in proper utilization of their capacity in type of work, which requires their expertise. However, without clear definition of what constitutes end of requirement and end of design, the assembly line type sequential working between resource groups will never materialize due to flow backs. It is also important to put up a process of check to mark completions – this is imperative to break the bad habit of proceeding without completing the phases.

Requirements Phase

This phase should focus not only defining what should be done in a feature but also defining what will not be given. It is also important to begin with the end in mind. The inputs of all test cases to be used in the final validation should be defined. At times, visual prototypes can also help customers visualize what they really want.

Design Phase

A high-level dependency understanding at an architectural level is usually done in many environments by using the first few sprints, (called the foundational sprints). Dependencies which are neglected are in the subsequent functional sprints where features are delivered.

Design stage should focus on unearthing detailed dependencies in terms of interaction with different functionalities. Identifying verification test cases upfront in this stage makes sure that the gap related to any kind of dependencies which can lead to regression are minimized. In the absence of proper design, lot of capacity wastage can happen later in verification testing as fixing one issue might lead to breaking of other things, creating a vicious loop leading to unpredictability in flow.

The gates of design and requirements along with principle of “beginning with end in mind” should help in preventing type A errors and, unearthing type B errors early in the process.

(Interestingly, engineering of physical products focuses a lot on understanding dependencies as the cost of rework during product building phase is high. For example, if the design of beams needs to accommodate the load bearing capacity of a moving crane in a factory-building project, it is important such design dependencies are thrashed in the engineering phase. If the same dependencies are detected in execution for physical products, the huge physical waste of material becomes visible. However, in the case of software projects, wastages for bad design are never visible; a code going wrong can be re-written in the virtual world after it is detected in testing. No rejection of material or dismantling of build structure happens in the software development world. This inherent advantage of software development is also a bane. When testing is used for facilitating good design, the rework and loss of productivity is colossal, even if there is no loss of physical material).

2. Minimizing the Transfer Batch

Just having an assembly line with delivery coming out after a period of six months or a year is also undesirable. When different customers require different features at different points of time, having one delivery date for a large set of features is of no use to any one. It is unreasonable to expect the customer to wait till all other features are complete. So, moving individual features through the assembly line in order of priority (sequence in which features are introduced) ensures better flow and a short lead-time in delivering workable features that individual customers want.

The way to make a transfer batch of one feature is to institute a WIP (work in process) limit control in the different resource group types. The work in process control implies that a new feature will be introduced to the resource group only when one under progress is complete as per the criteria set for handovers. The rule of “one in when one is out” ensures a single piece transfer batch flow at a feature level. (Due care should be taken to define features in a way that they are fairly independent entities).

WIP control rule implies that tasks cannot be prescheduled or cut out using the “knife” of a time-boxed sprint. The rule of “one in when one is out” will ensure output of features in a staggered manner and that load on testing is leveled out. (Instead of wave of lumpy work for testing in a sprint-based scheduling.) The staggered flow prevents temporary bottlenecks in the system.

The WIP control also aids transparency of queues, which in turn helps in better capacity planning between resource groups. Skill group sizes can be adjusted time to time to manage any temporary elongation of queue. (Change in complexity of features introduced in the system or loss of resources in some groups can create temporarily lengthen queues).

The above principles will help in rapid flow of features from this system. The rapid delivery of individual deployable features also helps promote “a-version-at a-time” thinking approach in requirements phase to keep it under control. Customers (or marketers of the software) can keep improving the features by initiating work for the next versions.

The suggested model of working, however, has the following drawbacks

  • The rule of WIP control makes scheduling of tasks redundant. In the absence of a time schedule, predictability is lost.
  • It is in direct conflict with typical sales planning process of a product company that works on annual or bi-annual software release plans.

Improving Predictability

The above system exposes queues in the system and helps differentiate touch time (actual work time) from waiting queues. If the features’ content can be standardized as multiples of a unit work package, then it is possible to model the expected arrival time to provide the desired predictability. When flow improves, with drastic reduction in interruptions, priority changes and rework, the system predictability goes up many folds.

But it is important to use the scale of time to provide continuous predictability and not use it as a tool to drive “commitment” in execution or use as a scheduling decision. It is a fallacy that schedules, and commitment around schedules, prevent time wastage. In reality, wastage of time is prevented by daily process of issue resolution and close handholding by flow supervisors in respective groups.

The decoupling of prediction and commitment can be best understood with the analogy of driving using Google Maps. Google maps offer expected time of arrival looking at queues on road. But it is only a predictive tool, and the driver cannot commit on the time claimed by Google. What he can do effectively is only reduce wastage in every moment of driving. In case of an overall manager of a system, the focus of predictability improvement comes from reducing queues in the system, and managing issues interrupting flow on a daily basis.

In this model, a feature is introduced in the system without trying to cut it out based on some arbitrary sprint cycle definition. The feature size introduced in the system is based on what is deployable.

Dynamic Software Release Planning

The new model mandates that one move away from managing software development as a large monolith project with detailed plan aiming for a single release. Final releases can be done as frequently as one can manage based on the release overheads. Single features or a set of features can be bundled into releases as and when one wants. Instead of committing to a release plan upfront for a year, marketers of the software can decide on release strategy based on dynamics of the market. This provides necessary flexibility to react to competition strategy, and hence change the queue of features in the waiting list to deal with market dynamics.

To summarize, software environments have had a chronic difficulty of not being able to clearly differentiate two independent measuring scales required to manage projects effectively

  • Scale of time (to provide predictability of when something will be completed)
  • Scale of work to understand size

Both are different; they should not be mixed. Since defining a standard scale for work content has always been a challenge, using time (the sprint cycle duration) as the proxy scale to “knife out” work in planning and in execution is source of all problems in the scrum methodology. Hence, the Procrustes Phenomenon becomes unavoidable. The suggested Rapid Feature Flow model offers a way to differentiate the usage of the two scales to escape the wrath of Procrustes.

So what happened to Procrustes? His reign of terror ended with his death at the hands of Theseus, the king of Athens!

Case Study

Schneider Electric Engineering Workbench, a product from Schneider Electric’s Process Automation business helps in automating the engineering and configuration of the instrumentation and control systems of brown/greenfield projects. Faster engineering helps in reducing lead time to start of operations and thereby improves profitability and reduces the risks of penalties for the Automation vendor.The Agile methodology formerly in place for software development at Schneider Electric Engineering Workbench could not give the desired results. Therefore, the company innovated a flow model based on the core concepts of TOC for the automation software development process which not only created a more harmonious work environment for the development team but also increased productivity by a whopping 71%!

At the end of a year, Schneider reported the following additional benefits

Scientific Revolution, Disruptive Innovation and Theory of Constraints

“Innovation”, “Disruption” have been buzzwords for a while. Pundits remind us how Nokia, Kodak didn’t act on time and got disrupted into oblivion. These stories are scary enough to whip up board rooms into frenzied action. Top managements of large companies now seek to “act” and do something “proactively” before they become similar case studies.… Continue reading Scientific Revolution, Disruptive Innovation and Theory of Constraints

A new inventory management paradigm for made to stock companies

Any business which manages stock to meet customer needs faces a key challenge in stock management – i.e. how much to hold or in other words what is the right inventory. It would seem that almost all the mess of shortages and surpluses is caused by not knowing how much inventory to keep. The apparent… Continue reading A new inventory management paradigm for made to stock companies

Battling the efficiency syndrome. Effortlessly!

With implementation of Theory of Constraints solution, it is expected that all plant managers align their thinking and decision making to the paradigm of flow rather than local efficiencies . While it is intuitively easy to understand and appreciate the flow paradigm, it is very difficult to GIVE UP the efficiency paradigm. Not many production… Continue reading Battling the efficiency syndrome. Effortlessly!

Beating project deadlines, the CCPM way

Organizations dealing with projects often make the mistake of adapting the same best practices that have been evolved for operation or production environment. Despite knowing that the key commitments of project (time, budget and scope/quality) are all interrelated, control actions are taken as though each of these commitments can be achieved discretely. The framework of… Continue reading Beating project deadlines, the CCPM way

Beating the Recession Blues

Management consulting industry and all IT vendors in enterprise space, promising productivity improvement have a business cycle well aligned with the overall economy. They grow fast when the overall economy is booming and they get into trouble when recession strikes the economy. This looks rather strange. Logically speaking, this entire industry (dealing with productivity improvement),… Continue reading Beating the Recession Blues

To measure or not to: The danger of focusing on measures & targets

I was addressing an audience of top management of a company recently just before a new assignment was about to kick off. To my surprise one of the team heads at the meeting, informed me, a little belligerently and with very obvious ‘consultant fatigue’, that the ‘on-time’ performance at their company had recently jumped from… Continue reading To measure or not to: The danger of focusing on measures & targets

Egg before the Chicken?

Understanding why some CCPM implementations fail to deliver the promised results. The logic of CCPM appeals to common sense. The damages of bad multi-tasking and “date driven” behavior are irrefutable to a logical person. Every CCPM workshop is successful in conveying the logic of the new paradigms. However actual implementations have mixed results. There are… Continue reading Egg before the Chicken?

First among Equals: Marketing or Supply chain

For any company involved in manufacturing and selling of tangible products, both marketing and supply chain forms an essential aspect of business. A good marketing strategy involves the correct product placement, branding, promotions, advertising etc. Without such initiatives the product may not appeal or become known to the target segment. So it is natural for… Continue reading First among Equals: Marketing or Supply chain

Focus on longest path ≠ shortest possible lead-time

Every literature on project management reminds us that the longest path of dependent tasks determines the total duration of the project. Every practicing manager believes that delaying work on longest path damages the project time line. So, logically speaking, project management should focus on ensuring minimal delays on the longest path. With this strong intuition,… Continue reading Focus on longest path ≠ shortest possible lead-time

From Sales to Production – a tale of misaligned priorities

Far too many times, organizations behave like dysfunctional systems with their different arms working at cross-purpose to each other. I once had an opportunity to engage with a company producing and selling custom-built equipment for banks. The objective of the engagement was to identify ways and means of reducing their SG&A expenses, preferably through an… Continue reading From Sales to Production – a tale of misaligned priorities

Ignoring the Future

The Nano debuted in 2008. It was expected to be a historic event – the launch of the cheapest car ever to be sold on the planet. Auto analysts across the world prophesized the Nano would be a game changer for the Indian auto industry. CRISIL announced Nano would expand the Indian car market by… Continue reading Ignoring the Future

Is your Planning Method bloating your working capital Requirements?

Current downturn is putting pressure on companies not just to reduce costs but also to reduce the working capital requirements. A significant portion of working capital is money locked up in inventory in form of raw material, finished goods and work-in-progress. In most organizations, the typical management approach towards reducing the inventory is by target… Continue reading Is your Planning Method bloating your working capital Requirements?

Why management by objectives is flawed?

Driving Outcomes Vs. Driving Enablers One of the pre-dominant styles of conventional management is MBO, management by objectives or results. Whenever a problem is seen, it is common practice for top management to set an objective – a target for improvement with a timeline, assign responsibility and subsequently measure the variance after end of a… Continue reading Why management by objectives is flawed?

Managing Call Centres : A Logical Approach

Easy customer accessibility to an organization always becomes an issue when the organization grows up in complexity, in terms of geographic spread, organization structure, products and processes. Call centres have been successful in providing easy accessibility amidst the complexities of an organization. (Often with single, easy to remember contact number to contact the organization) Today… Continue reading Managing Call Centres : A Logical Approach

Restoring Harmony in Manufacturing Plants

Does TOC bring harmony among people? Let us first define harmony. It’s about getting consensus, agreement on a topic. There are no conflicts. I am sure most of you must have observed and experienced the extent of disharmony that exists in any organization. There are almost daily fights/disagreements/arguments between people from various departments. It could… Continue reading Restoring Harmony in Manufacturing Plants

Sales team – A very obstinate lot!!!

Sales teams are primarily concerned with doing their budgeted targets for today and refuse to see more than year into future and that is also stretching it. They blame the distributor for non-adherence to sop’s, blame the top management for confusing priorities, and project obstacles (mostly concerned with other departments) to show how their environment… Continue reading Sales team – A very obstinate lot!!!

Simple Tactics to Double Team Productivity: The science of getting work done on time

In organizations, leaders must get tasks done through their team members. On the surface, this appears to be an easy thing to do, as leaders have formal authority over their team members (by virtue of organizational hierarchy) and so, can simply issue orders to get things done. However, a survey of team leaders across companies… Continue reading Simple Tactics to Double Team Productivity: The science of getting work done on time

Theory Of Constraints and the Thinking Process

1.1. Background and underpinnings of the TOC thinking process Though Theory of Constraints was originally offered by Eliyahu Goldratt as a manufacturing scheduling method, over the course of his career, Goldratt evolved TOC into a systems methodology which encompasses a wide range of concepts, principles, solutions, tools and approaches that strive to ensure any change… Continue reading Theory Of Constraints and the Thinking Process

Thinking Clearly

This Blog is inspired by Eli’s speech in 2009 TOCICO Tokyo Conference and Nassim Taleb’s Black Swan Let us see how “experts” in business conventionally analyze situations. They go around departments and ask people for problems, do a gap analysis ( with help of some benchmarking data)and then they arrive with solutions, almost one for… Continue reading Thinking Clearly

To batch or not to batch

Batching issues tend have a profound influence on the flow characteristics of a manufacturing plant and substantial gains can be made by properly understanding underlying principles. Almost all kinds of automotive operations are associated with large batching operations. The following are the commonly found large batching operations in the automotive manufacturing units: Forging – Forging… Continue reading To batch or not to batch

Aftermath of Demonetization in the Aftermarket

Published by ETAuto.com, 19th January 2017 According to RBI data, 90% of all transactions in India are made with cash. A little over 80% of this cash became practically useless overnight after Rs1000 and Rs500 currency notes were demonetized on November 8 this year. This withdrawal of legal tender status of these notes came as… Continue reading Aftermath of Demonetization in the Aftermarket

Parag Milk Foods: From “Push” to “Pull”

Parag Milk Foods announced the results of its new sales pilot after it rolled out TOC Pull distribution solution to provide very high availability at lower inventory while simultaneously improving freshness of products at retail points.

Published
Categorized as News

Reclaiming Global Leadership in Textile Manufacturing

In an interview with Fibre2Fashion, Satyashri Mohanty discusses how Indian textile is losing its “cheap labor” based competitive edge and how exporters have no option but to make a huge paradigm change to regain a compelling advantage in the international markets.

Published
Categorized as News

Resolving the Grapple through TOC

With growing number of industries and business firms, the diversity in the constraints is also growing. Some organization find their way out of the pitfalls where as some grapple with them. Theory of Constraints (TOC) as a reliable solution has benefited largely to these organization. Walking us through the factors associated with the application of TOC and its prevalence, Mr. Satyashri Mohanty, Founder Director of Vector Consulting Group gives us real glimpses of industry.

Published
Categorized as News

VCG is 2015 AMCF Awards Finalist

Finalists Change Management EY with Fannie Mae EY with Monsanto JMW Consultants with Z Energy Corporate Social Responsibility EY with ConAgra Foods KPMG with Ambuja Cement Tata Consultancy Services with Child Maintenance Group Customer Engagement EY with Medtronic Gulland Padfield with Silicon Valley Bank – Asia Tata Consultancy Services with Hilton Grand Vacations Company Developing… Continue reading VCG is 2015 AMCF Awards Finalist

Published
Categorized as News