Enterprise System Spectator blog: ERP and enterprise system vendor evaluation, selection, and implementation.

The Enterprise System Spectator

Monday, February 07, 2011

When smartphones disrupt medical devices

I'm here at the Medical Design & Manufacturing (MD&M) West conference, one of several shows running concurrently in the Anaheim, CA convention center this week.

Along with the trade show, there is an excellent conference program. I am especially interested the tracks on disruptive technologies in the medical device industry as well as updates on the regulatory environment with the US Food and Drug Administration and other regulatory bodies globally.

Here are some highlights of what I've heard so far.

Global competition for innovation

Tracy Lefteroff of Pricewaterhouse Coopers outlined opportunities and barriers in worldwide medical device innovation, based on a PwC survey.

The results are not good for the US.
  • The US is becoming increasingly unfriendly to innovation. Israel is the easiest place to get regulatory approval for new medical device technologies, followed by the EU and India. The US ranks lower down the list. So, if you need treatment involving innovative technology, you may need to go outside the US.
  • The US carries the highest cost per hospital bed, and fewer beds per capita than any other global region--by far.
  • Industry participants expect that the regulatory environment in the US will become even more restrictive in the future.
  • On the positive side, the US is still the best place to raise money for new medical technologies and it also one of the easiest markets to enter, once you have an approved product.
There may be hope, however. Lefteroff reports great interest in Washington to see the regulatory environment improve. Why? Jobs in the medical device industry are leaving the US for more friendly jurisdictions, and in the current environment, anything we can do to improve the employment situation is attractive, on both sides of the political aisle.

Disruptive technologies in the medical device industry

Jeff Brown from UBM TechInsights followed with an insightful look at how consumer technologies are disrupting established ways of addressing patient needs. Brown showed as new technologies reach critical mass, their IP is often transfered into other established technologies, disrupting them and driving down the cost and size of the established products. For example, digital camera capabilities increased and the cost dropped to the point that the technology could be incorporated into cell phones. Today, many consumers do not carry digital cameras, as the cameras in their cell phones are "good enough."

