Project of Governing

 
 
By Edward Cone  |  Posted 2004-06-18 Email Print this article Print
 
 
 
 
 
 
 


The Project of Governing

Helping achieve the outsized earnings growth was Popper, CIO from 1991 to 1999. Toward the end of his tenure, he created a process for approving the deployment of new information systems that was loosely based on how Merck chose which drugs to develop.

"We had a strong focus on managing the cost and benefits, and on the governance of projects," Popper says.

Project approval committees made up of a mix of business unit and information technology managers would analyze project and technology choices according to risk, cost and potential reward. Committee members would estimate and weigh the cost and potential savings or other benefits in dollars, plus or minus 25%.

The committee would also assign metrics with which to judge success or failure to each project it approved. "If we got the result that we planned, we probably planned it correctly and the system made sense," Popper says.

For example, one project for Merck manufacturing was judged by a reduction in the number of "bad batches" produced by Merck’s pharmaceutical manufacturing plants, he says. As was often true, that result took a combination of systems, such as better software for scheduling maintenance tasks, and other process improvements, such as better training for manufacturing and maintenance personnel, he adds.

At a corporate level, individual products would be tracked in a portfolio, meaning that high-risk, high-return projects, like some of the more adventurous applications being created for R&D, would be balanced against low-risk, low-reward projects, such as system maintenance. Like a stock portfolio manager, Popper wanted to tune this project mix to be neither too aggressive nor too timid. He adopted techniques for graphing the results so he could show other managers exactly where he was placing his bets.

Popper was succeeded in 1999 by Hassan Dayem, who served until leaving for a CIO job at Amgen in May 2002. Popper had hired Dayem from Los Alamos National Laboratory in 1997 and put him in charge of the information technology group assigned to R&D. (Dayem declined to be interviewed for this article.) After Dayem left, his successor as head of Research Information Services, the former Cray Computer executive Irene Qualters, was put in a caretaker role as acting CIO for most of a year while Merck searched for a permanent replacement.

Prof. William V. Rapp of the New Jersey Institute of Technology, who researched Merck for an academic case study on the excellence of its technology management during Popper’s tenure, is convinced that the organization’s strengths—balancing high- and low-risk projects—have remained constant.

"It’s working well, and these kinds of rules and routines don’t change," says Rapp, who published his study in his book Information Technology Strategies: How Leading Firms Use IT to Gain an Advantage (Oxford University Press, 2001). One of Popper’s key accomplishments was securing the involvement of business managers on the project committees, which helped keep systems efforts aligned with business goals, Rapp says.

That was then. That is not now.

Fifteen months on the job, Scalet says he simply doesn’t see the strengths Popper talks about reflected in the process he has inherited. For one thing, the management of Merck technology projects needs "worldwide visibility," he says. "Traditionally, projects were rationalized division by division,’’ Scalet says. "You could wind up with projects that do the same thing in different parts of the world. We need a better way to find out that duplicate projects are going on and bring those together."

At issue is money being spent on duplicative efforts that can, over time, be unified. Yet Scalet is concerned that the project approval committees have been making decisions with so much independence that the result has been systems fragmentation.

For example, Merck uses J.D. Edwards financial software worldwide, but multiple versions and customizations have been implemented. Merck turned to J.D. Edwards for a supply chain system fielded in 2003, but that module was unrelated to the other J.D. Edwards components.

"We took data out of an existing system, and once we were finished with it created a plan that had to be integrated with another existing system—neither of which was J.D. Edwards," says Mark Lind, a consultant from Inrange Consulting who worked on the implementation. "The decision was based on pure functionality," he says, meaning the supply chain managers picked what was most beneficial to them "without regard to anything anybody else in the company was doing." This is one area where Scalet sees "inherent opportunities for consolidation."

Former CIO Popper defends the strategy of not trying to make everything revolve around one ERP system as one way Merck saved money. "When everyone else in the industry was wrapped up in eight-figure SAP-type projects, we stayed with a best-of-breed concept," Popper says. Merck chose the best products it could find in each category for financial management, manufacturing and other functions, stitching them together with message-oriented middleware. "We probably pulled that off with a $10 million to $20 million price tag," he says, and that’s a fraction of what he would have expected to spend tailoring a single ERP system to meet Merck’s needs.

John Blanchard, an analyst with manufacturing and logistics consultancy ARC Advisory Group, says Popper may have a point in that most pharmaceutical companies that adopted ERP systems wholesale in the 1990s have yet to see a return on investment. At that time, a best-of-breed approach "was probably a smart economic move," Blanchard says. But the state of the art has improved since then, he says, "and today I would probably make a different decision."

A consultant who provided an independent review of more than 40 information technology projects under way during Popper’s tenure says about 70% proved to be on track, while the other 30% "went in the wrong direction or nowhere."

One problem: Business executives were so much in control that they would make product selection and project direction decisions "regardless of the I.T. infrastructure," says the New Jersey-based systems consultant. "I don’t think they had the right guidance. You need someone there to play referee."

Without that, the committees sometimes chose whatever they thought was right for their business unit, even if it was inconsistent with Merck’s overall systems architecture.

Former employees say the project committees can bring out the worst in Merck’s bureaucratic culture, leading to "analysis paralysis" or continually expanding project requirements rather than focused effort. Popper admits he doesn’t really know how well the practices he introduced functioned after his departure. "The mechanism only works well if you have the right people implementing it," he says.

In the future, Scalet wants to make sure projects aren’t just approved in isolation to serve the needs of an individual business unit. They also need to be reconciled with an overall systems strategy, he says.

Next Page: Seeking strategic impact.


 
 
 
 
Senior Writer and author of the Know It All blog

Ed Cone has worked as a contributing editor at Wired, a staff writer at Forbes, a senior writer for Ziff Davis with Baseline and Interactive Week, and as a freelancer based in Paris and then North Carolina for a wide variety of magazines and papers including the International Herald Tribune, Texas Monthly, and Playboy. He writes an opinion column in his hometown paper, the Greensboro News & Record, and publishes the semi-popular EdCone.com weblog. He lives in North Carolina with his wife, Lisa, two kids, and a dog.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel