Browsing all articles in Lessons learned

Radiology vs IT: Who needs to change?

Posted Posted by Martin P in Lessons learned     Comments No comments

As I was pinging a reply to Doc Dalai’s IT-bashing, it became less of a reply and more of an article in itself so I thought I’d put it here.

I’m primarily an IT guy, although with some qualifications in Medical Physics.  I’d like to think I’m more of a help than a hindrance but I’ve certainly seen some extreme examples of the latter that explain (at least partially) where some of the schism arises.

There are good reasons for entrusting IT services to a service department.  The fact is, IT professionals have the skills (usually), the time (sometimes) and the mandate (always) to know stuff that even enthusiastic non-professionals don’t.  As an extreme example – on a number of occasions – online and face-to-face – I have had to explain to folk in a technical decision making position why the question:

Which is beter for my PACS – RAID or SAN?

…is a dumb question, which really, really, really, should not be asked.

Abstracting a given set of service functions to a separate department is always going to create boundaries that must be overcome at a cost, and that certainly isn’t confined to IT. I recall in the mid-90′s when working for a large US multinational (in London), which due to the nature of its operations had an unusually active Health and Safety department.  As a result, the maintenance department had a rule that every plug/fuse combination must be tested once a year and if the test expired, that plug MUST NOT BE USED, even though they were not always able to perform that function in good time.  Now how disruptive is that?  The complexity and reliance that organisations in every industry place on IT means that any over-zealousnous has a disproportionate impact really only precedented by electricity services in the past.

I know of IT professionals in the healthcare industry who would like to take a strong stance on what can be restrictive policies such as security.  Like the plug testing rule, all of these policies are, in themselves, good ideas, but it can be easy for zealotry in creep in.  Even though there is much evidence (here and here – ok perhaps that last one isn’t exactly evidence :-) ) that security advice doesn’t protect against the very real risks faced, the fact that the risks are real is undeniable, and precautions MUST be taken.

The bottom line is this: The management in any organisation must first realize for themselves, and secondly communicate to all organisational units (especially IT – but certainly not only – remember even Radiology is in itself largely a service department to other clinical specialties) that each service cannot be considered an island. Decisions in one department can have significant impact in other departments, which affect the delivery of the overall mission.  That message sometimes get lost in the noise generated by management targets and ‘Key Performance Indicators’.

But then again, there has to be a balance.  If everybody consulted everybody else about the impact of every decision, absolutely nothing would get done.  Some people find the balance, and some don’t.

So to answer the original question – who needs to change?  I think in many cases, probably no-one.  There are places (certainly on a department-to-department relationship level) that find that sweet spot. But in many others, it should be said:

  • IT staff need to be part of the solution and not part of the problem – and know it!
  • End users (certainly not just in Radiology) need to be aware that actually there are good reasons why security protocols are in place, or the servers need to go down for an hour every month.. because there are, but realistically, having to explain why will make everything take sooooooo much longer.

I don’t believe even the zealots are too far from that goal.  The biggest step is for folk to trust their colleagues to be part of the solution.  Trust is built rather than delivered. But its a two-way process.  Now there’s a thought for the New Year.

Why New Systems Fail: A (brief) review.

Posted Posted by Martin P in Lessons learned     Comments 1 comment

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:


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.


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.

Why New PACS Fail

Posted Posted by Martin P in Lessons learned     Comments No comments

In many ways, RIS and PACS are unique in the world of ‘enterprise’ systems.  But in many ways, including many of the reasons that new procurements go awry, they’re very much like other enterprise systems.

/. has a book review for a new book on Why New Systems Fail. Does this bit sound familiar?

Throughout the book, Simon puts a significant focus on human factors in project success and failure. He identifies issues such as internal politics, kingdom-building, reluctance to learn new systems, internal project sabotage, end-user resistance, and staff allocation. Simon divides firm personnel assigned to work on the COTS project into four groups — willing and able (WAA); willing but not able (WBNA); not willing but able (NWBA); and neither willing nor able (NWNA) — and talks about how each groups helps or hurts. Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All.

Mine is on order. I’ll report back here.

14-Aug EDIT:  Report here.

A note on javascript-y user interface

Posted Posted by Martin P in Development, Lessons learned     Comments No comments

The use of javascript is pretty ubiquitous now. Even without considering the full-scale ‘webapp’, it is commonplace to find javascript doing client-side field validation, if nothing else.  One feature that javascript enables that I’ve rather liked in the past is for fields to be hidden and subsequently presented only in the right context.  So, if one considers a single survey form, which may ask the question; Who is the hottest? a: Scarlett Johansson ; b:Nicole Kidman ; c: Other.  Only when ‘Other; is selected does a text entry field appear for the user to elaborate.

Now in this simple example, its probaby a little over-complicated, but it would be easy to envisage a form such such UI logic would clear (unclutter) the screen, enhancing user experience.

But I think now that idea can be taken too far.  I have just spent a little too much time working out how to configure a monitoring tool (Hyperic) to help maintain a DCM4CHEE DICOM archive.  Hyperic is a great choice because it shares the same application server layer (JBoss – although I had a little issue with conflicting JRE versions which apparently will be addressed in the next version ), and is, overall, a fine product.  But, geek as I am, I tried configuring collection intervals without resorting to the documentation.  In each page where I thought there may be a route through to the config, no route was obvious.

Long story short,  the config route only arose after I selected a specific metric to indicate that I wanted to ‘do’ something with it.  On the plain page, there was little clue that indeed that page is the one I need, so instead of digging deeper, I went elsewhere, to equally no avail. In the end, a peek at the documentation gave me the clue – if I select a metric, the config will apear. Admittedly, if I’d paid a little more attention I would have spotted where to go but this is a note on properties of UI generally and not (NOT) any criticism of Hyperic.

A short sharp lesson in building new-paradigm applications.  I don’t know if it is naturally intuitive to have visual clues around a UI or just what we (I) have become accustomed to over the last couple of decades.  But it is regardless where I (as an Hyperic user) stand at the moment.  I need lots of visual clues about what is available on each page of the application.  That is why simple drop-down menus worked so well.  Give me a week, and maybe I’ll need less.  A month, and even less.   One for follow-up.