When a Good Design is Not Enough

Comments: 1
Rate this:
Total votes: 0

In spite of significant advances in both improvement methods and enabling technology, the success rate in implementing complex process redesign projects still hovers around 33% and has not changed that much over the past decade. When a good process design does not get implemented, it’s often due to insufficient focus and attention on accountability, governance, resources and momentum. Results can be compromised whenever there is insufficient attention to one of these factors. Even when there is a good design – implementation failure is nearly certain when there is lack of attention to several of these factors as the following example illustrates.

The U.S. division of a global aerospace company (GAC) was faced with the challenge of improving its business practices in responding to requests for proposals (RFPs) received from clients and prospects. The level of current performance was not good. GAC was failing to respond to RFPs on time around 20% of the time. This was of concern to both clients and the members of the GAC leadership team. The Vice President of Quality launched a process improvement project to redesign the RFP “receipt to respond” process. On the surface, the RFP receipt to respond process was easy to understand. When GAC received an RFP, it would be passed to a Proposal Manager, who would assemble a proposal team comprised of the right resources from various departments such as engineering, finance, and production, the team would then assess the RFP, draft a response, which would need to be approved internally, and then presented to the client or prospect organization. The process improvement project team rapidly identified a number of significant issues, disconnects and opportunities. There was no central point of contact to receive RFPs. Some were received in the Contracts department, others in Marketing, and, at times, an RFP would even be received in Engineering. This sometimes resulted in a delay in passing the RFP to a Proposal Manager. Due to other priorities, the Proposal Manager sometimes had difficulty in assembling all the right resources from various other departments. Next, all RFPs were treated more or less in the same way, even though some RFPs were for products that had been quoted in the past 12 months and where the original data was still fresh and current. For the more complex RFPs, and especially for the high-dollar-value ones, there were delays in getting cost estimates. This was particularly relevant when GAC needed to get quotations from its own suppliers on new component parts. Finally, there were frequently delays in getting approval from GAC’s own senior management due to the full agendas of GAC leaders and difficulty in getting the needed time to review responses to complex RFPs. The project team developed a solid new process design, supported by a process model and a set of recommendations and presented its findings to the steering team. A set of recommendations were tabled, including the following:

  1. Create separate work flows for “fast track” and “standard” RFPs (fast-track to be handled by the proposal manager on an accelerated basis).
  2. Implement an easy-to-monitor (green-yellow-red) measurement system that provided early warning to senior management of responses to RFP that are in jeopardy of missing the due date;
  3. Build a new database so that cost estimates would not need to be redone every time;
  4. Create a cost-estimating center of excellence, which would require some organization changes;

The design was solid. The Steering Team thanked the project team for their good work, appointed an implementation team leader and concluded the meeting, assuming that the transition from design to implementation would proceed smoothly.

Nothing could have been further from the truth. The project team did make some progress in developing the proposed measurement system, but then they got bogged down in defining and creating the cost-estimating center of excellence, as that involved organization change and significant political challenges. The implementation effort stalled.

What happened? The design was good – maybe even excellent. Given the complex, cross-functional nature of this business process, GAC failed to pay sufficient attention and focus on accountability, governance, resources and momentum.

No one was made explicitly accountable for the measurement and management of the RFP receipt to respond process. Everyone had interest in improving measurement practices, but there was no-one with skin in the game.

In spite of the recognition that the new behaviors in the redesigned process called for unprecedented collaboration between Marketing, Engineering, Finance and Procurement, there was no explicit attention paid to establishing the needed cross-functional governance of the process.   Insufficient resources were assigned. The implementation team leader was a part-time role, whereas the complexity of the design called for a full time, dedicated resource.

The lack of attention to accountability, governance, and resources virtually assured that there would be insufficient focus on quick wins and momentum. Logic would have dictated that the implementation effort begin with a focus on creating the fast track work flow for products that had been recently quoted and where the original data was still current. That would have immediately saved a lot of unnecessary meeting time and it could have been implemented with the stroke of a pen.

If your organization is encountering challenges in effectively implementing good process designs, consider how much attention is being focused on accountability, governance, resources and momentum.

Comments

Tom Miller
,
posted 11 years 36 weeks ago

"...the success rate in

"...the success rate in implementing complex process redesign projects still hovers around 33% and has not changed that much over the past decade..." This resembles the success ratio on many I.T. projects. :( It often is not the implementation that fails but having a less than accurate picture of the requirements of the project/system. From your article we could go back to first principles like "what problem are we trying to solve here" and verify not only process design but the conditions that must be in place proceeding the implementation and the outcomes feedback that provides correction(s) to the process/process implementation. I will freely admit to not being an expert on this area but it looks like an example of a project that may not have had a robust enough scope to cover all the problems that they were trying to solve as well as a comprehensive requirements workup.

Join the Discussion

Remind me later

If you wish to make a purchase today and experience an error with the shopping cart, you can place your order over the phone. Please contact us at (508) 475 0475 x15 or toll-free within the U.S. at (855) 300-2686 x15.