is a neglected factor in overall efficiency and needs adoption into the new age of work
Technological change, talent scarcity, and rising cost pressure demand smarter planning and use of R&D resources. In today’s world of innovative technologies and changing business models, estimates from previous projects are no longer sufficient to assess tasks for the future. Especially not with the shift from hardware- (HW) to software- (SW) driven products. In terms of resources, employee utilization and time spent across the product development process (PDP), are crucial cost drivers for OEMs and Tier-x suppliers in R&D. In this paper, we want to elaborate the current flaws and future challenges of effort estimation across the PDP.
In the automotive industry, the PDP provides guidance for planning and managing the workforce. Considering its length, hardware orientation, and complexity, this habit can, however, be a root cause rather than a solution.
1. False sense of predictability
OEMs and their products are built on long development cycles and structured to meet milestones, creating a perception of high predictability and transparency. However, this method overstates the accuracy of planning and effort estimation. Designed for hardware products, these processes struggle to keep up with fast-moving software demands. These lengthy processes make it difficult to adapt to rapidly changing conditions, such as new regulations, shifting customer demands, or varying tariffs. A more adaptive and agile approach is needed to balance structure with responsiveness.
2. Effort estimations based on individuals’ experience
At the beginning of each new development project, effort need to be estimated for all the systems involved. In most cases, estimations derive from individual experiences rather than data-driven methods. These estimations often follow a rule-of-thumb approach or use reference statements of work (SoW) from previous projects, which do not suit the current assignments. Due to time constraints in the development schedule and limited experience with emerging technologies, new effort estimates tend to be ignored and those gained from previous experiences are used instead.
3. Continuous software development adds more pressure to resource estimation
With the growing use of software, hardware and software development become increasingly decoupled and run on different timelines. Moreover, software development does not end at the SOP and requires continuous updates up to the end-of-life phase and cross-program reuse. This fact alone calls for action as traditional PDPs do not cover this aspect of product development and the required updates.
Our first hypothesis is based on the product development process:
(H1) Slicing the product development process into shorter intervals with respective effort estimations will improve overall resource estimation.
Accurate effort estimation is driven by the availability of specifications. Therefore, unavailable or incomplete requirements negatively impact the accuracy of effort estimation. Yet, the required resources are evaluated on time as the milestone-oriented delivery needs to be served. This rigid approach does not account for the evolving nature of product development, where time, effort, and complexity increase in curves, while budget and resource planning remain linear and set since the beginning. OEMs struggle to define detailed specifications of their product, while Tier-1 suppliers face difficulty in determining their own resource needs without precise specifications. This misalignment leads to a bullwhip effect, where incomplete requirements often result in overestimated effort.
Therefore, we summarize in our second hypothesis: (H2) earlier supplier involvement improves requirement quality and reduces reworking.
Both OEMs and Tier-1 suppliers struggle with sufficient transparency in terms of capacity utilization. Teams often juggle multiple projects with shared components, making it hard to allocate resources correctly. Cost center-based tracking offers insights into the real workload, but is limited by administration and flawed workflows.
To summarize, our third hypothesis (H3): improving resource tracking and digitization capabilities will enable the more effective management of resources.
Increasing the efficiency of R&D departments is fundamentally dependent on the rationally planned and correct use of resources. Achieving this goal necessitates a complete rethinking of established resource management and allocation systems. Below we present levers relating to our three hypotheses to enable more precise yet flexible planning.
Figure 1 – Different approaches to effort estimation
Source: AlixPartners, Berylls by AlixPartners
Decoupling of effort estimation and project budget
One method of improving resource estimation is to decouple effort estimation from the constraints of a pre-determined project budget. Traditional project management suffers from the imposition of a budget before understanding the project’s requirements, which can lead to inaccurate estimations. Instead, we advocate for a data- and requirements-based planning process. This approach begins with a detailed analysis of project requirements, leveraging existing empirical data and historical values to inform effort estimations. A centralized data collection system is crucial for this approach. The focus should be on creating a comprehensive plan that accurately reflects the resources needed to deliver the desired outcome. Once efforts are substantially estimated, strategic decisions on pricing these efforts to the customer can be taken. This strategy will avoid setting a spiral of overestimated efforts and budget cutbacks in motion. While budgets are essential for maintaining financial discipline, they should not dictate the estimated effort required. The budget should be a result of an exhaustive assessment of project requirements, not the other way around.
New methods of effort allocation
The shift towards modular development, characterized by the cross-program usage of software components and continuous software integration, necessitates novel approaches to effort allocation. Traditional project models often struggle to account for the shared effort in modular systems. We advocate recognizing the reusability of software components. This can be achieved, for example, by adopting a “60% standard and 40% customized product components” approach. This strategy acknowledges that a significant portion of the software development effort is directed towards reusable components (the 60%), while the remaining effort focuses on customizing these components (the 40%).
This requires a mechanism for tracking the development of reusable components. One method is similar to the allocation of overhead costs. Another could involve establishing a dedicated “base software development unit” responsible for creating and maintaining the reusable core software. By adopting these levers, organizations can gain a more accurate understanding of the actual cost of software development in modular systems, leading to improved resource management.
Democratizing planning activities
Current effort estimation relies on information held by a few individuals. A more effective approach democratizes planning by leveraging the distributed expertise. Using the appropriate tools, expert stakeholders can be engaged directly in effort estimation, yielding more accurate project plans.
This democratic approach is supported by a project archetypes library. Completed projects are deconstructed and categorized into these archetypes, which offer pre-defined task breakdowns, estimated effort levels, and resource requirements. These archetypes serve as baselines and are adapted with real data after completion to avoid past mistakes in effort estimation.
Figure 2 – Using archetype approach in effort estimation process brings several benefits
Source: AlixPartners, Berylls by AlixPartners
Falsely assumed predictability can be addressed by slicing one large process into a number of smaller pieces
The idea is to replace the illusion of long-term certainty with iterative adaptation. By dividing the project into smaller, manageable intervals, organizations create opportunities for regular re-assessment and course correction. Each phase is characterized by clear objectives agreed upon between the OEM and the Tier-1 supplier, defined deliverables, and scheduled review milestones. At the conclusion of each phase, progress is rigorously evaluated against the original plan, and adjustments are made based on newly acquired information and insights. This phased approach 1) minimizes the impact of unforeseen events by limiting the scope of each interval, 2) enhances visibility through regular reviews enabling early problem detection, and 3) fosters adaptability by allowing for plan adjustments. Most importantly, as the project progresses and more data are generated, estimation accuracy for subsequent phases improves. Ultimately, slicing the automotive development process into various phases transforms the project from a rigid, potentially flawed, long-term forecast into a flexible, data-driven journey. As a consequence, contractual agreements over lifetimes need to be defined and executed differently than today.
Continuous requirements derivation “continuous strategy phase”
Instead of deriving the full set of requirements at the beginning of a new project, a subsequent approach is needed that makes it possible to deliver requirements frequently without disturbance. These new requirements are agreed upon with the supplier in pre-defined timeframes. For each planned iteration according to agile setting, the requirements are frozen and estimated and budgeted. By doing so the complete system reaches a state in which requirements are mutually agreed between the OEM and the Tier-1 supplier for each planned iteration and later change requests are avoided. However, as development is still an incremental activity in which each step builds on the preceding one, changes cannot be made without considering the previously agreed specifications. To circumvent this issue, both parties need to define “corner cases” of the later limited performance bandwidth.
Requirement breakdown across standardized structure and processes
To reduce changes in later process steps and increase overall transparency, we propose conducting the requirement breakdown along with standardized (product) structures and processes. On the one hand this serves as the basis for proper effort estimation, on the other hand it creates the basis for problem-free integration as it means that only specific requirements are tested at a certain integration level instead of testing the complete requirement set at oncein one process.. Code beamer or Jama are suitable tools that could be used in this situation. Such tools link requirements to test cases. By doing so, if changes are needed at a later phase, the requirements in question can be easily identified and the affected product specifications adjusted and tested at the end of the process. In order to gain the benefits of this lever, a system-level structure and integration plan needs to be in place.
Structured data form the basis for creating transparency on own workload situation and conduct effort estimation
R&D managers lack transparency in their teams’ current projects due to the prevalent use of incorrect project codes. To address this issue, effort should be tracked by role, workload, and demand, critically supported by closing old project codes and enforcing the use of current ones. Tools such as JIRA and SAP can facilitate the process by recording the actual effort, thereby creating the harmonized data structure essential for reliable estimation.
(Project) organization mirrors customer’s product structure
To allocate and track resources even more accurately, we recommend establishing an operating model which reflects the (customer’s) product structure to some extent. Therefore, if a new, software-oriented product is to be developed, this needs to be reflected in the organization. Otherwise, information, transparency, and efficiency will become lost in translation as they cannot be transmitted to the customer. Without having the same structure, there is likely to be confusion in allocation and estimation.
As mentioned above, available resources are limited. OEMs and Tier-1 suppliers need to reduce costs in order to remain competitive while working on different technologies and projects. Therefore, a holistic approach is required to exploit the potential outlined here and reduce the overall required efforts compared to the regular resource approach (see figure 3). Individual measures alone cannot achieve their full effect. We recommend launching a holistic transformation program focusing on resource management in R&D.
Figure 3 – With the laid-out levers, R&D departments can reduce the overall Efforts during development and “flatten” the curve usually spiking at the end of a project
Source: AlixPartners, Berylls by AlixPartners
1. Re-evaluate the lengthy and fixed PDP. The phased approach will increase the accuracy of effort estimation while reducing the required resources in total. In addition, we suggest investing in data transparency for resource utilization and allocation.
2. For OEMs specifically we suggest redesigning requirement processes to enable continuous alignment. Structure organizations to decouple HW/SW and involve suppliers earlier to ensure clarity and reduce change effort.
3. For Tier-1 suppliers we propose aligning their organization or operating model with the product structure of the clients. This setup will enable proper requirement breakdown during the RfI (request for information) and RfQ (request for quotation) phases. To work across clients, the main lever will be the establishment of a democratized, data-driven approach for effort estimation as set out in this study.
Copyright Berylls by AlixPartners
