Why New Systems Fail: A (brief) review.

Posted by Martin P in Lessons learned      1 comment

Aug
14

Ok. So having come across this book “Why New Systems Fail” via /. (mentioning it first here), I promised to report back.  So here it goes.

Bottom line first, by page 20 I realised I was only reading it to pick more holes in it, and gave up.  Instead, flicking through to sections that looked like some kind of interesting.  Almost every time I opened a new page, I found something to gripe about.

Before even getting to page 1, I noticed that the key reference on the cover page was from the “Chief People Officer, Quaker Foods and Snacks”.  Not even a CIO. Does that matter?  Maybe not.

But to illustrate with a sample of the gripes I had:

• Page 22, table 3.1 – ballpark costs of implementing systems – is a perfect example of false precision.  According to author, the ballpark support costs for a ‘lower end’ system is $44,000.  Not $43,000, or $30,000.  By introducing the extra ’4′, there is a implication that the precision is more than it is.  And anyway, it’s wrong.  Such a ballpark figure (note: for a ‘low end system’) could be anything from $100 to circa $50,000.  This is exacerbated by the fact that the word ‘ballpark’ appears only in the table heading – not in the associated text.  According to the text, this is “expected costs”.
• Page 85 – ‘the staggered or phased implementation has two variations’.  Given the amount of space given to the discussion of the ‘two variations’, a reader might be forgiven more assuming this is a rigorous discussion.  In fact, there is a whole spectrum of variations not given air althoug, to be fair, the two mentioned may well be the dominant options in the author’s limited scope of HR and finance systems.
• Page 139+ – As well as defining 4 ‘types’ of project manager, the book defines 4 type of client end-users -
  • Willing and able
  • Willing But Not Able
  • Able But Not Willing
  • Neither Willing Nor Able

This isn’t a bad categorisation, although there are certainly others.  The book tells us how each type helps and hinders a project, but gives us very little in the way of actually dealing with them.  What is does say is you have two strategies – a carrot and a stick.  Deep.

In the bits I read, I found the level of insight and writing skill more conducive to a series of blog posts than to a book which, ultimately, I cannot recommend.

Looking back to the origin Slashdot article – I’ve picked up a few of the comments.  There don’t seem to be many on the book itself, which is perhaps a shame, but instead on the nature of IT-based projects and failure.  A couple I particularly like:

rgviza:

You _can’t_ get the requirements right up front because the users don’t even know what they want until they have a system that doesn’t have it. They think they told you what they want, but they didn’t because they don’t know themselves..

.. a bit harsh but there’s (much) more than a grain of truth in that.

T.E.D.:

The best insight on this subject comes from Tolstoy, not Brooks. He was talking about families being functional, not software, but the principle is the same:

All happy families are alike; every unhappy family is unhappy in its own way.

HIT Market Growth and Clinical Process Reengineering

Posted by Martin P in Open Source      No comments

Aug
7

I see from an article on BEyeNetwork that some are forecasting growth in the HIT market.  While there is much sense in the article:

The “big guys” such as Cerner and Epic are not interested in a price point below ten million dollars.

While the point of “ten million dollars” is perhaps a little overstated (by an order of magnitude or two), the idea is valid that many healthcare settings are simply under the radar, and that provides open source solutions with an achievable entry point.

But the author has at least one point very wrong:

Software is a part of every business process and every scalable delivery system. In that specific sense, healthcare is no different, though many details are and will remain distinct to the mission of improving human well being

For a long time I found it confusing and (because I didn’t understand why,) frustrating, that in an age where I can fly from my home in Ireland to a sunny spot in Portugal (or Morocco, or Thailand, or wherever) with a piece of plastic and in a remote corner on the edge of Europe, pull money out of a hole-in-the-wall, I cannot go two hospitals barely two miles apart and have one aware of my record in the other.  The answer is that patient care is very different and considerably more complex than a financial transaction.

The author goes on to say hospitals should:

Understand that the critical path to success includes reengineering the workflow to accommodate the efficiencies of the software…

As Doris might say, yes yes yes yes …. NO.  Clinical and patient care workflow SHOULD NOT be re-engineered to suit software.  There may well be improvements that can be made by re-engineering processes, but implementation of software should not be the driving force behind such re-engineering, but should support the processes that are there now, or may be in the future.

Vendors that understand that, and strive to understand ALL of the processes that go into patient care, do well.  Vendors that seek to impose an artificial vision of heathcare processes, tend not to do well.

NB The article included an idiom I  hadn’t heard before:

Interoperability remains the navel into the unknown…

While I could half-guess what it might mean, I consulted the Great and Good Google and it found only one reference which appears to be a psycho-therapists tome:

There are some patients who cannot get the feel of themselves or move on unless they feel they have seeped through the therapist’s dream navel into the unknown, and that what the therapist says or does grows out of the unknown depths , filters through the dream navel into images, gestures, statements.

It may be that a patient needs to be dreamt by an analyst before the former can make use of dreaming.

Wow.