Volume 5, #3, May 2007
Wizards of Change: How to Encourage Buy-In and Motivate Developers to Improve Product Development Processes
by Sheila Mello
"They always say time changes things, but you actually have to change them yourself."
-- Andy Warhol US artist (1928-1987)
My grandchildren are masters of processs. At two, three, four, and six, they have invested years in developing their approaches to the most important daily tasks: eating, playing, and sleeping (not necessarily in that order). Needless to say, they are none too happy when a change management expert -- in the form of mom -- introduces a new approach. They can't grasp the benefit to them of the "process improvement" that involves putting away each played-with toy before selecting another from the toy box.
All of us have a bit of the child within us when it comes to how we do things. The very fact that we exist means we have mastered the process of life; the way we accomplish everyday undertakings must be, to some degree, effective. Even when our intellects understand why changing a process may be important or necessary, aligning our hearts and souls with the new way of getting a job done may prove difficult.
Nowhere is this as true as in product development, where the very nature of the work breeds homegrown process experts who sometimes believe as wholeheartedly as my grandkids that their way is the best way. This issue of Discoveries looks at how managers and leaders can create product development processes that engineers, marketers, project managers, and others will actually adopt.
The Cult of the New Product Magician
There are few functional areas of an organization where process and professionals are so intertwined as in product development. The managers who hire them may maintain a bit of awe for the product superheroes, whom they invite to join the staff in hopes that these individuals can replicate past successes. The feeling that black magic is at work often pervades (let's not ask too many questions; let's just hope our new product magician can bless us with success). Engineers, chemists, software programmers, and others involved in product development often are hired for their technical skills, which in their minds are inseparable from the process by which they accomplish their jobs. The miniaturization expertise of a circuit board designer or the gene-splicing know-how of a geneticist appear so entwined with their respective proficiencies that it seems impossible to disentangle the skill itself from the process of deriving results related to that skill.
A company may not notice this conflation of skill and process when all is going well. The challenge arises when the processes that come along with individuals' skills no longer serve the organization. Maybe the competition heats up, and new product development cycle times suddenly must shrink, or new technologies emerge that offer an opportunity to improve product quality. Executives recognize these strategic-level forces and understandably want to adjust the product development process to respond. But no amount of top-level enthusiasm will convince product developers to change the way they do things unless the developers themselves experience the process as broken or requiring improvement.
How can top management create the burning necessity for change that leads to acceptance? A basic approach includes: Assess where your processes are inefficient, hindering success, or plain-old broken; introduce change in a way that gets participants to buy in; choose the most broken areas to work on first; roll out change gradually and reassess after roll out to see what worked and what didn't.
Yes - Assess -- Then Go Beyond
Certainly, there must be some way to know whether or not existing processes need improvement. Maturity models, like those developed by Michael Hammer and explained in a recent Harvard Business Review article, are essential. In the product development area, PDC has created maturity models for innovation and for product portfolio management. Such models provide a concrete framework for evaluating the deficits in a company's processes. Where industry benchmarks exist, companies can assess their performance against others in their industries. (Maturity models have evolved in the last few years from a test/evaluate/step-up approach, in which companies fixed many elements at once to leap up to the next level in the model, to the an approach based on continuous improvement.)
As in the case of my grandkids, there must be a path to action after you check off the assessments that say, "More than 10 toys on floor at any given time" or "Adults trip more than three times an hour when navigating the playroom." And regardless of the type of model used for assessment, other, more subtle factors often stand in the way of companies successfully improving their product development processes. One of those is buy-in.
Encouraging Buy-In Through Process Metrics
Some change is driven by fear: Witness individuals afraid of dying young who make difficult lifestyle changes to reduce their risk of heart disease. Fear can have the opposite effect, however, when an organization seeks to change. Leaping into the unknown, especially where it involves one's job and performance, is always anxiety-provoking, and this anxiety can lead to resistance. When people are afraid of failing, they will be afraid of changing.
This is why buy-in is so important in introducing process change and even more important when seeking change from technical experts in product development. Certainly, a new administrative or manufacturing process requires a certain degree of buy-in from the staff whose daily work the change will affect. But the buy-in required of process experts such as new product developers is of a different order altogether.
The term buy-in implies that a person not only understands the need for change on an intellectual level, but has an emotional investment in making the change happen. In a technical organization -- whether it's chemical, mechanical, electrical, or software -- the key to enticing an emotional investment in change is having the individuals affected by process improvement participate in the definition of the process change. These individuals can undermine the change if they don't see its value or ensure its success if they do.
Once managers have used a tool such as a maturity model to identify what isn't working, their next task is to get product developers to acknowledge what isn't working and to participate in imagining the new approach. Managers can create guidelines through predictive metrics -- that is, metrics that relate in a concrete way to the actual work being done -- and then introducing new techniques to improve performance relative to those metrics. For example, one common goal of product development process improvement is to trim time off development cycles. In this case, using time as a metric leads only to informed fluctuation: The development team will know it's a month behind schedule, but so what? The result won't help them fix the problem. Predictive metrics, on the other hand, measure actions that actually affect cycle time, such as whether product definition is complete prior to the start of design. If the team sees that incomplete product definitions are causing them to fall behind schedule, they know that focusing on completing product definitions before starting development will solve the problem.
When management initiates change by clearly identifying predictive metrics, the team has a much better chance of achieving its cycle-time reduction goal -- thereby easing the fears of product developers that the new method of doing things will somehow make things worse.
Unless You Have a Magic Wand, Start Small
The adults in my grandchildren's lives might wish to wave a magic wand to transform the kids into enthusiastic embracers of the new toy-management process -- and new ways of doing things generally. But the kids undoubtedly will need multiple exposures to the new process over the course of months, along with many reminders about how to do it and of its benefits.
In the absence of magic wands, agents of product development process change must be similarly patient. While developing the ability to change as a core competency can be a competitive advantage (see Discoveries, Volume 3, #1, February 2005, Befriending Upheaval.), part of this core competency includes an understanding that you don't create fundamental change overnight.
How patient do you need to be? Process management consultant Arthur Schneiderman created a goal-setting tool (see The Half-Life® Complexity Matrix) for companies to determine how long it will take to implement a new process. The time required can be as much as 22 months in situations where both the technical and organizational complexity are high.
You can aim to reduce this time by developing subject-matter expertise, launching a successful pilot project, and having the change be motivated by the individuals it affects (a "pull" instead of "push" model). Some ideas to help build a core competency in change include:
1. Don't reengineer every process at once.
Pick the pieces that are most broken or that can yield the greatest improvements, and work on them first. You can do this by viewing the product development staff as "customers" who need to be motivated to "buy" the change, then conducting in-depth research to uncover what gets in the way of them doing their jobs effectively. Next, you prioritize these findings to decide which areas to tackle first. For example, suppose that by gathering a set of project histories, you identify that your organization needs 1) a better project management process, 2) a voice of the customer process, 3) metrics to drive alignment, and 4) a revamped portfolio management process. If you attempt to put in place all of these at once, you will engender chaos. Instead, you want to determine which one or two will yield the greatest impact and concentrate on those. One of PDC's clients -- a major medical device company -- selected voice of the customer as the first area to improve followed by project management. Using this staged approach, the company streamlined its whole development process and cut R&D costs.
2. Take advantage of pilot projects.
While pilot projects sometimes get a bad rap for leading nowhere, a successful pilot provides proof of concept and goes a long way toward getting the buy-in you need from the development staff. When you celebrate and promote pilot project successes you create a ripple effect, spreading the desire for change throughout the organization.
3. Avoid a rush to roll out everywhere, all at once.
Once you have proven how great the new process is, you understandably want everybody doing it as soon as possible. Resist this temptation. By rolling out too fast, you risk diluting the process and setting your organization up for failure. It takes time to develop the necessary depth of expertise about the process. Too few subject-matter experts mean that many people won't be following the process exactly, leaving room for slip-ups. Think of introducing the process not as opening a floodgate but as rolling a snowball. An open floodgate drowns those in its path. A snowball starts small and slowly at the top of the hill, gathering speed and growing in size organically as it rolls.
Create Value and the Change Will Follow
Just as customers pay for perceived value, professionals in development organizations will pay, with time and energy, to adopt a new process when they perceive a direct value for themselves. Without clear value, they won't plunk down their money. The new process becomes just another management mandate, easily set aside in favor of handling the stresses of daily work. When my grandkids see that picking up their toys yields a happier mother who is more apt to get down on the floor and play with them, they're more willing to spend the time and energy required to implement the new toy-management process. When the technical product developers responsible for the vital task of creating your company's new product offerings see that teasing apart their expertise from the process and then improving the process can actually free them to be more creative, they'll gladly spend the time and effort on process improvement.
***
Tell us your experience with process change.
Find out about making change stick for your portfolio management process in PDC's book, Value Innovation Portfolio Management: Achieving Double-Digit Growth Through Customer Value.
