Re: Yet another goverment IT fiasco -- roll on ID cards!


Harry The Horse wrote:
Stephen Horgan wrote:
Harry the Horse wrote:
"MM" <kylix_is@xxxxxxxxxxx> wrote in message
news:jjhd725q0d3qocuf4sc0drtac6etku19fm@xxxxxxxxxx

But I built databases for years, having pragmatically found a basic,
simple design that worked. There is no need to keep reinventing the
wheel, not even in software. I think part of the problem is that too
many people just love gimmicks. They can piss about for ages with
fancy popup windows, voice input, touch screens etc. But in terms of
moving data from A to B, we could still be using DOS in most cases.
The IT cockups happen, because IT people are never politicans, but
instead are the archetypal backroom bods who don't want anything to
do with management. But along come the "polticians" in the company
or organisation and *demand* that changes be made. The IT guys then
just roll over.

In my experience the root of cause of IT project disasters is
rarely, if ever, technical. It always starts with a lack of clarity
of objectives and that translates into an ill-defined scope and you
are off to a crippled start. If you have politicians meddling then
the programme ends up with no baseline control, as the minister is
announcing new initiatives which translate into new requirements.
And so the circle of pain continues. With no clear 'business
owner', there is no one who can actually say, 'no, that waits for
phase 12; these are the key requirements that must be delivered in
phases 1 - 3'. ID cards project will be just this kind of fiasco,
as there are several government departments that have a key interest
in it, and there will be a battle for ownership of the project.

Technical issues are often central to IT project failure, not at a
programming level, but at an architectural level. Modern large-scale
IT systems are very complex and the expertise to build software
components does not necessarily extrapolate to an overall design.
Government IT systems often appear to be very poorly built, and they
are very expensive by commercial standards. While requirements
management is very important it isn't always the root of all evil.

I disagree. I have been at the 'mopping up' stage of three big IT
programmes that have gone awry and the fundamental problem was always the
lack of control on requirements. That often leads to poor technical
decisions being made. Had the proper control been in place the risk of poor
technical judgments being made would have been far less.

There is a view, largely propagated by the large consultancy companies,
that technical matters are very secondary to matters of project control
and requirements. They do this because they are usually selling their
services to people who know next to nothing about modern IT at any
level of detail, but who can be made to understand about project
management concepts. Also, they often aren't very good at IT
architecture but when that becomes apparent they have usually got the
contract and the project is well underway. When you are dealing with
large bespoke systems in new business areas, and especially where said
systems are to obtain a competitive advantage, then assuming that
getting the requirements right equates to project success is very
dangerous. A good example in the public domain is the nascent ID cards
system, a system unlike any other in existence and where the technical
design of the database and biometric functions is absolutely central to
its success or failure. You can get the requirements spot on but if
either of those is not properly architected then there will be a
debacle regardless.

If you are dealing with yet another system of a kind that is well
understood, which has been built before, and where the appropriate
skills are available then requirements can be the main focus. For
anything else architecture and questions like 'will it work' are also
hugely important.

.

Relevant Pages

  • Re: BCE Vs MVC
    ... >Can we say that Boundary, Control, Entity classes are the analysis ... >phase equivalent of the MVC architecture in implementation? ... > Boundary, Control and Entity classes. ... > categorizations for moving from use case narrative to actual design. ...
    (comp.object)
  • Re: how design a electrnic switch for ac line(AC220V-50HZ-I<10A)
    ... >> mosfet to built it, ... >> reverse direction,so it can not control ac source. ... how can I to design ...
    (sci.electronics.design)
  • English eBooks Engineering
    ... Adaptive Voltage Control in Power Systems Fusco, ... Advanced Design Techniques for RF Power Amplifiers Krizhanovski, ... Advanced Fuzzy Logic Technologies in Industrial Applications Bai, ... Bioinformatics Using Computational Intelligence Paradigms Jain, ...
    (sci.med.nutrition)
  • =?UTF-8?B?2YHYsdmI2LQg2YXYrNmF2YjYudmHINqp2KfZhdmEINqp2KrYp9io2YfYp9uMINmF2YfZhg==?= =?UTF-8
    ... PTData for Windows Post-Tensioning Design and Analysis Programs ... Construction Business Management A Guide to Contracting for Business ... The Classical Orders of Architecture, Second Edition,[By Robert ... Brownie],Copyright © en US DEPT OF THE INTERIOR ISBN b000q5zftk.pdf ...
    (sci.math.num-analysis)
  • Re: Access 2010 Web Form - tab order
    ... and the fact that we have control layouts to move controls together as a group are actually two distinct issues. ... I think for existing applications and most things I have, I do prefer simple design mode, but some of these new features can really help and terms of productivity. ... They could've perhaps built something that took an existing access form and then had some some type of special ActiveX or client program you install on your browser that renders that form. ... Keep in mind if the form you specify in the browse two command does not have to be part of the current navigation control set. ...
    (comp.databases.ms-access)