The auto sector in India is one of the most hotly contested market spaces. This is because per capita vehicle ownership in India is still very low, leaving a substantial gap between the potential demand for auto products and their supply. The Indian passenger car market alone is expected to reach USD 60 billion by 2027. To thrive in this sector, a typical auto company must meet three primary needs:
- Continuously launch newer variants of its current models with reasonably high frequency.
- Frequently introduce completely new platforms or brands to address new consumer segments. Interestingly, each new platform or brand will also require its own variants after launch.
- Comply with new regulatory requirements. Undertaking these regulatory projects quickly and in a timely manner is a significant challenge for any automaker since failure to meet them could result in halted production, lost sales, and diminished market share.
Meeting all three of these needs without multiplying investment in resources is the primary challenge of any auto NPD (New Product Development).
How do companies currently try to make sure that all these projects are done on time?
Companies typically adopt a conventional approach: they set the project deadline and then work backwards to determine the start date. Historically, the more delays a company has experienced in previous projects, the earlier it tends to initiate work on new projects. This is done to provide themselves a buffer against future setbacks.
At the same time, companies also believe that more reviews & proactive monitoring of timelines will ensure better control of projects. Therefore, timelines are monitored more strictly than ever, and project reviews are becoming more frequent. However, soon they realize that these proposed solutions end up contributing to the increase of problem-project delays or their scope compromised to meet deadlines or both!
Question: Why do we claim that starting projects early does not lead to faster completion, especially in an environment where we see constant delays? It seems logical!
Let's consider an environment where to begin with, projects are habitually delayed & project completion rates are already poor, indicating that, on average, projects are spending more time in the system. Now, against this backdrop, if we adopt the solution of initiating newer projects earlier than before in order to buffer against likely delays, we see a faster infusion of newer projects in the system while older ones are still stuck inside. These newer projects, in turn, divert the attention & capacity of resources away from projects already in the system, leading to further slowing down of all projects. This is especially true of NPD environments where resources are shared across projects in many teams. This slowing down of projects further drops the completion rate and leads to further build-up of WIP in the system and so it goes on.
Therefore, the so-called solution becomes counterproductive to the system output.
In many organizations, capacity is always planned based on the number of skilled people and machines required compared to the expected load of projects. Why is that a problem?
In any production environment, which is highly repetitive in nature, the output of a machine can be used as an indicator of capacity—both current and future. For example, a CNC machine can produce a specific number of parts within a given time period. However, this approach does not apply to a designer working in an NPD environment.
In an NPD (New Product Development) environment, it is challenging to define capacity based on the predicted output of a skilled resource because:
- The work in this environment is largely non-repetitive. By definition, every project executed in an NPD environment differs from the previous ones.
- Given the non-repetitive nature of the work, the output cannot be predicted as it depends on a multitude of factors that vary across projects, such as complexity, the experience and expertise of allocated resources, and the level of collaboration among team members.
- Consequently, any capacity planning juxtaposing current resources' predicted output against future project demand can go awry. We may end up either adding too many resources or too few—sometimes both, in different teams.
- If we under-plan for resources or load too many projects simultaneously, it can lead to resource switching, poor collaboration among resources, delayed issue resolution, and ultimately, a decrease in project output. This contrasts with a production environment, where overloading a machine results in a queue without affecting the machine's output. In such environments, people are typically less concerned about overloading and may even add more to avoid potential downtime.
- Conversely, loading too few projects can lead to resource underutilization and a drop in output.
- Additionally, resource-loading software often fails to address these complexities and can produce significant errors.
As I mentioned, predicted output method fails because predictability of a project system is always limited. Therefore we need a system which can guide us to load just the right amount of projects without causing either overloading or creating starvation of resources.
Here, rather than looking for a surrogate measure for capacity, using the no. of projects as a measure of capacity serves us very well. So capacity in project environments is defined as the max number of projects than can be executed simultaneously without any loss of speed. Any addition of projects beyond this capacity would result in a slowdown of projects and drop in the system output. For any system to be stable, this number has to be kept in control.
How do you arrive at the right number of projects to be worked on at a time?
The right Work In Progress (WIP) level is not a single optimal point—it is as many projects as the expert resources, who are few in most systems, can handle. This means expert resources' capacity determines an NPD system's output. The good news is that we don't need to be perfect from the start; we can begin with a number and adjust it gradually over time.
In most environments, we reduce WIP by as much as 70 to 80% and maintain it at that level. When we applied this strategy and other solution elements to a two-wheeler manufacturer, we saw a dramatic increase in output. Within two years, the number of projects launched year-on-year increased by 500%, and lead time was cut in half. They were also able to meet regulatory requirements on time, which saved a substantial amount of money on write-offs—a common issue in the past.
(Disclaimer: Vivek Chopra is Partner, Vector Consulting Group. Views are personal)
Disclaimer: The copyright of this article belongs to the original author. Reposting this article is solely for the purpose of information dissemination and does not constitute any investment advice. If there is any infringement, please contact us immediately. We will make corrections or deletions as necessary. Thank you.
