Healthcare Software Development: We Can Do Better - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Healthcare // Leadership
Commentary
10/9/2014
09:06 AM
Todd Dunn
Todd Dunn
Commentary
Connect Directly
Twitter
RSS
100%
0%

Healthcare Software Development: We Can Do Better

Yes, users do know what they want from software. And developers must listen.

Benjamin Franklin said, "An ounce of prevention is worth a pound of cure." Then why is so much software rework done today, and why do so many software products fail to delight users?

In my view, it is because most companies don't understand or implement soft skills to develop great software.

In my career in the software business, I have experienced and/or led a number of interesting failed deployments. One effort involved software designed to help physicians enter orders. As homework, one tech person spoke to a physician and translated the physician's insights to an analyst, who wrote them up. An engineer then developed the solution and tested it for quality assurance, and the implementation team installed it.

But the receiving clinicians at another hospital wanted nothing to do with it, so it was back to the drawing board. The IT team went to fix it. Who got egg on their face? Development -- and not because of a lack of talented people. I strongly believe it is because the approach used old processes and an old mindset. We can do better.

Engineers, analysts, and others often believe they know what the user needs. A friend's teammate, who happened to be a trained physician but never practiced medicine, often said, "Users don't know what they want."

The fact is, he didn't know either. How could he? He may have studied and even practiced a little medicine. He may have done the job years before, but he was no longer involved in the medical field. A user may not know how to express what they need, but they certainly know, as Clay Christensen teaches, the job to be done. We can do better.

[Don't talk yourself out of opportunities. Read 'Why Not?': Power Phrase For Women In Tech.]

The first change we must make is to observe. We must do the contextual inquiry needed to understand why a user will "hire" the software. It must be done with a "customer empathy" mindset. Success stories achieved in other industries can show us the critical nature of this approach.

A good example is Huggies Pull-Ups. Parent company Kimberly-Clark created a whole new product line after spending time with parents and understanding that diapers are about the growth and development of babies. Another favorite example is the Oxo Good Grips measuring cup: After watching people crouch to see the lines in their measuring cups, Oxo designed its cups to be legible from any angle.

Agile, scrum, rapid cycle ... these are terms we are becoming more familiar with. They are often touted as the balm that will heal the wounds of bad software. So why do companies who get these theories right still build less-than-thrilling software? Are we focusing too much on the middle of the software information chain and on developing better engineering skills and capabilities?

We need to teach contextual inquiry skills to observation teams. Software, as innovation, is a collaborative team sport, yet we don't seem to collaborate around the context of the job we're doing. We still fail to think of software development as a team sport. What information does a developer need to do a great job? What information does a quality assurance person need to do a great job? The same question can be applied right through to the implementation consultant.

But it all starts with the user. In his famous article Integrating Around the Job to be Done, Clay Christensen asks: "Why would someone 'hire' a milkshake? What 'job' are they trying to get done?"

Many people talk about user-centered design, and I agree with that mindset. With a little creative license, I suggest that we should add "job-centered design" as well. We need to teach the mindset and skillset, and instantiate the toolset that enables great observation teams and outcomes.

Consider the concept of a "love metric." IT experts are familiar with the metrics of on time and on budget. However, these are entry-level expectations -- they are simply expected, but we are rarely rewarded in the long term for achieving them. Isn't our job really to help users get a job done?

If users want software to help them more easily record a patient note, or get paid faster, we must instrument our code and reviews to determine if the software delivers what users would love it to do. If they love it, we've succeeded.

Avoiding audits and vendor fines isn't enough. Take control of licensing to exact deeper software discounts and match purchasing to actual employee needs. Get the Software Licensing issue of InformationWeek today.

Todd Dunn is the Director of Innovation for Intermountain Healthcare's I.S. Organization. Todd has worked for notable companies such as Cisco, Siemens, and GE. Todd is responsible for implementing a broad based innovation program specifically focusing on employee engagement ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
AnnaK746
50%
50%
AnnaK746,
User Rank: Apprentice
1/5/2017 | 7:55:01 AM
I would like this idea
this apps have 2 side. I read about different application, and use some of them https://itechcraft.com/custom-healthcare-solutions/ . if app can save life it will be great. but I think it can have other side. these apps can distract physicians from work. What do you think about it?
JeffC712
100%
0%
JeffC712,
User Rank: Apprentice
10/22/2014 | 2:10:31 PM
Re: we can much better
You get what you measure.

Todd says it well: "IT experts are familiar with the metrics of on time and on budget. However, these are entry-level expectations -- they are simply expected, but we are rarely rewarded in the long term for achieving them. Isn't our job really to help users get a job done?"

Too often in software development is the mandate that something be "on time and on budget". Sometimes, in order to "really help users get a job done" a software developer has to sacrifice something "on time" - but if on time is what the developer's performance is based on, then it shouldn't be a surprise that innovation and "really help users get a job done" frequently doesn't happen.
PedroGonzales
100%
0%
PedroGonzales,
User Rank: Ninja
10/9/2014 | 8:47:10 PM
we can much better
You hit the right with this article.  In IT, we can do it much better, but we need to change our approach in tackling users' problems.  What is the purpose of using current metrics to evaluate a project, if the end result is a project that would never be used at all?  This is a good time to re evaluate our approach and provide an IT project that users would truly love.
Slideshows
IT Careers: Top 10 US Cities for Tech Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  1/14/2020
Commentary
Predictions for Cloud Computing in 2020
James Kobielus, Research Director, Futurum,  1/9/2020
News
What's Next: AI and Data Trends for 2020 and Beyond
Jessica Davis, Senior Editor, Enterprise Apps,  12/30/2019
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
The Cloud Gets Ready for the 20's
This IT Trend Report explores how cloud computing is being shaped for the next phase in its maturation. It will help enterprise IT decision makers and business leaders understand some of the key trends reflected emerging cloud concepts and technologies, and in enterprise cloud usage patterns. Get it today!
Slideshows
Flash Poll