Execution Problems
Failure to Implement
We have long been criticized for having problems with quality. We will therefore implement six-sigma as part of our company turnaround.
The adoption of a quality process methodology is a noble undertaking and one that can pay dividends for companies who successfully implement it. However, process frameworks such as six-sigma, the “Baldridge” initiative, or others such as the CMM (Capability Maturity Model) are far from easy to implement. Further, executives who see in these frameworks a means for turning around a company often are unaware of the implications of adoption. Quality systems are by their nature process-focused. The idea behind them is that the control of the systems that produce products and services in an operation will result in quality outcomes. It is the process or processes that are controlled in a high-quality operation rather than the quality of each individual product itself. What executives fail to consider in the adoption of such quality management-driven change initiatives is that implementing a process-focused methodology requires process discipline. This means that employees, including executives, cannot simply do what they may want to do using ad hoc methods. Instead, they must respond to the issues of the day by means of following a defined process. The reason for the word “discipline” in the term “process-discipline” is that it is very difficult to follow processes when all instincts lead executives to take independent, ad hoc actions to address issues. Management by process constrains what executives can do. Executives are no longer kings but are actors in the organization who play a specific important role. They make hard decisions at important process milestones. They report status, good or bad, to clients, employees, and directors. They hire and fire as required. They point the way forward for the purposes of competitive advantage. However, such actions occur in the context of associated business processes. As soon as an executive understands the process constraints that limit executive power, the desire to support change via the implementation of a quality management framework begins to fade. The change goal announced with great fanfare therefore remains unimplemented, perhaps in a way analogous to what King John would have done had he become aware of what the Magna Carta would do to constrain future kingly action (Figure 8.1).
Figure 8.1 Process management and constraints
There are other circumstances where company executives fully support the proposed change, but the company fails to implement due to a lack of knowledge and capability. To make an analogy, consider that every football team desires to go to the Super Bowl, but only those teams with the capability to do so succeed. To illustrate this point, consider a company that is failing in the market due to its inability to launch products on time and within a regular annual cycle. Competitors in the industry would release at least two or more products per year in the spring and fall, but perhaps more when different products are launched in Europe, Asia, Africa, and the Americas. It was therefore dictated by the CEO of the parent company of the international telecommunications company that the company from now on would develop products on time and launch product multiple times per year just as competitors did. But, outside of the visible result of multiple product launches per year by competitors, what specifically did the competitors do that the company seeking change was not doing? Behind the scenes of the multiple product launches per year was a deep process infrastructure that organized development and portfolio decision-making spanning from the development of components to product platforms, and finished products. This process created the illusion of having the ability to develop and launch multiple products simultaneously. In reality, major competitors planned ahead in the 3- to 5-year range, determined what platforms would be needed to support multiple product iterations, and finally decided what components would be needed to support platform development. Although multiple products were launched across the globe twice per year, the same core platform was used along with customization and feature additions for each market. Doing this required a high degree of foresight, planning, and analysis of market and macroenvironment and demographic trends. Further, such processes required the discipline to commission the development of components today for products that may not materialize for another 5 years. Without such a process, an individual “from scratch” product development effort would take at least 18 to 24 months.
While delivering multiple products each year is a desirable change initiative, the implementation of such a goal requires both the understanding of what needs to be accomplished in order to achieve it and the process discipline to undertake it. The company seeking this goal failed to implement it because it lacked both the know-how and the accompanying process that happened. This can be observed by inspecting the product development process that was not able to support either timely product launch or the launch of multiple products. Instead of a structured planning and product line development process stretching out for three to 5 years, the company seeking change typically commissioned development projects in response to events, market shifts, or product launches from competitors. Events triggering the typical product development cycle that roughly follows this pattern:
- External market trigger for new product.
- Mad scramble on the part of the product planning department to create a highly desirable product specification without regard to the feasibility of development.
- The design teams struggle to understand the technical and market requirements from the customer while at the same time arguing and negotiating with corporate product planning.
The product planning philosophy was to push the design teams as much as possible and accept nothing less than the ideal product based on comparison of competitor specifications and client requests. No thought was given regarding engineering capabilities, available platforms or components, or concerns regarding risk. This ad hoc trigger-driven process was to push even if it did not seem to make sense in hopes of inspiring some breakthrough. The ad hoc process continued as follows:
- Frenetic activity ensued to identify possible technologies to create a workable product. This included chipsets, protocol stacks, software, firmware, and other components.
- Time was wasted over a period of months negotiating with corporate executives and product planning managers, leaving approximately 1 year to develop what would typically take 2 to 3 years to develop from scratch.
This typical development cycle along with severe time constraints led to the development team adopting a very high-risk approach in order to get the product done in the required time frame. A more workable low-risk approach could not be considered because doing so would require that the company acknowledge that the schedule for delivery would be far behind what the company had committed to the market. Of course, the commitment was given to key customers by executives prior to conducting any feasibility study with the development team nor with any acknowledgment that no components nor platform technologies were in place.
The high-risk development strategy adopted by the company led over the years to several “runaway software development” projects. The software defects revealed in testing led to fixes that, once implemented, led to more defects. The defect resolution curve in such a runaway project failed to converge. Instead, in these situations, the defects continued to increase in spite of significant effort to correct them.
With multiple product delays and development failures, the engineers involved in development recognized that a more advanced management system would be required and therefore began to lobby senior management for change in how product development is managed if the goal of multiple products per year were ever to be achieved. It became clear to the development team that the mission to develop a next-generation product would require some stability in the product development process, some additional structure, and finally some forward-looking market projections to avoid last-minute reactions to market triggers without sufficient time to develop products. It was also clear that this approach to product development did not exist in the company. It was decided that the satellite operations of the corporate parent with the highest level of process expertise would focus not only on product development, but on driving process improvement throughout the company so that the maturity level of the parent company could be improved. Some explicit strategic goals were as follows:
- Adopt a structured product development process locally and continually promote it within the parent company.
- Shift from a functional organization to a true matrix organization so that multiple projects could be pursued at the same time.
- Shift to the incremental software development method (and away from the existing waterfall method practiced throughout the company).
- Adopt a product line methodology to focus the organization on building components and platforms in advance of products in an effort to better respond to market requirements for frequent product refreshes (and avoid the mad scramble to integrate products on the fly from technologies available from various vendors at any given time).
- Implement a process improvement infrastructure within the local company to craft improvements, document them, and promote the processes as well as the process improvement methodology to the parent company.
The first step in pursuing improvements in the product development process was to attempt to clarify the roles and responsibilities of product development being carried out throughout the world. The existing model of product development assigned a development team to each market. Very little was shared between market teams making the corresponding maturity of documentation and design processes limited. The local teams could react (and often did) to ad hoc direction with a minimum of coordination between teams. While this method of resource allocation supported optimal flexibility, it also led to high costs. Success in a given product development team occurred when the team was fortunate enough to have a strong project manager to drive the project over the finish line. Should the team find themselves behind schedule or over budget, limited support could be obtained from other teams or corporate offices due to the semi-autonomous structure of the globally distributed organizations and resulting lack of standardization (Figure 8.2).
Figure 8.2 Market responsibility method
Leadership from the development groups sought an improved solution to the organization of teams around specific global markets. One popular approach that had been employed by global companies was to create a platform referred to as a reference design at the corporate headquarters, and then have design centers in local markets customize a product based on the corporate reference design and do so in a structured and modular way. This approach was considered far more efficient than organizing according to a loose confederation of semi-autonomous operations supporting markets around the world. However, it also required a high degree of complex system development and standardization skills to create and manage such a design operation. It also required a long-term market focus and strong process discipline with contributing management skills such as project management and documentation creation and management. The products historically produced by corporate R&D were weak in terms of architecture and not suitable for the extraction of a global reference design. Regardless of the attractiveness of this approach, the corporate product development headquarters acknowledged that this strategy was not feasible (Figure 8.3).
Figure 8.3 Corporate reference design method
An alternative to the corporate reference design was to assign product line responsibilities to each product development operation regardless of location. Given the global convergence toward common standards such as GSM and 3G, the emphasis on assigning development teams to support specific markets began to seem misplaced. It was expected that some efficiency could be gained by allowing each operation to focus on their respective strengths. Further, it allowed for continued semi-autonomous operation that did not require the process discipline associated with multisite development collaboration on each product. The downside to this form of reorganizing is that multiple development teams separated by geography would need to support product launches in multiple factories and countries around the world (Figure 8.4).
Figure 8.4 Product line method
Finally, a mix of various approaches to organizing global product development was considered. The benefit of this approach was that it added a layer of discipline onto globally distributed product development centers while also allowing for some ad hoc product and technology assignments. Ultimately, a hybrid method appeared to be like the structure already in place. In fact, it was observed that although the current structure was said to be one of “market responsibility,” in practice, each local product development organization tended to be assigned to activities by corporate engineering that suited them based on the market or industry trigger du jour (Figure 8.5).
Figure 8.5 Hybrid method
After ongoing discussion, comparison, and conflict among the global product development stakeholders, the decision was announced to restructure global product development using the product line method. It was hoped that the new structure would better focus the efforts of each team so that the company was better positioned to produce multiple products per year (Figure 8.6).
Figure 8.6 System comparison
While restructuring held the promise of improved performance, restructuring was but one component of the overall improvement effort. The new structure required management oversight or governance in order to foster decision-making, ensure collaboration where necessary, to distribute and manage product development budgets, and finally to ensure the alignment of all product development operations with the corporate product and business strategy. In fact, it could be said that above all, governance, rather than organizational structure, was the real problem to be solved. Although global product development efforts involved costs ranging from the tens to hundreds of millions, work assignments as well as budgets were determined informally by a single corporate engineering manager in the breakroom in company headquarters. The informal approach proved problematic, particularly since assignments and budgets tended to change frequently (Figure 8.7).
Figure 8.7 Ad hoc global product development
To make the most out of the newly implemented global product development structure, the globally distributed product development operations lobbied for a more structured approach to decision-making. The launch of multiple products per year by each team was unfeasible when budgets and product roadmaps changed on a regular basis. To attempt to minimize ad hoc decision-making, it was proposed to formalize the decision-making process by moving the decision-making from a single informal point of failure to a team of sponsoring executives. The idea was floated of creating an entity called the “product development board.” It was accepted by the corporate executives primarily because it supported greater visibility of budget decisions by the general manager of the division. Further, the product development board provided a formal means for sales and marketing executives to have more involvement in the commissioning of product development projects (Figure 8.8).
Figure 8.8 From individual to group decision-making
The revised organizational structure paired with a strengthened decision-making structure provided some stability to the management of product development. However, the traditional ad hoc decision-making culture continued to get in the way of the process-oriented focus that would support the launch of multiple projects per year. It was recognized that a more comprehensive restructuring of product development governance was needed. The first step in realizing this vision was the attempt at the implementation of the Product and Cycle-time Excellence (PACE) as pioneered by the consulting firm PRTM (and now championed by the Product Development Management Association [PDMA]). This process was first implemented in local product development operations and then promoted and lobbied for in the corporate engineering office. The problem with this effort to influence the corporate office to adopt new process is in the recognition that a problem exists with the current systems and processes. An early effort was made to promote the PACE model to corporate executives by presenting a copy of the book Setting the PACE in Product Development by Michael McGrath of the product development consulting firm PRTM (Pittiglio, Rabin, Todd & McGrath). Representatives of local product development teams followed up a few months later in a trip to corporate headquarters when an engineering executive was asked “What do you think about the book we gave you to read?” The response was “Oh-yeah, we are already doing it” (Figure 8.9).
Figure 8.9 Global decision-making structure
The next effort to establish the product-line methodology was to attempt to implement the processes locally, produce results, and then use the outcomes to promote the processes globally.
These efforts were a beginning, but culture change was a constant battle. Eventually, the corporate executives saw the need for an improved development process and IBM was brought in to lead the effort. Principles from process improvement activities in the local company were incorporated in the PACE and product-line organization effort. However, it was observed that the parent company carried out the same practices in product development that were always done. The only real change was the incorporation of existing practices within new templates and nomenclature provided by IBM. Elaborate product line and component development roadmaps were created to support the vision of launching multiple products per year, but were never explicitly executed. The focus on individual products alone drove all activities in the company. This led to the local development team adopting a strategy to develop a product in such a way that a platform could be extracted from it on completion. Included in this effort was the partnership between the local development organization with industry partners who could supply highly structured hardware and software components to support platform and product-line architecture. The structured software in this platform and the lack of know-how on the part of corporate engineering to understand it or modify it provided hope that a strong platform could be built locally and eventually adopted globally. There was some discussion by corporate engineering about attempting to port software features from products in which the company was known to be strong, such as audio, video, and other consumer electronics products. However, the corporate code base was so corrupt and so tightly coupled to individual products that gleaning functionality from audiovisual products and porting to the new platform was proved to be impossible. As an example of corrupted code and weak architecture, it was not uncommon to find extensive use of global variables throughout unstructured, poorly documented, and non-object-oriented code.
The goal of launching multiple products per year proved to be elusive. The goal was announced and endlessly promoted, and many supporting moves and restructuring were carried out to support it. In the end, the company was not capable of implementing the grand strategy that the company set out to achieve and failed as a result.
Pointers for how to fail:
- Commit to change without understanding the implications.
- Promote change that requires managers to do what they are never going to do.
- Embark on change that ignores the culture, history, and fundamental capability of the company.
- Attempt change on a grand scale with managers having only small-scale experience.