For the first four years of its life beginning in 1992 as Automated Healthcare, the robot pharmacy maker now known as McKesson Automation was the quintessential startup. Its payroll included only about 30 people. The company made just one product. That product’s developers were also the people who supported it: making phone calls, writing reports, visiting customers, and so on. And the company’s internal communication centered around conversations at its office water cooler. 

Today, as part of the $57 billion McKesson healthcare colossus, the division employs more than 1,000, produces an integrated line of products, and supports more than 700 client hospitals nationwide who use the company’s advanced drug dispensing technology. But even for a company with Automated Healthcare’s outstanding track record, ramping up to such great size so quickly cannot be done relying solely on the work patterns which brought it success in the first place. 

At a June 10 forum of the Pittsburgh Product Strategy Network, McKesson Automation’s Director of Centralized Automation Development Bob Meek, told an attentive audience of local product strategists about his moment of realization. 

Epiphany 

Four years ago, McKesson’s prime competitor introduced a new product. It was a medical transcription device that allowed physicians to handwrite orders, scan them, and then send them to the hospital’s pharmacy through the hospital network. That product, which was marketed as part of a comprehensive medication management solution, led some of McKesson’s customers, as well as its own sales people, to see a gap in McKesson’s approach to medication management. And it prompted the company – which was then undergoing explosive growth – to develop its own competing product. 

That development followed a highly disciplined process. “We went about defining market requirements, talking to customers, trying to find out what it was about the competitive product they loved so much, and what we could do that would make our own product better,” Meek recalled. “We went through a very detailed financial analysis, trying to figure out who might be our solution-providers, what might be the cost to partner up with other people, and what it would take to develop internally. 

The product name ‘MedDirect’ was created and a business case was formulated for presentation to management. Management was enthusiastic. As Meek recalled, their reaction went like this: “ ‘We have a product we can make money on, we can provide a viable alternative to the competition, we can round out our portfolio, and we can probably do it quickly if we bring development in-house and get it done.’ So we were given the green light to put a team together, to begin a development process. We felt that at that point in time, we were really doing everything right.” 

Over MedDirect’s aggressive seven-month development cycle, its crackerjack four-member development team focused obsessively on delivering a product that would work perfectly. Ideal Alpha test sites were lined up. Initial pricing levels were targeted. And a high-profile sales launch at the company’s national sales meeting in Las Vegas was choreographed, complete with theme music from 2001: A Space Odyssey. All systems were a “go”, or so it seemed. 

“Then we had this all-day offsite operations meeting where our Vice President of Operations does his routine check-in to surface issues in the company. All the departments were represented. And as he’s going through the agenda, he comes to MedDirect,” Meek recalled. “And he casually threw out a question as a topic of discussion: ‘we’ve got this MedDirect Alpha Install coming up, are we ready? Do we feel we’re ready to support it?’ This hand goes up. And our help-desk manager says, ‘What’s MedDirect?’ ” That was when Meek knew he had a real problem. 

Left behind

“We had the product, but our company team – the call center, billing service, implementations, and so on were saying that we hadn’t brought those organizations along with us or gotten them ready to bring the product to market and support it. If I were to go to a tradeshow or a customer site with just my four-person development team, we’d be great,” he said. “But next year we’re going to have 50 of these out in the field, and in the year after that there’ll probably be 100. And my four-person team doesn’t have the bandwidth to deal with that.”

That’s when his team lurched into what Meek called its ‘firefight mode.’ “We were able to pull things out and end up with a very positive result. But that positive result came with too much pain,” he said, citing long work hours, high stress, rush charges, communication breakdowns, delays in general availability, and alienation of colleagues. “We needed to mitigate that pain and set the stage for the company’s future so that as the company continued to grow and become more specialized, we could deal with that.”

The tool kit

That was when the Automation group became serious about using the management and planning tools developed to advance projects in large organizations and to expand their circle of influentials within the company. Those new tools include:

• Roadmapping. Representations of the continuum of development processes from idea generation to market launch prepared to help formulate initial time lines, milestones, and resource requirements. 
  
  
• Idea management. Collecting product ideas and managing their status and disposition all across the enterprise, regardless of the mode of their expression. Implementing an software system to capture, change, comment on, track, and direct ideas to the appropriate product managers, was part of that effort. 
  
  
• Product Development Process. Moving from the idea phase to the specifications phase makes use of a five-step gated procedure. At each phase, a determination is made as to whether the right entities are on board before proceeding onto the next steps. 
  
  
• Specification tool. A document template was created and used to communicate to the development organization and other parts of the company how a product needs to work: its functional requirements, market requirements, business theme, and customer interface.
  
  
• GA Checklist. The formal declaration of a product’s General Availability, particularly for a large organization like McKesson, has critical legal and financial ramifications. A checklist shared broadly through the organization communicates the hardware, software, and related impacts that a new product release is expected to have. 
  
  
• Flow-charting. Particularly helpful for new employees, process flow charts help to show how work on current projects moves from start to finish in the company.
  

ABOUT THE AUTHOR:
Peter Longini is a Managing Editor for the Pittsburgh Product Strategy Network. Peter is a former professor of communication research at the University of Pittsburgh and professor of TV-Radio at Brooklyn College, CUNY. During the 1980s, he was an executive speechwriter at PPG Industries in Pittsburgh. Since 1992, he has been the principal of Peter Longini Communications, an editorial services company in Wexford, PA whose clients include various publications, public sector agencies, nonprofit organizations and corporations. In January 2003, Dr. Longini became an adjunct faculty member of New York University and Director of Communications for Cranberry Township, Pennsylvania. He can be reached at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it