Special Report: Human Error

The Defense Logistics Agency (DLA) thought it was on its way to achieving more efficient purchasing when it unveiled its Procurement Gateway website two years ago. The site was designed to draw from several integrated databases to provide solicitations, specs, drawings and other contract documents online. Its aim was to make it easier for vendors to sell to the agency, thereby attracting more bidders and better prices for everything from paint to parachutes.

But buyers at DLA, the part of the U.S. Department of Defense that provides supplies and services to U.S. military bases worldwide, were posting only about half of their requests for quotations (RFQs) online. Some resisted using the site; others simply forgot it was there. Either way, it was an extra step that offered little apparent return. Buyers found it easier to hand the information off to clerical workers to mail to bidders who asked for it.

Then last summer a reorganization sent 150 of those clerical workers packing, and the buyers were inundated with paperwork. That's when Gateway Administrator Rosanne Sarkissian, who manages the website from the DLA's Defense Supply Center in Philadelphia, saw a golden opportunity to show buyers how the site could help them do their jobs. By February 2000, buyers were using the gateway for 90 percent of their RFQs, saving the agency $4 million in postage and cutting from three weeks to five days the time it takes for an RFQ to be awarded to a bidder.

In hindsight, it is obvious to Sarkissian that the buyers should have been trained at the outset. But in grappling with closing supply centers and cutting jobs, managers overlooked the need for training. And it took a near crisis--buyers unable to do their work--before managers realized they had not built enough internal support for integration.

The DLA's saga is far from unique. The biggest challenge to integrating the enterprise isn't choosing the right hardware and software, or even crafting a sound business case. Whether it's a data warehouse, enterprise resource planning, knowledge management or a customer relationship management system, these projects founder time and again because the people who have to use integrated systems can't, or aren't convinced that they ought to. Yet shepherding diverse business divisions, each with its own culture and databases, through an integration project often gets less attention than either the technology or its anticipated ROI. Even when companies follow what they think are the rules--communicating their vision to employees and training them to use the new systems--success can be elusive.

It doesn't have to be that way. The advice that follows is common sense. But the obvious is easily lost amid the complexity and pressure of these all-encompassing projects. To recover it, ask yourself three questions:

How well do you really know your internal customers?

Do they trust you?

What's in this project for them?

Understand Your Customers

You may think that what happened to David Johns is so easily avoided that it could never happen to you. But Johns, CIO with Owens Corning in Toledo, Ohio, was sure he was doing everything right when, three years ago, he was in the midst of deploying SAP's ERP system. The project's goal was ambitious: to integrate the company's supply chain for manufacturing insulation and other building materials.

After rolling out smaller versions of the system to two of the company's divisions, Johns readied his first major installation for the company's $1 billion roofing products business. He thought he'd covered his bases for the 32-location rollout. Owens Corning's top leaders were solidly behind the project. Executives and project leaders held "town hall" meetings and videoconferences to explain how the SAP system would make the company more efficient and help it pursue new customers. Workers were trained. But when they booted up that first morning, work at several sites ground to a halt.

While there were some technical bottlenecks, more fundamental flaws surfaced as well. "One of the things we did when we trained people was [tell them] that they needed to pay attention to what the system says. [But] we didn't have processes well enough defined, [so] the system came out with bad answers," Johns says. Employees, doing what they had been told, looked to the system instead of talking to each other when common sense told them something was amiss. In one instance, workers let a truck carrying a single pallet of shingles leave the plant--even though they knew it was a mistake--because that's what the system told them to do. Such errors were costly, Johns says.

"One of the biggest costs of [producing] our product is logistics."

For the next deployment, Johns had workers kick the tires "dozens and dozens of times" before going live. For example, they entered test data into the system to make sure that orders placed would result in products being properly shipped and invoiced. Johns also modeled how employees communicated with each other, to make sure the system enabled them to get the information they needed at every stage of the manufacturing and distribution process. Previously, each location had operated almost as a separate business, with its own data flow. With more careful testing and planning, Johns and his team finally got it right. He notes that production planning now goes more smoothly and that Owens Corning has been able to reduce its inventory while providing better service.

"One of the things we never tested in the first major business [deployment] was the communications process end to end," Johns says. "It sounds pretty stupid, but believe me, we did it." Johns found out that employees had never quite absorbed the magnitude of the changes that the system would wreak. "We never validated that the people were getting the message," he says.

Johns' experience is typical. Corporate IT staffs and business-line executives alike get so immersed in big integration projects that they forget not everyone in the company understands the project as well as they do, says Michael Coovert, a professor of psychology and director of the Institute for Human Performance, Decision Making and Cybernetics at the University of South Florida. Executives who are trying to meet project deadlines on top of doing their regular jobs get pressed for time, and communication with the rank and file about how the business will change consequently suffers.

Furthermore, the right people aren't always invited to participate in the necessary business-process redesign, particularly key sessions where business units hash out what data is going to be included in the new system and how it will be represented. Accountants and human resources specialists can each make the case for their own data, but the team also needs people who understand the relative importance of each data set to the larger project, Coovert says.

TRUST ME Once bitten, twice shy is how Coovert describes end users' attitudes toward major IT projects. "The way people react is tied to how they've been treated in the organization," he says. If there's a history of people being left out of the decision-making process, they may respond with suspicion, feel threatened and be reluctant to cooperate, he explains. Before embarking on an enterprisewide project "you need to take a look at the current work climate," he says. "You have to look at morale, turnover, absenteeism, worker conflict."

If you find trouble, you should take that into account when you assemble your team and be sure to involve people who can do something about it.

When Joe Cleveland, president of Lockheed Martin's Orlando, Fla.-based IT division, Enterprise Information Systems, started a long series of corporate integration projects five years ago, he knew he needed to convince business managers to trust him. The company had just been through a major merger with Martin Marietta Corp. and was about to merge with Loral Corp., and everyone knew management would be looking for ways to become more efficient. In fact, executives had promised shareholders to trim $1.5 billion in IT expenses. But at the same time, the changes threatened employees who believed their jobs would be different, or eliminated, once new systems were in place.

Cleveland didn't have time to get to know the stakeholders among the 140,000 employees in the new company, so he put together a transition team with IT representatives from its many subcultures. The team scrutinized every system and decided whether it should be retired or rolled out to the rest of the company. For some functions, existing systems were scrapped entirely in favor of brand-new technology. With each subculture represented, Cleveland says that employees could "feel comfortable that things have had a fair hearing, that people who know their culture are making a recommendation [and] that is the best decision."

That's not to say every decision went smoothly, or that everything was accepted by end users. Cleveland won't get specific--"to protect the innocent"--but says he sat through some tough meetings, including some with top executives, where argu-ments were made against integration. Opponents weren't only worried that a new system wouldn't meet their requirements; they also saw threats to their status within the company. Cleveland describes their arguments this way: "If you choose [the system that supports] my process, you'll also need me because I'm an expert on my proc-ess. If you choose another process, I have some catching up to do because those who know that process are the experts."

But, Cleveland says, he didn't dismiss any complaints out of hand. Some objections turned out to be legitimate. For example, the executives who ran Lockheed Martin's state and local IT services business, which supplies customers with engineers and software, argued against using a common procurement system geared toward buying parts for missiles and satellites.

"Procurement was not a big part of their job," Cleveland says, so it didn't make sense for them to make the investment. In general, the company did not insist that customer-facing systems, such as those that support manufacturing custom products or customer relationship management, be uniform. Because those systems have to support a wide range of customers' needs in addition to company objectives, one approach won't work for everyone. "As you move farther from the customer, it's more likely you are dealing with infrastructure," Cleveland explains.

That's why when it came to back-office systems Lockheed Martin held its ground.

The company recently chose to deploy standard human resources management applications from PeopleSoft to automate routine tasks such as posting job openings, to standardize benefits and payroll, and to give managers a corporatewide view of staff assignments. Top executives tried to cajole reluctant human resources departments within the company by promising to reduce their paperwork, but they also made clear that corporate ROI from the PeopleSoft system (which will be fully installed in 2002) trumped any benefits to keeping homegrown applications, and they had to go along with the standard.

When he started out, Cleveland estimates 70 percent of the workforce supported his team's integration decisions. The rest, who bore the brunt of the changes, either acquiesced or left the company. "There were always people who did not agree with the answer, but if they thought the process was fair, they supported it," he says.

MOTIVATE EMPLOYEES TO CHANGE When enterprise systems projects fail, it's usually because management has neglected to consider what will motivate employees to use the new systems, according to Leslie Wilk Braksick, who's president and CEO of The Continuous Learning Group, a Pittsburgh company that helps organizations anticipate how employees will respond to major business changes. "Rarely have I seen that [the problem is] really the wrong strategy or the wrong vendor," she says.

"Consequences drive so much of what we do. Most managers just communicate what they want done differently. They don't realize that reinforcers are built to enforce old behaviors," Braksick says. She tells of a company that installed a new financial management system to replace a set of spreadsheets used to produce financial reports. The president of the company didn't want to learn how to read the new reports. So his assistant kept generating reports from the old system and basked in his boss's praise. The lesson, says Braksick, is that unless end users get rewarded for contributing to or using a new system, they'll be reluctant to do so.

This problem has plagued the Department of Defense in its numerous attempts to integrate systems used across the department for administrative applications like procurement, finance and personnel. "The DoD as a whole is not used to being an information-sharing organization. There are many people who still feel that harboring information and letting that be their functional domain is more important than sharing information," says Marvin Langston, who was deputy CIO with the DoD until January, when he left to become chief operating officer of Salus Media in Carpinteria, Calif. Four years ago, the DoD canceled an integrated inventory-management system project after spending more than $700 million, largely because business-line managers could not agree on what the system should do and wouldn't commit enough money to deploy it.

Langston says that stovepipe mind-set is changing because a younger, more technology-savvy generation of both managers and end users in the ranks is more open to new ways of doing business. "They're impatient, and they're looking for us [DoD IT] to move faster," Langston says, making them natural frontline allies for IT executives pushing integration. It's also getting easier to persuade top officials to commit money to integration projects these days because without efficiencies from sharing data, it will be harder for them to fulfill their missions.

Getting the top brass to fund integration projects is critical because otherwise, base commanders, at the bottom of the military management chain, are left with the cost and the headache of deploying the new systems. Though they may support the goals of integration, spending money on such projects means that other needs, more critical from their point of view, can't be met. But after a decade of DoD payroll cuts that cost thousands of jobs, senior managers have been more willing to set aside funds for integration. With fewer people to carry out support functions like acquisition and logistics management, "we're trying to get enough efficiency into product lines or functional lines so [we] have a snowball's chance of getting the job done," Langston explains.

IT'S NOT THE TECHNOLOGY, STUPID Corporate systems integration projects "are [usually] treated as technology projects rather than how business gets transacted," says Braksick. Instead of focusing on what she refers to as "screens and data," CIOs and system designers need to be more sensitive to why end users should want to use new applications. "You're changing how people have to interact with one another," she explains. "If their lives are made more difficult, it's going to be a net negative for them."

Johns of Owens Corning would agree. "We had systems and processes in place for 20 years, and people get used to that," he says. "We were very enamored of the technology itself. The IT piece of it is the smallest and easiest part, yet that was where we put our focus when we started this thing. You have to be enamored with the people aspect, the process aspect and the organizational aspect" of an enterprisewide project.

Lockheed Martin's Cleveland says that for enterprise integration projects to succeed, CIOs need to keep a constant eye on the entire landscape. "We looked at people, process and technology simultaneously," he says. By thinking about all three dimensions in tandem you can see more easily how changing one of them affects the other two, he concludes, and "you're less apt to make a false start."

Senior Writer Elana Varon enjoys change, as long as she can fit it into her routine. Share with her your stories of integration battles lost and won at evaron@cio.com.

THE POWER OF LISTENING For integration to succeed, the CIO must have a firm grasp on business needs Southern California Edison Vice President and CIO Mavash Yazdi understood the importance of listening closely to her business colleagues when she launched a massive IT integration project two and a half years ago.

A response to deregulation of the electrical utilities industry, the integration project aims to create a common infrastructure to support corporatewide, integrated applications on 19,000 desktops run by a central IT organization. Edison wants to reduce overhead as well as pursue new markets abroad and sell new services like telecommunications to both existing and new customers. Sharing data about customers, suppliers and power plants companywide is one source of fuel for this growth.

According to Holly Kolinski, vice president of SCE's Mass Customer Division, the company has handled the transformation, accompanied by the consolidation of its IT operations this past January, much better than other companies she has worked for in the past. Kolinski recalls her experience at an international services organization where a similar revamp took place. "While there was a level of participation, it was presented as, 'This will be done, and the organization will look like this, and you will interact this way.'" At Edison, she says, "there is an openness and a willingness to work together."

"We spent a lot of time with our business entities understanding the direction they're going," says Yazdi, who with her management team and consultants conducted one-on-one interviews with key internal customers and senior managers.

They learned that managers wanted assurance that with a central IT staff managing integrated systems, they would still be able to get someone on the phone when they had a problem. Yazdi responded by putting her customers in charge. She reorganized IT on a service model to make it simple for them to get their requests for IS services filled.

Kolinski says that partnership has been a critical factor in the smooth rollout of a new SCE customer service system, which has been designed with the extra capacity her department will need as the company grows. In addition, its ability to capture more information about workflow will help her make customer service more efficient. -E. Varon OH, BEHAVE Six steps to get user buy-in for integration projects CIOs can anticipate which aspects of their enterprise integration projects will cause problems for end users by becoming aware of the messages they are--or aren't--sending along with new systems.

In a new book published in January, Unlock Behavior, Unleash Profits: How Your Leadership Behavior Can Unlock the Profitability of Your Organization, Leslie Wilk Braksick, a Pittsburgh-based business change consultant, offers help. She spells out six steps executives can use to specify the behavior they want to encourage from employees, identify the incentives--or lack thereof--for compliance and determine how they should encourage workers to change their ways.

At the core of her method, which Wilk Braksick calls Changing Yesterday's Behavior for Enhanced Results, or CYBER, is an analysis of the consequences of behavior. Consequences can be positive or negative, immediate or future, certain or uncertain. Managers should create consequences for employees that are positive, immediate and certain--and avoid those that are negative, immediate and certain.

Here are Wilk Braksick's six steps, and how you might use them:

1. Identify your business opportunity.Your CEO wants to see more repeat sales.

You think a customer relationship management system will help.

2. Target results and measures for success. Loyal customers buy 10 percent more. They rave about the company 15 percent more often in customer satisfaction surveys.

3. Pinpoint and align behaviors that drive results.Sales and product support reps report customer contacts to the system weekly. They look up the latest info whenever they talk to customers.

4. Understand the influences on behavior. Salespeople will use the system only if it helps them sell more. Product support staff will use it only if it helps them resolve more customer problems.

5. Develop, implement and adjust behavior change plan.Company creates new sales/support teams assigned to customers, and team members get bonuses when their customers buy more. Executives publicize new sales and customer feedback that result from using the system. Managers make consistent use of the system, a requirement for a good performance review.

6. Celebrate achievement of improved results.Up to you.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about APTCorningDLAGatewayLockheed MartinLoralOwens CorningPeopleSoftSAP AustraliaTandemUniversity of South Australia

Show Comments
[]