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.