The information technology organizations in many companies are trying to evolve from an “order-taker” role of merely fulfilling requests to the role of enabling the business. In accomplishing this evolution, companies must transform the “demand management” function. Traditional demand management involves waiting for handoffs from the business side — ideas for projects that individual units in the company think would improve their operations. Although often valuable, these ideas are not necessarily aligned with the needs of the company or matched against project proposals from other business units in such a way that system development and implementation are efficient and scaled throughout the organization.
By contrast, at Toyota Motor Sales USA Inc., the information systems group (where we work) has been moving toward a new model that we call “next-generation demand management”: an effort to meet overall corporate needs rather than narrower project-by-project demands. With this approach, we have become partners with the business units, helping to mold the demands throughout the organization so that redundancy is eliminated and only systems that match the strategic direction of Toyota are produced. Through this campaign, we are leveraging IT’s existing “silo-agnostic” position to deliberately change its role in the company so that it is managing and completing projects that produce business value.
The seeds for this transformation were planted in the 1970s. That was when Toyota began to expand out of Japan into new markets around the world, with the technologies suited for the business in those days. Although new IT systems were needed to support growth throughout the company, there was no master organization-wide plan to create and deliver them. Every functional group could be as creative as it wanted to be, and IT treated each business unit project as an independent effort, designing the solution in isolation. The result was a lot of duplicate infrastructure and increasing maintenance costs.
With many projects under development and limited resources, we began to rely on contracted outsourced help. This was expensive, and, worse still, the contractors became the subject matter experts, gaining critical knowledge about how to link IT functions to the needs of the business while the Toyota IT staff plowed ahead with the next round of basic projects. We were outsourcing not only the work but the valuable skills and know-how that we should have nurtured internally. Rather than nurture them, we let them atrophy.
Even though we spent years developing and advancing the notion of an enterprise architecture function within IT and had all the requisite standards, strategy, and philosophy to achieve a more consistent and integrated approach, the business at large lacked the structure to benefit from these efforts. All IT projects at Toyota were business unit–specific and, in fact, one-offs within those business units.
As IT professionals, we were responsible for changing this cycle of behavior. We began by conducting a performance audit in 2002. We confirmed what we already knew: Costs for IT projects were climbing, implementations had not been ending soundly, and the business leaders perceived IT as a “black box” that funds went into. The audit also showed that many of the problems were upstream. That is, the troubles began with individual business units’ inability to articulate what they needed; they did not know which systems requirements would generate real value, and they did not align their needs with the overall strategic direction of the company. These upstream issues were as much a problem as any concern within the IT department.
It became clear that we needed to create a new operating model. IT would have to help the business units place their wish lists in the context of the needs of the enterprise — all while keeping the business running.
We took on this new approach during a period of great change — for global economies, the auto industry, and our company. This instability made the need to deliver value even more essential, and it gave the business units an incentive to consider and then express what exactly they required to generate their best performance. We conceived of this next-generation demand management strategy in two phases: readiness and renewal.
Readiness. Readiness meant getting our own house within the IT group in order. The business side rightfully told us that it was IT’s responsibility to deliver its work faster, better, and cheaper. We would have to reduce our own complexity, improve our batch cycle time, minimize the number of reports, consolidate data, and reduce our costs. In doing this, we would prove that we were flexible, scalable, efficient, and knowledgeable.
We have thus been developing new metrics and tools to measure an IT project team’s performance, creating clear-cut benchmarks to determine how well a project has delivered on its promise, and putting in place controls to minimize cost and schedule variances. For example, the project manager — now a much more empowered position — is directed to track vendor cost, schedule, and scope performance with transparent models shared by Toyota and the vendor. And to hold our team’s feet to the fire, an internal client can terminate a project at any time if we cannot show that the project meets a set of agreed-upon quality metrics, including return on investment. In other words, we are ultimately accountable to Toyota for what we promise, and we can no longer blame the vendors if we fail. We now have sufficient management tools in place to keep the vendors on track.
We had never undertaken this kind of readiness effort before the IT transformation. Our success has been a critical enabler. It gave us credibility with other functions in the organization and created an environment in which we could take a stand on behalf of the enterprise. For example, we can now say to a group manager, “We cannot build the system you are requesting because its scope is not broad enough to be useful across functional groups.”
Renewal. As we continued to deliver on these readiness efforts, demand for substantial projects grew — and our performance, although improved, was not sufficient. Projects continued to expand in scope and cost; our own time, costs, and risks were seen throughout the organization as “output” variables, rather than as inputs we could manage. The requirements process seemed to generate a wish list of features to be added to the pile. In one instance, after a year of requirements work, during which we determined a project’s scope, timing, and tasks, our team doubled the cost estimate and asked for another year to complete the work. We had to do better; because projects represent a significant amount of any IT budget, we needed to ensure every dollar spent was spent well. But the systems integrators, to whom we first turned for help, seemed to have nothing to lose (and much to gain in new knowledge) from our struggles. Change was in order.
We worked with Booz & Company to create a demand management road map for this new role. First, we told the business managers who had projects in the queue that we wanted to reevaluate how those projects fit organizational requirements. We put a number of project requests on hold until we could look at them collectively and determine how to link them together — to renew the capabilities of our company, not just the capabilities of individual departments.
We followed this with a series of conversations with leading Toyota executives. We asked them: “What business process issues do we face in building a more efficient, leaner organization? Is the business model changing? What pain points are impeding our progress? And what could IT do better?”
Moving away from the traditional role of relationship management in IT, we were stepping into the role of business strategist. Through these conversations, we began to appreciate at a much deeper level the nature of business operations. And we learned the language and political skills to use when interacting with business units.
Then, during a series of “bottom-up” meetings, we asked critical business managers and subject matter experts to help us document the business processes they used repeatedly when doing their jobs. We traveled vertically down each process in the vehicle supply chain, and then horizontally across major areas like customer relations, product quality, and finance.
This “top-down” and “bottom-up” work led to a new project list — one that only sketchily resembled the prior set of projects that we had halted. For example, a manager had previously wanted a program to track and trace a vehicle within her limited part of the business, which accounted for only about a third of the supply chain. With our demand management analysis, we could come back and say, “The business identified almost 200 capabilities for improving the supply chain. We grouped them, we looked at the dependencies, and now let’s see if the business needs align well with the program that we can build to make the supply chain more transparent and efficient for everybody.” The result was an end-to-end supply chain track-and-trace project, incorporated into the full business unit’s five-year plan. From here, we are developing the ability to check individual IT projects against each business unit’s five-year strategy, to ensure that we support needs in the proper priority.
The difference between the IT “alignment factor” of just a few years ago and that of today is almost unrecognizable. Not only is the performance of our projects notably better, but the business is looking at IT through a new lens. This is a far cry from when we first slowed down the project work and began our discussions with the business side. Now, rather than weapons being pointed solely at IT when a system goes over budget and turns out to be disappointing when finished, everyone’s accountable. A popular sentiment in IT these days is, “You’re in this with me, Mr. or Ms. Business. Let us work together to manage and deliver your project — and to make sure the project is the right one for the enterprise.”