...If I was a non-US large organisation such as the NHS, I would think twice about continuing to invest into MS products and would start very quickly to consider alternatives (such as the French police that went with Linux). There are also national security issues for a non-US country to have such a total reliance on the product of a single US corporation:
Europe's reliance on Microsoft has governments under a worrying digital 'killswitch'
____________________________
-dr_andus
That's evidently a valid point - or at least, the French police would have presumably thought so, anyway. How did that Linux thing work out for the French police, by the way? Was that project completed on time and budget, having delivered to its objectives, or was it sabotaged from within and turned into an expensive trainwreck? (I have no idea, but it might be interesting to find out.)
Whenever I read of some strategic IT project that breaks "new" territory - a potential trainwreck - it reminds me of a New Zealand project that did notoriously become an expensive trainwreck. It was the NZ police INCIS project in New Zealand, in the early '90s. I saw it happen, and it was like watching a trainwreck in slow-motion, and one knew that it was wrecking and that the taxpayers were going to have to foot the bill (cost overruns).
What happened was that the NZ Police put out a tender for project INCIS (Integrated National Crime Information System) as their IT platform to deliver IT services for the '90's and beyond.
A lot of their existing technology at the time was delivering services to online terminals from IBM and/or Univac mainframes hosted in a high-security data centre in Wanganui (New Zealand) by GCS Ltd. (Government Computing Services), which was the first of the SOEs (State-Owned Enterprises) to be privatised by the NZ Government and put up for sale (EDS Corp. eventually bought GCS Ltd.).
There were 2 major competitors for the INCIS tender - IBM and Microsoft. GCS also could have easily done the business, but, as the incumbent supplier, their bid was largely unwanted/rejected. The tender was won by IBM, whose response to the tender (as I vaguely recall) had proposed the general approach of a fairly conventional distributed 3-tier client-server architecture based on IBM OS/2 (Surprise!), with maybe some IBM mainframes/minis acting as central or distributed local servers for some services. I thought it was a pretty solid and feasible proposal, though it required detailed planning. At the time, OS/2 was recognised as being a stable OS that was technically way ahead of and out-performed the then current Windows OS in almost all benchmarks.
Then the fun began.
For some inexplicable reason, an ICIS project manager was appointed who apparently favoured Microsoft and was apparently openly critical of the IBM contract and the OS/2 technological direction and approach, or something. An antithetical schism rapidly formed within the project team(s), between the OS/2 camp and the Windows camp, and it was all downhill from thereon, and the project eventually (inevitably) failed.
A
LOT of obvious conventional risks and lessons were re-learned from that project failure (see the links below). One of the main ones - straight out of Project Management 101 Risk Management - is
the risk of staffing-up with inexperienced resources. The PSC (Project Steering Committee) needs to monitor and avoid the risk of staffing the project with human resources (people) who are not experienced in/with, or capable with, or who may be hostile to, the IT technology they will be
required to use to implement the project according to the project technology implementation plan.
I have personally been put in a similar position, where I was assigned to recover a failed strategic $multi-million project which had run foul of
exactly that risk -
the risk of staffing-up with inexperienced resources - some of whom were openly hostile to the technology they were required to implement. The technology was not what was "conventionally acceptable" to the bulk of the IT project personnel assigned to the project.
I knew nothing about the technology, but I agreed to undertake the role, but
only on condition that I was allowed to cast a new budget and plan, and that I was fully authorised to replace those personnel in the project team of 10 people whom I felt it was necessary to replace. I replaced 8 of them within about two weeks, and the project ran smoothly and was recovered on-time and on-budget, exceeding its delivery objectives - all enabled because I had a superb project team that knew what it was doing and pulled together collaboratively all the way.
The rule is: If you are going to undertake an important and potentially costly strategic IT project, using a new or potentially controversial technology, then prepare for war. Provide the project with all the resources necessary to support it and to enable it to deliver and survive and protect itself for the duration of the project, in what will probably inevitably be an almost palpably hostile political environment - an environment that may ensue, where landmines, grenades, torpedoes, homing missiles, flack and nay-saying could well be the order of the day for months on end.
And stick to a regularly-reviewed plan.For all the above reasons, and though I could be wrong, of course, I would suggest that the UK NHS IT opportunities could very much belong to the Microsoft monopoly already and that it could thus cost potentially too much in terms of $money and political aggro to pull away and be put on a war footing by going down the Linux (or other) technology path, no matter how good that technology path may be.
Refer:
