Many organizations have created significant business benefit by decentralizing R&D and innovation functions, thus improving the contribution of innovation to business unit performance. However, this often creates a conflict of ownership, as the alignment of R&D activities with corporate strategy then needs to be dealt with at group level. Frequently, the responsibility for alignment between corporate strategy and business unit innovation and R&D lands with the CTO, who needs the right processes and tools to achieve this. Making the right tool choice is key to ensuring the optimal balance between sector-level autonomy and group-level alignment.
The CTO’s role
R&D in large organizations ranges from fully centralized to fully decentralized (see below figure). Increasingly, organizations are adopting a hybrid or decentralized option, carrying out a significant amount of R&D activity within the business units (BUs). Such organizations often include a CTO charged with creating alignment across R&D/innovation activities, which typically include creating a common vision/strategy for the group to:
- Leverage common resources
- Create value through the combination of different divisional capabilities
- Create transparency to align the overall R&D portfolio with the organization’s strategic and growth objectives
In selecting tools to help align decentralized and hybrid R&D activity, CTOs face a challenging variance in process maturity among technical areas – from standard phase-gate approaches (e.g., most engineered products) to options valuation (e.g., most pharmaceutical research). Furthermore, CTOs often have no direct reporting lines from the different technical areas. Instead they tend to work in a power matrix where their influence achieves alignment through dialogue.
Existing project management systems often struggle to provide meaningful R&D insight
Many existing project management systems were designed for backward-looking financial reporting, not to provide the insights required for a shared approach to R&D/innovation. These systems lack sufficient clarity on the portfolio of innovation projects that enable senior leadership to understand how R&D/ innovation can close the growth gap and what new activities should be targeted to improve these efforts. Even when current systems can provide this type of data, adoption of the necessary R&D processes remains relatively low. As a result, the business struggles to establish a coherent overview of its R&D portfolio and usually lacks the functionality to adequately flag risks or requires integration with a risk management platform.
Systems not designed to automate portfolio reviews are typically not updated frequently enough, so any attempt to review activities across the portfolio can result in a hasty push to update data at the project level. The limited validation time is compounded by program leaders’ underestimation of the value of the portfolio review activity. They question the value of providing additional data that will require different ways of working and assessing projects to make more informed portfolio decisions.
Better system configuration is needed
If the management system isn’t giving you the answers you need, we have found that two things are required. The first is a project management system that is flexible enough to handle the differences across divisions and capable of aggregating information across projects. It also needs to create value by addressing users’ issues. The second is an innovation management and governance system that recognizes the decentralized nature of many companies but creates sufficient common ground so that activities can be described in the same language.
If existing tools cannot deliver authoritative and up-to-date data to the CTO, the organization should consider other options. However, getting a handle on the portfolio does not necessarily require very elaborate project management tools. More lightweight and cost-effective solutions are available.
A major problem with the more traditional, monolithic systems is the need to import R&D best practices with the system. Frequently, these systems prove to be a bad fit with the diverse needs of the organization. Instead, the organization’s needs should be captured upfront and should form a core part of the selection process.
There is a trade-off between the level of customization required to work with existing processes and ways of working versus importing best practices from vendors experienced with R&D that can provide standardized approaches.
Aim for a “single source of truth”
The introduction of a new system is an excellent opportunity to rethink R&D management. A cornerstone of this approach is moving towards operating a “single source of truth” for data used at all levels. Often the project management system is best placed to assume the role of “single source” or master system, as it is where project-level data is updated regularly. The system then feeds data externally linked to reporting cycles and phase reviews, the frequency of which are best driven on a per-project basis. This approach means there is never a “real time” view of the portfolio, as all the visualized data is based on the last formal review for each project. The trade-off is higher-quality data that is automatically maintained, so you can track and review the portfolio performance without requiring a flurry of activity. There is also a reduction of “garbage in, garbage out,” as all project performance data has been reviewed as part of a go/no-go decision point within the BU.
Select the right tool for mass adoption
Changing existing ways of working and expectations for reporting are likely to be met with resistance from the BUs. To counter this, the selected tool must provide a meaningful improvement to the current process for the end user. It cannot be simply an additional top-down reporting requirement that only benefits management. It is then critical to clearly articulate this value to project managers and end users.
To achieve this, our preferred approach is to operate an initial review of existing R&D management practices to surface the needs of the different users and ensure that the system’s selection and design accommodates both the variability in processes across divisions and the specific needs of different user personas (see above figure). For example, in one project a benefit of the new software was that entering and using the data created automatic generation of project management data for reporting, thus saving project managers several days a month previously spent creating reports.
Governance isn’t a “one-size-fits-all” approach
Corporate oversight and identifying where the focus should be may need to vary over time. BUs should have a significant degree of autonomy in decision making to boost ownership of the R&D effort, which requires guiding principles to steer the ship and control costs. Appropriate governance starts with getting the underlying innovation process right; it also requires careful thinking around metrics, incentives, reporting lines and the culture within each BU. The right level of governance focuses the organization’s combined creativity without overburdening members of the R&D organization.
One way to minimize disruption is to apply a trial-and-error approach to enact a change of governance, beginning with a smaller unit, then rolling it out more widely. Using such an approach may yield a slightly different governance approach by BU. A minimum standard includes reporting on the same metrics and linking BU contributions to the innovation gap, therefore aligning to corporate strategy. The BUs may include a different selection of internal and external “clients” or link objectives to KPIs in different ways. The view of the global portfolio, however, should be a constant across all BUs.
Corporate-level governance should include the CTO, CFO and strategy officer. It should not be about cutting down individual projects but about providing appropriate guidance. There must be a clear strategy for innovation with clear goals so that expectations are tangible.
Lay the groundwork for success
In all cases, the organization must perform a complete review of existing as-is processes before technology assessment and selection, ensuring that the new solution fits with the organization’s requirements and creates enough common ground among end users to harmonize R&D activities. A technology assessment can then identify “best-fit” solutions from the available options (see below figure).
Arthur D. Little’s approach prioritizes a company’s requirements while recognizing a core set of guiding principles (i.e., a solution should be cloud by default, accessible and secure, one shared solution, automated, modular, and a strategic enabler).
Once selected, the company must ensure the tool’s successful adoption. All stakeholders should know the “what’s in it for me” message, and employees must feel that they are well supported. Demonstrating that the implementation is strongly supported – not dictated – by leadership is critical to capturing employees’ attention and building the momentum required.
Ensuring that new ways of working become normalized quickly requires strong change champions, located in all geographic regions and carefully selected by each BU. These change champions should be frequent users of the tool to ensure they remain credible.
Agreement with senior leadership on business milestones linked to the implementation allows momentum to build and ensures all users and executives have clear targets.
Looking to the future
This article focuses on one of the more “traditional” problems that organizations face when looking at their innovation management strategy. In our article “The Laboratory of the Future,” we discuss how the most successful companies of tomorrow will be those who are able to master three global challenges in R&D: (1) how to use software and digital approaches in a shared way of working and thinking, (2) how to accelerate learning and the sharing of insights and knowledge and (3) how to balance R&D productivity with maximal creativity and breakthrough realization.
Insight for executives
Digital tools do not solve business challenges. Indeed, implementing the wrong tool can create problems where none had existed before. Prior to any change, businesses must have a clear understanding of the problems that need to be solved and a comprehensive plan to solve them. The method of delivery should be agile to ensure that the minimal viable product is built to address the business challenge. Understanding users’ needs and the evolving nature of the business, serving customers and adapting to market conditions are fundamental activities. The choice of tools and the implementation path should then be clear.