Reply to post: Re: another closed system with no upgrade path

Re: another closed system with no upgrade path

The message I'm getting from this thread is that a major reason for NHS IT systems being unfit for purpose is that apparently THERE ARE NO QUALIFIED MEDICAL STAFF IN THE DESIGN TEAM.

There is no excuse for this: but incompetent project management is an entirely reasonable explanation of why it happens.

One of the most complex (and successful) projects I've been associated with was the BBC's Radio 3 Music Planning system. There are two reasons why it was successful:

1) The initial design team included a newly retired member of the Music Planning Team, a decent project Manager and two IT specialists, of which I was one

2) It was obvious from the outset that the data model would be complex, since it had to deal with musicians and orchestras, composers and their works, broadcast schedules and, last but not least, musicians fees, both for the initial recordings, but also the additional payments made if a concert or parts thereof were re-broadcast.

So, the first thing we did was to teach the ex-planner and the project manger to read data structure diagrams and then we all stood in front of a large whiteboard for around a month until we'd developed a DSD that everybody agreed with and that nobody could find problems in.

We didn't do ANY technical design until this point was reached.

At this point we considered the users, who covered everybody from the music planners, who would use the system all day, every day to the program producers, would use it only every month or two when they were planning a new concert and needed to check that the performers and music they intended to use weren't already scheduled to be broadcast around the target date. This, and the terminals (24x80 green screen block mode devices) determined both the command syntax (7 single character commands, any data shown on screen could be shortened using personal abbreviations, command+abbreviation could be concatenated to run a set of related commands in sequence). We also introduced a permission system: any user could look at anything in the catalogs, or run clash checks on programs, but updating and/or data entry needed appropriate permissions.

Then, last but not least, we used a modular software design and, and delivered subsections, e.g the music and performer catalog creation and search tools the the music planners, ASAP, since maintaining this data was part of their job and concerts couldn't be planned without them. We also showed them how to use the fault logging system and encouraged them to use it as well as to call us if they hit problems. We delivered modules incrementally but in a sequence that allowed to planners to input music and performer detains, and then to enter broadcast details. The consequence of all this was that the way the system worked suited what the music planners needed and we got prompt feedback from them on anything that needed fixing or re-implementation.

The system was originally intended for around 6 - 10 users, but it turned out to be useful for rather more people that its original sponsors expected: last time I heard, it had nearer 40 users.

The main message to take away from this palaver is that, if you're designing an IT system that must support experts in any profession which is outside the development team's personal expertise, then YOU MUST INCLUDE AT LEAST ONE MEMBER OF THAT PROFESSION IN THE DESIGN TEAM for your project to be something that its users will find both easy and (hopefully) enjoyable to use.