Although Brown covered several disruptive technologies in the medical device industry, much of his presentation focused on how smartphones (e.g. Apple's iPhone) are becoming and will become part of future so-called mobile health (mHealth) solutions.

For example:
  • The AliveCor EKG sleeve turns your iPhone into an electrocardiogram monitor. Note however that the device is not cleared for marketing in the US. More on that issue in a minute.
  • iStethoscope Expert, a free primitive iPhone application, uses the native microphone in the iPhone to listen to and record your heartbeat.
  • Hearing aids, which at the high-end can cost thousands of dollars, are about to be disrupted by blue tooth earpieces connected to smartphones.
In these and many other examples, Brown pointed out the tremendous improvement in capability that comes when standalone devices (e.g. hearing aids, stethoscopes, EKG monitors) are replaced by devices that connect to smartphones. They not only perform the same function as the device they are displacing but they can go beyond with their ability to record and store data and to communicate with other devices.

For example, a traditional hearing aid can only do one thing: help you listen better. But a hearing aid that is connected to a smart phone can take advantage of the smart phone's capability to record and store conversations. In fact, a smartphone could take that recorded conversation and convert it into text and email it to you. One can imagine many applications, even for people that are not hearing impaired.

Innovation vs. regulation

Brown briefly covered the regulatory issues that constrain the convergence of new technologies with medical device solutions. Current FDA regulations treats many of these new applications and distruptive technologies as medical devices, depending on their intended use to diagnose or treat disease, or to affect the structure or function of the human body. This classification puts FDA squarely in the middle of commercialization of such products.

As Lefteroff indicated earlier, other jurisdictions are friendlier environments for introduction of these new converged technologies. It may be that some of these solutions will take hold first in developing countries, where their low cost and "good enough" capabilities will allow them to be perfected and proven.

It is ironic that, while the underlying technologies may have been developed by US companies (e.g Apple), their application as medical devices may only come to the US after they have been established and proven in other geographies.

Related posts

FDA still enforcing regulations for validation of enterprise software

by Frank Scavo, 2/07/2011 05:24:00 PM | permalink | e-mail this!

Subscribe!

Read/post comments!
(0) Links to this post

Sunday, February 06, 2011

Avoiding project death by ROI

I had an unusual experience recently: a client demanded an exhaustive ROI calculation for a project, and the client approved the investment.

How to kill a project

Why is that unusual? First, some background. Over the years, my consulting firm, Strativa, has developed a methodology for building the business case for enterprise IT projects (or, any initiative for that matter). We identify the perceived benefits of the new system (for example), trace them back to features/capabilities of the new system, then quantify the direct financial impact. We also identify the time-phased project costs so we can calculate the ROI, whether by a simple break-even calculation or a more sophisticated internal rate of return. The whole methodology is implemented in an elaborate Excel workbook.

Although we are quite proud of this tool, I have noticed a pattern in cases where we use it. Often, when a client demands an exhaustive ROI calculation ("show me the money"), the project does not get approved. This is true even in cases where our calculations show a strong ROI.

Although I am a great believer in the need to demonstrate financial return, I have come to the conclusion that, in practice, too many executives ask for the business case not to determine whether they should make the investment, but to find an excuse for why they should not.

Now, having said that, there are some cases where an organization's capital expenditure processes require a formal business case. Here, the project sponsor requests the business case not as a means to kill the project but merely to get funding for a project that he or she already wants to do. But apart from these cases, what explains the correlation between client demands to see an ROI and projects being killed?

The "ROI Trap"

My hypothesis is that, due to a reluctance to say "no" directly, ROI calculations are often a convenient way to refuse projects that management simply doesn't want to do.

This "ROI trap" can take several forms:
  • Management argues the project budget is underestimated
  • Management argues the benefits are overly optimistic
  • Management argues the benefits cannot be connected to the proposed initiative
That final point is the most subtle. For example, benefits involving increased sales are the most difficult to get by management review. A new sales force automation (SFA) system, for example, might be justified in part by increased revenue from new sales. The rationale would be that sales people today only spend about 50% of their time selling. The rest of their time is spent looking for information, administrative activities, and reporting to management. By providing faster access to information and automating much of this administrative overhead, sales people can spend more time selling, which should result in increased revenue per salesperson.

The problem, however, is that the organization is planning to do all sorts of things to increase sales, such as any number of marketing programs and new product introductions. If sales do increase after the new system is implemented, how will management know that the improvement is due to the new system and not to other things that the organization is doing? Therefore, when presented with a SFA business case that relies in part on increased sales, the easiest thing for management to do is to say, we don't see the connection.

Who owns the business case?

Is there a way out of this trap? We have found that there is one important key to having a business case approved: management ownership of the benefits statement.

Here is how we now prepare the business case for a new system or business initiative. We hold a series of workshops to collaborate with the client's project team and stakeholders around five questions:
  1. What the objectives for the proposed investment?
  2. How will the project meet those objectives?
  3. What financial metrics would improve if those objectives were met?
  4. What are the baseline measurements for those metrics today?
  5. What percentage improvement would be achieved in those metrics if the project is approved?
We often find, however, that even among the project sponsor, project team, and key stakeholders there can be significant disagreement, especially in answering the fifth question. The reason is simple: stakeholders are going on record that they believe the project will yield certain benefits, and if the project is approved they are in effect taking responsibility for meeting those improvements in performance.

A success story

Now, back to our recent client project, which involved selection and approval of a new customer relationship management (CRM) system.

Early in the project, the client made it clear that a strong business case would be needed for a new CRM system to be approved. Based on my past experience, alarm bells went off in my head. What were the chances that this selection would end in "no decision," to the disappointment of the project team and the vendors asked to bid on the project?

Knowing about "the ROI trap," our consultants took a collaborative approach to the business case. Instead of going off in a corner and coming back with the proposed business case, they brought the client's team into the room and asked the five questions outlined above. The CFO was particularly strong in telling the team: if you say these things are benefits, you can expect your sales quotas and budgets to reflect what you say. Translation: they would be held accountable. The CFO even went so far as to ask us to break down the benefits by region, so that the regional sales managers could be held accountable.

The result? A business case that, perhaps, was understated (due to the desire not to set too high a bar) but one that was still quite positive, and most importantly, one that had the ownership of the stakeholders who would be responsible for implementation.

In the end, the project was approved, and contracts have been signed.

Lessons learned

No one likes to be held accountable, and if the business case for a new initiative is the consultant's work only it becomes an easy excuse for stakeholders to escape responsibility. Collaboration is the key: combining the consultant's methodology and industry knowledge with the client's ownership of the goals and metrics. Then, when it comes time to present the business case, it is not the consultant's presentation but the project team and stakeholders arguing in favor of the investment.

Footnote: way back in 2004, I explored the psychological dynamics of the ROI trap, based on the work of Max Bazerman. These are still quite relevant today. See the related posts below for more discussion.

Related posts

Escaping the ROI trap
Escaping the ROI trap, Part 2

*Image courtesy of Ramberg Media Group.

by Frank Scavo, 2/06/2011 08:02:00 AM | permalink | e-mail this!

Subscribe!

Read/post comments!
(3) Links to this post

Powered by Blogger

(c) 2002-2014, Frank Scavo.

Independent analysis of issues and trends in enterprise applications software and the strengths, weaknesses, advantages, and disadvantages of the vendors that provide them.

About the Enterprise System Spectator.

Frank Scavo Send tips, rumors, gossip, and feedback to Frank Scavo at .

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision. My consulting firm, Strativa, offers assistance that is independent and unbiased. For information on how we can help your organization make and carry out these decisions, write to me.

For reprint or distribution rights for content published on the Spectator, please contact me.


Go to latest postings

Custom Search

Join over 1,700 subscribers on the Spectator email list!
Max. 1-2 times/month.
Easy one-click to unsubscribe anytime.

Follow me on Twitter
My RSS feed

AddThis Feed Button


Computer Economics
ERP Support Staffing Ratios
Outsourcing Statistics
IT Spending and Staffing Benchmarks
IT Staffing Ratios
IT Management Best Practices
Worldwide Technology Trends
IT Salary Report
IT Help Desk/Service Desk Management

Get these headlines on your site, free!


Awards

2013 Best ERP Writer - Winner

Alltop. We're kind of a big deal.
 
Constant Contact 2010 All Star Technobabble Top 100 Analyst Blogs


Blog Roll and Favorite Sites
Strativa: ERP software vendor evaluation, selection, and implementation consultants, California
StreetWolf: Digital creative studio specializing in web, mobile and social applications
Vinnie Mirchandani: The Deal Architect
Oliver Marks' Enterprise 2.0 Blog
Si Chen's Open Source Strategies
diginomica
CISO Handbook


Spectator Archives
May 2002
June 2002
July 2002
August 2002
September 2002
October 2002
November 2002
December 2002
January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
September 2009
October 2009
November 2009
December 2009
January 2010
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
January 2011
February 2011
March 2011
April 2011
May 2011
July 2011
August 2011
September 2011
October 2011
November 2011
December 2011
January 2012
February 2012
March 2012
April 2012
May 2012
June 2012
July 2012
September 2012
October 2012
December 2012
January 2013
February 2013
March 2013
May 2013
June 2013
July 2013
September 2013
October 2013
December 2013
January 2014
February 2014
March 2014
Latest postings