- Research Partners with the Rest of IBM
- IBM Creates FOAK
- FOAK's Aim Is Leadership and Growth
- FOAK Gets Systematic: The FOAK Board
- FOAK Proof Points
- FOAK's Distinctive Model for Innovation
- Summary
FOAK Gets Systematic: The FOAK Board
Early FOAK projects provided a strong starting point, but not a finished model. For instance, initially IBM Research had many assets lying around that could be cherry-picked for "hardening." This means taking a technology and providing the structure, training, and documentation needed for the technology to be used reliably in the marketplace. This availability of almost-ready assets couldn't last, and a crisis of sorts occurred when less mature and visible assets became central to FOAK engagements.
It became clear that FOAK needed to include more development activities—especially alignment with markets and current offerings—during projects. Today, careful consideration is given to the state of the initial assets that become the core of the FOAK project to ensure that they can be implemented, enhanced, and extended within a 12-month time period, which is the typical duration of a FOAK project.
In addition, it became clear that too many projects failed because they were being approved without sufficient attention to clear goals and roles. The program also did not provide enough guidance to those who in many cases were not used to working with clients and managing those relationships. The early projects also showed common weakness in project management.
In 1999, the concept of having an overall governing body for the program to manage its investments and help alleviate pain points in the processes emerged. The FOAK Board (described in Chapter 5, "Choosing the Best Projects") consists of a cross-IBM team of executives who meet quarterly to do the following:
- Review and approve investments
- Help innovation teams navigate obstacles
- Ensure that both IBM and its clients are realizing value from the program
Although the members change continuously, the concept of the FOAK Board and its purpose have remained consistent over the years.
Problems occurred on the client side as well. Clients are used to having IBM "jump" in response to their requirements. A FOAK is fundamentally different in that IBM pays the bulk of the bill and has an objective in mind that may not align perfectly with the client's objectives. For example, with one FOAK, the Enterprise Portfolio Management Hub, the client wanted special adaptors built to interface with its tools. These were one-off solutions that IBM was not interested in building. It was just too big a job. Ultimately, the IBM Project Team had to reset the client's expectations. A painful lesson was learned about the need to set expectations correctly from the beginning. This is discussed in more detail in Chapter 4, "Getting the Most out of Partnerships."
Setting client expectations goes well beyond the features and functions of a given FOAK project. Balancing the whole premise of exploratory prototypes versus commercialized offerings is difficult and continues to be a challenge for the program even today.
Retooling and Polishing the FOAK Approach
Although the FOAK program delivered value throughout its first five years of existence, the FOAK Board believed it could have an even greater impact on IBM and its clients. So in 2001, the program was reengineered to better align it with IBM's solution strategy, link it to more strategic markets, improve its asset transfer rate, strengthen client commitments, and have a better means of measuring the program's impact.
Alignment with the Solution Strategy
Part of the impetus for change came not from a realization that improvements were needed, but from a strategic change outside of FOAK. In the late '90s, IBM's solution strategy shifted away from building applications to one of partnering for applications. IBM wanted to provide industry-focused consultants and subject matter experts who could leverage the breadth of IBM hardware, software, and integration services. This meant that the types of assets being developed and tested on FOAK projects needed to shift as well.
Instead of large, application-based assets, IBM needed to invest in a wider variety of assets. Middleware, business models, methodologies, architectures (business, functional, and implementation), analytics engines, and more—extended by innovative technologies and thought leadership—became the focus of the program's investment strategy; it remains so today.
This fundamental shift from application-based assets to a broader range of assets being developed and piloted on FOAK projects cut the program's funding needs in half. In some ways, this enabled the program to survive during times when the company was focused on quarter-to-quarter financial performance.
In recent years, however, the focus has shifted back toward innovation and growing the FOAK program. This is supported by an almost 50% increase in FOAK program funding in recent years.
Linkage to Strategic Markets
Organizationally, the FOAK program is the teaming of IBM's research and sales divisions (Sales & Distribution (S&D)). This enables the sales teams to leapfrog IBM's traditional development cycle and helps guide research efforts toward strategic markets.
The value of S&D input was understood only over time. Prior to 2001, the majority of the FOAK projects presented to the FOAK Board were IBM Research-initiated, with limited involvement from the S&D industry teams. Yet S&D had a sophisticated market planning process in place to pinpoint strategic market segments likely to grow—something IBM Research did not have.
The FOAK Board wanted the IBM Research teams to leverage S&D's market planning process to ensure that the FOAK projects were well aligned with the industry-defined strategies and focused on their targeted market segments. This was a pivotal insight for FOAK, and drove greater value for S&D.
Today in the FOAK model, sales identifies strategic market segments and targets early-adopter clients and business partners to work side-by-side with IBM scientists, testing new ideas and innovative technologies. FOAK selects research that is too immature to be included in a brand product plan, but not so immature that it poses a substantial risk to the client's business. IBM funds researchers as they pilot their innovations in a real business environment. The FOAK client invests in the hardware, software, and services needed to fully participate in the project.
It might be surprising that a sales organization could have such interest in innovation and would provide funding and personnel to partner with a research organization. The personalities and values of sales and research typically don't intersect. Classically, the researcher is interested in satisfying curiosity, gaining the respect of peers, and doing something new. A sales person is interested in commissions, salary, and bonuses. Although these characterizations are a bit stereotypical, they contain enough truth to raise curiosity about why research and sales should work together.
The answer to why such different organizations choose to work together is one word: growth. For IBM, FOAK enables S&D to guide IBM Research efforts towards strategic emerging-market opportunities that sales people have identified as potential sources of new opportunity. IBM Research has an opportunity to create an organizational ally and demonstrate its contributions.
During the reassessment of FOAK, another practice was found to be ripe for change. Prior to 2001, the innovation teams tended to engage clients before they secured FOAK Board approval of their projects. The researchers believed that if they had a qualified client, their FOAK proposal would be stronger, and the risk of rejection would be minimized.
This practice often led to innovation teams securing FOAK clients who were in nonstrategic market segments, as defined by the industry's market planning process. This may have been fine for getting the project done, but it could be lethal to attempts at later asset adoption. Delaying such commitments and linking the FOAK program directly to the industry's market-planning process has better aligned it with S&D's strategies and has driven greater impact on the IBM Corporation as a whole.
Improved Asset Transfer
Once a FOAK project is completed, the intellectual property needs to be transferred to an owning organization, such as IBM Software Group, to enhance and commercialize the assets for broader market consumption. Prior to 2001, most innovation teams did not explore asset transfer until their projects were completed.
Asset transfer occurred too late in the overall FOAK project lifecycle to have an impact, because it provided little or no opportunity for the commercialization organization to understand the requirements or influence how the assets were developed. These asset catchers, as they are called in the program, are responsible for the assets' ongoing enhancement, maintenance, and support. These catchers can be in an IBM product brand organization, a services practice, or an external partner's organization.
Today, FOAK innovation teams must engage the targeted catching organization early in the process. They need to gain the organization's support and feedback on strategic and technical relevance to the catcher's future product plans. Beginning with the proposal phase, they actively discuss the project's merits with the potential catchers, and these relationships are nurtured throughout the project. And it doesn't end there. When a project is about three quarters of the way to completion, more detailed discussions occur about the actual plans for transferring each asset.
These early and regular discussions are crucial to ensuring the assets' broader market applicability. This up-front dialogue, coupled with the ongoing involvement of the catching organization in the FOAK projects, has proven to be widely successful in pushing the asset transfer rate of the FOAK program to 70%. It is important to note that this asset transfer rate is based only on projects that have successfully made it through the various project filters (described in Chapter 2, "The FOAK Process: Phase I") and the FOAK Board approval and the contract negotiation processes (described in Chapter 6).
Stronger Client Commitment
During the reevaluation of FOAK, another change was made, this one involving the client. When the FOAK program was introduced, projects were offered to clients for free. The thinking at the time was that, since IBM couldn't commit to a fully commercialized product at the start of the FOAK project, it shouldn't charge the client a fee for participation. But without a client's financial commitment to the FOAK project, it was often difficult for the FOAK innovation teams to keep the clients interested in the projects' success. And upon completion of the FOAK project, it was virtually impossible to gain the client's commitment to fully deploy the solution.
The FOAK Board hypothesized that if the program had a more clearly articulated value proposition, the clients would be willing to invest—both financially and with in-kind resources, such as personnel, data, process, and user groups—to participate in a FOAK project. (The FOAK client value proposition is discussed in Chapter 4.) Today, a modest client investment is required to participate in the FOAK program. This improvement in approach over the last nine years has had a tremendous impact on the level of client involvement in FOAK projects and the overall value realized by both the clients and IBM.
Measuring Impact
Finally, measuring the impact of an experimental investment program is difficult. The traditional approaches used to measure businesses with existing markets don't necessarily make sense for experimental, unborn markets. Yet the FOAK program needed a way to prove its value to and impact on IBM and its clients. In 2001, a set of standard metrics was established and a scorecard tracking mechanism was created to measure and track the portfolio's performance at a glance. Not only does the FOAK Board use these metrics to manage the portfolio, but they have become critical in keeping the program funded. FOAK program metrics are discussed in detail in Chapter 10.