An Article From the Archives:
How do you get your professional people to change how they do things when they are used to an approach they think works fine and your company is clearly doing well? And how do you get the changes to stick? In this month’s article taken from Productivity’s Total Employee Involvement Newsletter, May 1997, we learn how in 1993, Minneapolis, MN-based DataCard, a 27-year-old, privately held credit and debit card personalization systems manufacturer, sought to hang onto its commanding market lead by switching its serial approach to product development to a concurrent approach, aiming to simultaneously improve quality, reduce the time it took to get products to market, and increase the odds that products launched would be hits. With 3,000 employees worldwide and $300 to $400 million in annual sales, the company had done well historically, but they wanted to break through the cyclical nature of their business and put themselves on a steady growth track.
Says DataCard Executive VP and COO Jim Moar (general manager of the company’s Card Personalization Group at the time of the changes): “It was a question of opportunity. At that time, not much new product development had been done for a while, so we were dealing with fairly mature products. With our share position, it was clear that if we could develop new products that customers really want, and simultaneously enter new markets, we faced an opportunity for significant revenue growth.”
Since they were spending as much as 40% of their R&D budget fixing existing products, and since their core market was beginning to shift, Moar reasoned that they needed to simultaneously fix their quality, speed up their development cycle time, develop greater process rigor, and shift from being engineering-driven to being market-driven: “We had a process on the books, but it wasn’t being followed. It was incredibly traditional. It viewed product development as belonging primarily to engineering and secondarily to marketing, and no one else. That stems from the fact that we used to be engineering-driven, which gives you technically good products that take a long time to come to market and often miss the market.”
HEAVY-HITTING CROSS-FUNCTIONAL STEERING TEAM
One of DataCard’s first moves was to set up a cross-functional steering team made up of Moar, another general manager from a larger product division, their business unit leaders, the corporate vice presidents of sales and service, and a senior product development cross-functional team leader. Moar and three of his peers reported directly to the CEO; the others reported to those four. The goal: represent all major stakeholders, have sufficient clout and credibility to sell proposed solutions to the entire organization, and reach far enough into the organization to know what was really going on.
So how are they doing four years later? Did the changes take root and, if so, what did they do to make that happen? While acknowledging the inevitable bumps in the road, principal software engineer Maryanne Gay, a member of the three-person team established to facilitate the new process implementation, says that the changes have substantially taken root, and that the company has developed 50 products and averaged more than 17% growth over the last four years.
Gay credits three factors with much of the success:
- the company’s decision to create a core team structure, supported by functional teams, and to let functional team members define for themselves the role of their function on cross-functional development teams;
- the deployment of significant resources to process facilitation;
- visible and strong senior management support.
SELF-DEFINING CORE TEAMS INCREASE BUY-IN
The structural linchpin for what DataCard wanted to accomplish was the creation of strong cross-functional core teams as centers of action. For large projects, these are full time, dedicated teams. For smaller projects, a given person will serve on more than one team. The company is driving toward the goal of one person being on no more than two core teams at a time. In the beginning, the basic functional representation included engineering, marketing, service, sales, quality, and manufacturing. A critical factor in the successful launch of the core team concept, says Gay, is the fact that the company brought in reps from these functions to define and document what their roles and responsibilities for product development would be at the very outset, and to train their functional cohorts.
Today, once an idea is approved by the Program Review Board (the new name for the steering team), a core team is chartered. Members are selected by their business units, with the core team leader having final say. The team gathers requirements, works with functional teams to put together a plan and schedule, and carries the action forward until the new product has gone into production and a warranty phase has passed. The teams must meet at least once a month, though most meet more often. In any event, when the teams include members from outside Minneapolis, they try to meet face-to face monthly. (Teleconferencing, videoconferencing, and e-mail can be terrific, says Gay, once a team has been socialized, but before that point she firmly believes in face to-face meetings).
Core team leaders are full-time. Gay says the situation with core team leadership has been dynamic, partly reflecting rapid growth (40% of their Minneapolis employees are new in the last four years). When they started out, she says leaders were about 50/50 from marketing and engineering. They’ve reverted to a 20/80 ratio, in part because the firm’s traditional engineering dominance remains alive and well. But in Gay’s opinion the reality is that the members of the teams are so strong that leadership is substantially a shared affair. Says Gay, “We try to make up teams with people who complement each other. Most core team members have MBAs. If we have a core team leader who is technically strong, we know we need to have a strong marketing person on the team.”
Recently they made two significant core team changes. The folks from sales felt that they weren’t really adding much value and asked to be excused from team membership or to redefine their role and responsibilities to add enough value to warrant the cost of their being on the teams. The company decided to excuse the sales function and assign its stake to marketing. Also, once requirements have been set, they now assign a full time purchasing person to work with a team.
Notes Gay, of the second change, “That’s been instrumental in setting up vendor relationships, finding good quality parts, and making sure the design includes as many common parts as possible. The teams are finding that vendors can help them solve problems. It’s also helping them hit their product cost goals because the purchasing person is right there to negotiate the cost and quantity.
The core teams are supported by functional teams, which deploy common resources across two or more teams. Gay admits that DataCard is experiencing the normal gripes of a matrixed organization, with core team leaders complaining that it doesn’t work well when their team members report to functional managers. However, she sees the matrixed model as critical because scheduling activities and deliverables is an iterative process and involves shared resources. (The company deploys a scheduling specialist to help teams with this). Moreover, notes Gay, you lose focus if you try to wear two hats: “Having been both an engineering manager and a project manager, I find that it is very difficult to do reviews and be concerned with people’s career development at the same time you’re trying to get a project done.”
PROCESS GROUP FACILITATES
When the company launched the change, it created a dedicated three-person product development process group that reports directly to an executive who in turn reports to the COO. Including Gay and a hardware and software specialist, these are technically strong people whose full-time task is to keep the teams and the process on track. They are responsible for development process training-a substantial personnel investment for a company of its size. They also meet monthly with core team leaders to review problems and, when appropriate, suggest an interim review with the steering team. For the past year, they have also sat in on core team meetings as mentors.
With a total team population of about 200 to be covered by three people, Gay says most of her day is filled up talking with people. Lacking some of the “soft” skills, on which a great deal of their work depends, the technically adept process mentors have themselves needed coaching in good training techniques. Cautions Gay, with a few years’ experience behind her, “We really underestimated how often we’d need to train. We thought we’d train the existing employees once then just keep up with the new hires. It doesn’t work like that. Once people tried it, they had even more questions. So training becomes an ongoing thing.”
The process folks also serve as crisis intervention professionals. When the change began, for instance, engineering and marketing had far more senior people than did manufacturing and service. As time went by, Gay says it was not uncommon for manufacturing and service people to sit quietly through team meetings, then, as soon as a decision was made, go tell their boss, sometimes creating problems that escalated all the way up to the senior level for resolution. Or they’d not say anything till a product was introduced, then it was, “I knew it was going to be a problem, but you guys seemed so sure of yourselves.”
On reflection, Gay and her cohorts realized that the manufacturing and service folks were comfortable with the old serial system: “Manufacturing was very proud of being able to build anything engineering threw over the wall. Service was proud of the fact that they could service anything. Suddenly we were asking them to participate in design.” To help them think their way into the new mindset, Gay’s team started to have monthly breakfasts with the manufacturing core team members, and lunch with the service folks, to talk with them about their problems, brainstorm solutions, and consider alternative scenarios.
SENIOR MANAGEMENT SUPPORT & REGULAR MEETINGS KEY TO SUCCESS
Of things that have worked well, Gay says senior management support tops the list:
“Our CEO and COO stand firmly behind making concurrent product development and cross functional teamwork work. They’ve provided resources and allowed us to hire resources we needed to fill out the core teams. When we discovered we lacked seniority in manufacturing and service, they let us go out and get the seniority we needed.” It is not lost on her that their assigning three technical people for full-time process work is itself a major commitment.
Perhaps most important of all is the fact that senior management walks its own talk: the Program Review Board is not siloed and it meets like clockwork every Friday morning, its members having locked the time into their schedules a year in advance. Sometimes these turn into strategic meetings for the business units. But once a month core team leaders come in with their program update packages: the status, key issues and risks, how they’re doing on their out-of-bounds watch list, dates for the next step of milestones, and their estimate of when those will be reached. The bottom-line message that gets communicated, says Gay: “From our executives on down, anyone involved in product development at DataCard is also very much involved in making the transition from a serial to a concurrent product development process.”
Moar’s advice to leaders who want to see this kind of change? “Get out into the organization and understand who is engaged and who is not. And have a mechanism in place that lets you know what’s working and what’s not; take time to celebrate what’s working but be honest about what’s not.”