Using the speedbumps technique to foster agility
It may be that project managers are looking in the wrong places to find improvements. Rather than searching for tools and techniques, the best leverage probably comes from removing barriers. The first half this paper describes the speed bumps technique and three examples of application. The second half of the paper discusses organizational agility and the future of project management. I characterize organizational agility as the capability to balance anticipation and reaction. Speed bumps reflect imbalance, so I will explain how creating balance is an attribute of a great organization.
The Speed Bumps Technique
The speed bumps technique is a group process of identifying project specific barriers (speed bumps) and accelerators. The process helps the project team build a common mental model of what causes project speed and what hinders it, so they can implement improvements.
Briefly, the process is this: develop a team meeting agenda and set expectations on the purpose and duration of the exercise. Fifteen minutes is enough for a cursory treatment, but the project should plan for at least an additional hour to uncover, analyze and discuss the root causes of the speed bumps. The materials needed for this exercise include flipcharts, stickies, and writing instruments. Get the participants in the right frame of mind by telling a war story or by asking participants to share one of their own experiences. Get people to think beyond the tasks of a project to barriers that affect achieving objectives. Next, post a piece of flipchart paper labeled “causes of fast projects” and another marked “causes of slow projects.” Emphasize to participants that the causes of each are different. Pass out stickies to the individuals or small groups of two to five people and tell them to write one reason per stickie. Get the meeting participants on their feet because it fosters interaction, energy, and creativity. Follow brainstorming rules: suspend judgment; build on ideas; and save analysis for a later step. Soon, the project has two sets of data that is relevant and local to the project's organization and the project can further analyze them with the well-known affinity diagramming method. Encourage the people to comment and point out interesting items, trends, and themes in the data. Challenge them to think about the underlying principles of project performance and common mistakes, and what improvements are possible for their project. Ask, “What did you observe and learn?” This is also a good opportunity to weave in a preliminary identification and analysis of NPD program risks and issues.
To prioritize and remove the barriers, use a weekly team meeting routine to discuss and remove one of the speed bumps. Don't stop when you've harvested the easy speed bumps (the “low hanging fruit”). The team will have some interesting discussions on the definition of easy and hard, and will disclose interesting insights on personal style and organizational culture.
The reader who wants to learn more about the technique should review my article in Visions Magazine (Githens, 2002).
Three Companies’ Experience in Identifying Speed Bumps and Accelerators
The three cases that follow list speed bumps (things that slow down a project) and accelerators (things that speed up a project).
Essilor of America, a global manufacturer of eyeglass lens, has its new product development (NPD) group working on removing speed bumps. Exhibit 1 illustrates selected data from Essilor from performing the speed bumps exercise, grouped into themes. Despite its experience and good results with project management, Essilor found that some supporting departments were not as mature as others in terms of having a process and understanding of how to support NPD project teams. In some cases, NPD projects were launching without the required documentation, causing rework. Project managers spent a lot of unnecessary time providing information. The speed bumps exercise provided focus in alignment for further refining the project management process.
I will call the technology unit of a large healthcare organization “Healthcare IT.” The new president of the technology unit had issued a challenge for “speed, value, and innovation,” which was a stimulus for trying out the speed bumps technique. Managers and executives performed the speed bumps exercise on two different occasions. Exhibit 2 lists selected speed bumps and accelerators from a session that included senior managers from Healthcare IT. Unfortunately, this change effort lost momentum when the champion took a new position.
IBM's experience provides further validation. In November 1999, Steve Ward, at the time IBM's VP of business transformation and chief information officer, pulled together a group of 21 people into a “speed team” that was charged with completing projects faster (Kirsner, 2000). One of early realization was that identifying and removing speed bumps was essential to project speed. The article identified a few speed bumps for IBM, as listed in Exhibit 3. Members of IBM's speed team concluded that there is a need to “blow up the process” to improve speed. IBM does not instruct people to disregard process, but rather to pay attention to the spirit of the law, rather than absolute, rigorous compliance to the letter of the procedure.
Recognizing the Distinction Between Speed Bumps and Accelerators
The layperson typically assumes that speed is the opposite of slow, but a deeper analysis shows that speed bumps are qualitatively different than accelerators. Generally, speed bumps are sources of frustration and dissatisfaction for the project team (e.g., “How can I go through these many reviews on a project scheduled for six weeks?”). Many are external to the project, in the organization's environment. Accelerators, by contrast, are things that motivate a person (or a term) to give extra energy, or work more efficiently.
Life Cycle of a Speed Bump
It is instructive to analyze the life cycle of a speed bump in order to understand and treat its pathology. During the course of a project, all kinds of problems arise. For example, one NPD organization found that its “study phase” often too much longer than the general manager desired. The purpose of the study phase was to determine the feasibility of the proposed product concept with respect to the current technology and market demand. Perfectionism was a big speed bump. Engineers there had (real and imagined) anxi-eties—sometimes spoken, sometimes not—that poor information or incomplete designs would be met with punishment. Thus, they worked all issues completely and thoroughly (especially those that were in their area of subject matter expertise), even if the analysis was more exacting than required by the task. To remove this speed bump, managers of the engineers clarified their quality expectations and even stated that experimenting and failing is acceptable.
There is a large literature on organizational adoption of technology, and setting standards around inferior methods. For example, designers of mechanical typewriters originally developed the QWERTY keyboard style to slow down the typist and synchronize the human element (the fingers) with the mechanical limitations of the keys. This dominant style continues today, even though the far superior DVORAK keyboard can be programmed into any computer (Everett, 1993). Just like QWERTY, organizations often create standards around inferior technology and practices. These practices constraint the organizations ability to adapt or respond. In the case of project speed bumps, the speed bumps are often non-value-adding. Exhibit 4 illustrates three forces make organizational speed bumps hard to remove. Speed bumps are structural, but get introduced and reinforced through the cultural and cognitive domains. As people find a technique that works for problems, they develop familiarity with that technique and it becomes a routine or habit. These organizational routines get in the way of creativity and change because they foster and reinforce compartmentalization, ambiguity avoidance, and inertia (Adams, Day, & Dougherty, 1998). What were once good, logical practices often become speed bumps when unanticipated side effects occur.
Stories are pervasive in business media that describe the uncertainties and complexities in the business environment. A short list of causes would include bankruptcy, merger, new technology, computer virus attacks, etc. In the face of this uncertainty, some managers think it is futile to develop an effective crystal ball, and instead focus on day-to-day operations. They would rather shift energy away from proactive, predictive contingency plans and instead perform workarounds. This uncertainty and fast pace creates the need for flexible capabilities.
For example, the Baldrige National Quality Award recognizes agility (formerly called fast response) in its criteria for the award. The Baldrige justifies the criteria of agility by saying, “All aspects of electronic commerce require more rapid, flexible, and customized responses. Businesses face ever-shorter cycles for introductions of new or improved products and services. Faster and more flexible response to customers is now a more critical requirement. Major improvements in response time often require simplification of work units and processes and/or the ability for rapid changeover from one process to another.”
The Baldrige Award is an example of what I call the reactive view of agility: the project or organization must response and adapt to an uncertainties brought about by the current business environment; good organizations react better than poor ones. Thus, people define agility in terms of responsiveness, quick reaction, adaptability and flexibility.
No doubt, projects must find ways to evaluate and respond to the uncertainties. Roberto Verganti (1999) identifies examples of reactive capabilities to include the following: redundant resources, flexible resources, rapid prototyping, overlapping tasks, and flexible product platform architectures. Thompke and Reinertsen (1998) measure development flexibility and express it as a function of incremental economic cost of modifying a product as a response to changes. The higher the economic cost of modifying a product, the lower the development flexibility. Their prescriptions include adopting flexible technologies, progressively locking down requirements, keeping multiple back-up approaches viable even after concept selection, providing a decision tradeoff framework, measuring and improving reaction time, making piecewise commitments instead of binary choices, and structuring design tasks.
Note that the reactive definition of agility implies that an external force is acting upon the organization, causing it to flex in response to that force. Problems are always occurring in projects and in the organization, and they consume a large amount of peoples’ time. The constant barrage of email, pager messages, instant messaging, voicemails, and other requests seem to call out for urgent reaction. Reactiveness-as-agility may be just a synonym for firefight-ing. I believe that many companies are stuck in fire fighting because they have not managed the balances. Why? Simply put: speed bumps throw organizations off balance. People waste energy trying to regain balance and this further tips the system towards a reactive orientation.
Many people overlook the anticipative view of agility. It is a valuable perspective, and is reflected in hockey star Wayne Gretzky's statement, “Some people skate to the puck. I skate to where the puck is going to be.” Anticipation is “squishy” but strategic. I have written on how planning is associated with project failure (Githens, 2001). Roberto Verganti (1999) describes anticipative capabilities as those that decrease uncertainty about the future. Anticipative mechanisms include transferring knowledge from previous similar projects, team building, early and collaborative communications, prototyping, and risk analysis. Just because “business has changed,” does not mean that project planning is futile.
I offer a balanced view of agility, where agility is defined as a function of reactivity and anticipation, and both must be present and balanced to have a capability for organizational agility. This balancing is a refined statement of what I wrote and presented about balancing flexibility and control in my PMI Paper “Balancing Strategies for Product Innovation” (Githens, 2000). Organizations need to be flexible so as to be responsive to customers and controlled so as to gain efficiencies of scale. The PMI 2000 paper describes the application and use of polarity management for finding balance. Verganti provides evidence that supports “planned flexibility,” which is the “project-specific flexibility, built through decisions in the early phase” of development.
Where can we find agile organizations per this balanced view? In addition to Verganti's research, consider the data provided in Built to Last (Collins & Porras, 1997), where the authors identified a number of companies that meet high standards for great companies: Procter & Gamble, American Express, Johnson & Johnson, 3M, Marriott, GE, Citigroup, Disney, Wal-Mart, and Sony. Collins and Porras identify the “genius of and” as exemplary of these great companies: profits and purpose, continuity and change, freedom and responsibility. The ability to manage the “and” is the same concept as balance.
Balance is important whether in sports, or finances or the Chinese art of Feng Shui. In the Chinese tradition, Yin and Yang provides balance and continual change. In terms of my balanced definition of agility, the reactive approach is “yang” active energy: the strong, action-oriented, forceful side of ourselves that gets things accomplished. The anticipative approach represents “yin” passive energy: energy that is intuitive and receptive. Yin energy is subtle, just like an organization that practices risk assessment, voice of the customer, or strategic planning: it develops an awareness and appreciation for the forces around it. Yin and Yang are explained as a duality that cannot exist without both parts. Thus, combining and balancing reactiveness and anticipation has a supporting rationale in non-organizational contexts, too.
Project management fits well with the concept of agile organizational capabilities. Although projects draw from the organization's existing capabilities, there is a strong argument that organizations develop capabilities one project at a time.
Adams, Day, & Dougherty. 1998, September. “Enhancing New Product Development Performance: An Organizational Learning Perspective” Journal of Product Innovation Management.
Collins, Jim, & Jerry Porras. 1997. Built to Last. HarperCollins.
Githens, Gregory D. 2002, April. “Removing the Speed Bumps From Your Project Schedule.” PDMA Visions, www.pdma.org
Githens, Gregory D. 2000. “Balancing Strategies for Product Innovation” Proceedings of the 31st PMI Seminars & Symposium Houston.
Githens, Gregory D. 2001. “Planning is a Vaccination Against Project Failure.” PDMA Visions, www.pdma.org
Kirsner, Scott. 2000, May. “Faster Company.” Fast Company.
Rogers, Everett. 1995. Diffusion of Innovations, Fourth Edition. New York: The Free Press.
Thompke, Stefan, & Donald Reinertsen. 1998, Fall. “Agile Product Development: Managing Development Flexibility in Uncertain Environments.” California Management Review, 41 (1).
Verganti, Roberto. 1999. Planned Flexibility: Linking and Anticipation Reaction in Product Development Projects. Journal of Product Innovation Management (July) 16: pp. 363–376.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA