Jonathan Shapiro remembers the instant he knew he wanted to hire Tom Scott as CIO of Lillian Vernon. In Scott's first interview at the headquarters of the specialty catalogue retailer in August 2003, he wowed company president Shapiro when he responded to a routine question about a customer database he had been working on at his then current employer.
Shapiro asked Scott what kind of infrastructure he was planning to deploy the database on. "I'll never forget what Tom said," Shapiro says. "'I knew I could build a state-of-the-art system that would deliver everything the business needed, but I knew I couldn't justify it.'" Shapiro's heart started beating faster. In 25 years of working with CIOs, he had never encountered one so intently focused on business needs. "I said to myself: This is our guy," he recalls.
Shapiro and his partners were aiming to beef up sales by freshening the product line, adding a fleet of sales representatives to sell products from their homes and improving the customer shopping experience in every channel - be it catalogue, Web, outlet store or one of the new reps. To do this, management decided to completely overhaul the archaic systems on which the company grew up. In sharp contrast to the conservative approach taken by most midsize enterprises, the management team decided, fatefully, that speed was crucial. The ambitious plan called for the installation of 10 major applications at the same time, with a tight-but-not-impossible budget and the end of 2004 as the finish line.
Scott was hired as executive vice president of operations and CIO in 2003. Given the scope of the IT projects and the company's limited resources, Shapiro agreed to lead the IT implementation team along with Scott - a team that failed to plan for the effects of so much change so fast. Employees resisted mightily, avoiding training and blaming new applications for their frustration. The company will now miss its ambitious time frame for rolling out all of its new applications and will have to wait until next year's holiday season to capitalize on new efficiencies wrought by IT. Yet as serious as their missteps were, both Scott and Shapiro have managed to incorporate the lessons learned into the continuing rollouts. That's proved critical because the deployment of the most important application - the order-entry, order management and warehouse management system - is only one-third finished. Both men acknowledge in hindsight that the plan was too ambitious. "In a world of perfect information, we might have chosen to schedule this differently," says Shapiro. "The business side had the plans in place before I came on board," adds Scott. "I doubt they understood at the time how much they were taking on."
In a way, that can-do attitude Scott observed in his peers was what attracted him to the job. "Of all the places I've been and all the projects I've been involved in, this is the most aggressive concurrent set of projects I'd ever seen," he says. He was particularly struck by the business managers' apparent readiness to take on so much change at once - something he perhaps should have questioned.
Everything Must Go
Shapiro and the parent company's chairman and CEO Strauss Zelnick were convinced they had to rip out all of the company's systems and start over with a blank slate. For one thing, most of the applications were home-grown systems that were 15 or more years old and totally lacking in capabilities that any modern cataloguer would consider essential.
For example, since the order-entry and customer service systems were not Web-enabled, call centre agents could not surf the Web site along with people who called in to place an order. This frustrated and embarrassed the agents and baffled the customers. Lillian Vernon was largely in the business of selling gifts, such as personalized baby blankets and engraved charm bracelets. But the company could not even offer gift wrap due to the inflexibility of the customer service system.
Merchandise buyers' efforts to dig down into the details of which items were selling in what colours, sizes and styles - the bread and butter of any retail operation - were hamstrung because Lillian Vernon had to pay its customer database outsourcer for each individual inquiry. It was cost-prohibitive to analyze the trends behind the sales data, and without that knowledge, the product mix had grown stale and unappealing.
Another shortcoming: Lillian Vernon did not have a digital asset management (DAM) system. So the buyers and creative services people who put the catalogue and Web store together had to manage product photos and descriptions manually, an extremely inefficient and mistake-prone process.
Among the applications Shapiro and Scott targeted for replacement were the order-entry, customer service and warehouse management systems. Also on the shopping list: the customer database, a DAM system, a merchandise planning application, an overhaul of the Web site and a new financial module.
The business acumen that Shapiro admired in Scott came through when he and his fellow executives began to select the platforms on which Lillian Vernon would rebuild its business. There was no one product or platform that would perform all of the functions the company needed, so integrating systems from a variety of vendors was pretty much a given. But for a company of its size, best-of-breed was not an option. "We are integrating third-party software that best meets our budget and our functional needs. We wanted the best reasonable fit for both," says Scott. If that meant cutting a few corners here and there, settling on a system that might not have been ideal for financial reasons, so be it. The executive team approved. "Tom is extraordinarily good at mixing creative technology solutions with cost-effective solutions," says Shapiro.
The most important piece of technology - from a business-critical perspective - was the system for order entry, customer service and warehouse management. The company's new direct-sales channel, due to be up and running in early 2005 - requires more flexible customer service technology. In the new model, sales reps host parties associated with holidays throughout the year - a Christmas ornament swap in December, for example. Unlike the old Avon model, orders will be shipped directly to customers' homes.
"We'll have reps calling in orders going to multiple different customer addresses. The reps will have their choice of calling in orders to the call centre or placing them on the Web. Our old system was based on single-customer orders," says Scott. The system would also need to handle the complexity of a multi-tiered commission structure, in which reps who recruit other successful reps will be eligible for higher commissions than those who just host parties.
Lillian Vernon would also install its first DAM system to handle product images and descriptions for the catalogue and Web site.
Merchandise planning and inventory control was another critical area, since a fusty product line was largely to blame for the company's post-2000 slide. "We needed a better understanding of what was selling and in what colours and quantities," says Scott.
Lillian Vernon's Web site was due for an overhaul, as well. On the previous site, users couldn't track orders across channels. (For example, if you place an order over the phone, you can track it only by calling.) And the site was not robust enough to handle the leap in traffic that would come along with the growth company executives are hoping to see.
However, in anticipation of the holiday season (which begins with Halloween and accounts for 60 percent of annual revenue), Lillian Vernon stops all new systems deployments on October 1 of each year. The company therefore is holding off on the launch of the new site until January.
Shapiro admits it is frustrating waiting for the new site to launch. "It's a little disappointing. We would definitely deploy it now if our business was the same month over month," he says. But with such a large chunk of revenue at stake during the season (Lillian Vernon takes 37 percent of its orders over the Web) putting off the launch is the safer course. "It doesn't make sense to add to our general business risk by launching a new site during our peak," Shapiro says.
Other projects on tap were infrastructure-related: migrating from Lotus Notes to Microsoft Exchange for e-mail and installing PeopleSoft financials. Because there was so much work, several of the projects were to be driven by user groups at headquarters. Because Scott was on the road for extensive periods, Shapiro agreed to serve as an on-the-ground project manager for the DAM installation.
What Went Wrong
All appeared well in the days leading up to the May 2004 launch date of the DAM system. The team was moving quickly, working with the buyers to improve business processes. However, just before the system went live, Lillian Vernon's failure to take change management into account became painfully evident. The supplier set up classes for end user training, and the buyers and creative services personnel who would be affected dutifully signed up. Although they signed in on the attendance sheet, many employees did not bother to stay for class. "They would pop in, pop out; it was as flagrant a revolt as I've ever seen," says Scott. These employees had already made up their minds that the system was not going to work, and they didn't want any part of it. In retrospect, Shapiro and Scott admit they should have communicated earlier and more often why the project was necessary and how it would affect each individual specifically.
Before the classes began, "we should have put everyone in a room and said: Here is how you fit into this new picture," Shapiro says. Instead, the project team fell back on blanket statements that everyone's job would be "better" once they had ways to handle the product photos and descriptions electronically, as opposed to manually. Once rollout began, however, they were angry when their jobs were harder instead. Since most had not taken the training seriously, they did not know how to use the application. And many were uncertain as to how their jobs had changed. "People were blaming the system for everything," says Scott.
The DAM team also tried to look the other way when the brand-new business processes began to break down. For example, the project team had elected to give exclusive control over a catalogue or Web site entry to the buyers. But the creative services people needed the ability to make changes, moving products to different pages when necessary. For example, a buyer might add a Christmas candle centrepiece to the Web site. But the creative services person might need to move that item to another location for space reasons. Since the creative person was initially not allowed to make changes in DAM system, this led to frustration.
"We allowed clever employees to create workarounds. But that just caused more problems down the road," says Shapiro. Untangling the initial decisions is taking time: The company was still struggling at press time. "I wish I could say we are done suffering," says Shapiro. Yet the company will stay with the software since he and Scott believe the problems were process- and people-oriented, rather than the result of picking the wrong system.
Repeat the Message
When Scott began work on the Lillian Vernon technology transformation, change management did not figure in his list of potential disasters. With so much work ahead, the softer side wasn't on his early radar screen. "Here's what I was thinking: We have third-party packages. We're bringing in vendors who will bring change management expertise to the table. We have capable, gung-ho teams. Giddyap, let's go," says Scott. In other words, launch the projects and fix problems later.
At that time Scott was not a big believer in change management as a discipline. In previous jobs, he had seen enough Big Five firms come in, tell you to do a project newsletter and hold brown-bag lunches with employees, and then charge five-figure fees. It seemed like a lot of time and money spent for not much return. But he rapidly shifted his view of change management because the problems were not confined to the DAM implementation. The toll the change was taking on management and the user community had become evident by late summer. "They would start raising the question of whether we should be on this new system or go back," says Scott. Enterprise-wide, much time was spent rehashing problems such as the DAM snafu rather than solving them.
"What I mistook for them being ready to go was that they just didn't know. I found out partway through that a lot of the employees had never been through a single systems project," says Scott. It was essential to communicate more clearly to employees, to speak to them as individuals well in advance of the project getting under way. Scott has learned that, far from being a frill, basic communication creates the underpinning for a successful implementation. The essence of change management, in his view is "a few well-placed, well-delivered conversations to the right audience. And then you follow up, again and again," he says. "There's not a whole lot more to it." Bowing to the change management gurus, his project office started publishing a project review newsletter in July, which he believes has gone a long way toward helping employees understand how they and the company stand to benefit from the project. "You have to say why you are doing this - not once, but many times," says Scott.
The good news is that Scott has put the lessons learned immediately to work while overseeing the other projects. Deployment of the most important system - the application for order entry, customer service and warehouse management - is only one-third complete. But the implementation so far has already gone much more smoothly than the DAM rollout. "We addressed change right from the beginning. Accountability was clear; not knowing where they stand drives people crazy," says Scott. He also appointed a certified project manager to each project.
Not surprisingly, the time line for the projects has slipped. Whereas Shapiro and Scott had once envisioned having everything complete by the end of 2004, now only the DAM system and the Web site are complete. The merchandise planning system installation will be done by March. And Scott says the order-entry and management system project should be complete by August.
But then again, he knows now to expect the unexpected. "The [order-entry and management system] project will undoubtedly go off course several more times before we get it in," says Scott. "You think the rollout will be like drawing a straight line between two points. But really there are going to be lots of zigs and zags. You can count on a lot of wrong paths and detours. It's just how quickly we get it back on track."
Road Map For Change Management
1. It's not all BS.
Even if you have been a change management sceptic such as CIO Tom Scott in the past, believe it: People have trouble assimilating change, and your project is at risk if you don't recognize that. But there's a lot you can do to help the organization over the hurdles.
2. Show them the big picture.
This includes why the company is undertaking the effort and why it is important for business goals. Also, talk about the normal course of projects and the inevitable ups and downs all projects go through. Do not assume anyone has been through a major IT project before.
3. Show them the small picture.
Let each individual know how his own job will change as a result of the project. Do not ever give the blanket statement "This is going to make all our jobs better."
4. Get in front of your audience. Repeat.
Take for granted that you're going to have to repeat these messages several times to the same people. Change throws the organization into doubt and turmoil; people don't listen well when they're threatened.
5. Be honest.
If some people will lose their jobs or if that decision remains to be made, work with HR to be up front with employees. What they don't know will hurt them and your project.
6. Don't even begin without solid project management skills.
Even if the vendor brings in a project manager, designate an in-house PM and make everyone's roles clear.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.