Example of when freezing requirements went wrong?

Media999

Bit of a strange one this.

Im looking for an example of a major system that went wrong because requirements were not frozen and the client changed their mind.

Anything that was in the news would be ideal. Did the government mess anything up? I can settle for something that wasn't a particularly big story if thats all you know.

Maybe something like the voting system but i need more details on how a change of mind caused problems.

SalteeDog

Media999 wrote: »

Bit of a strange one this.

Im looking for an example of a major system that went wrong because requirements were not frozen and the client changed their mind.

Anything that was in the news would be ideal. Did the government mess anything up? I can settle for something that wasn't a particularly big story if thats all you know.

Maybe something like the voting system but i need more details on how a change of mind caused problems.

What do you mean by 'went wrong'? Over budget? Over schedule? Failed to launch? Failure to deliver expected benefits? All of the above?

Media999

Pretty much.

Imagine having to use an example that someone who doesnt understand software development could relate to.

Something like Ulsterbank but because of a change in requirements. If it even exists.

Even if that issue could be somehow blamed on a requirements change but from what i understand it was a corrupt patch so cant really reword that into this answer.

ChRoMe

Every single project ever.

I'm not joking.

SalteeDog

I don't have anything topical, local or particularily recent. I'm sure there are loads but most will not be public. Here's a textbook example:

Canada's gun registration system
In June 1997, Electronic Data Systems and U.K.-based SHL Systemhouse started work on a Canadian national firearm registration system. The original plan was for a modest IT project that would cost taxpayers only $2 million -- $119 million for implementation, offset by $117 million in licensing fees.
But then politics got in the way. Pressure from the gun lobby and other interest groups resulted in more than 1,000 change orders in just the first two years. The changes involved having to interface with the computer systems of more than 50 agencies, and since that integration wasn't part of the original contract, the government had to pay for all the extra work. By 2001, the costs had ballooned to $688 million, including $300 million for support.
But that wasn't the worst part. By 2001, the annual maintenance costs alone were running $75 million a year. A 2002 audit estimated that the program would wind up costing more than $1 billion by 2004 while generating revenue of only $140 million, giving rise to its nickname: "the billion-dollar boondoggle."
The registry is still in operation and still a political football. Both the Canadian Police Association and the Canadian Association of Chiefs of Police have spoken in favor of it, while opponents argue that the money would be better spent otherwise.

http://lessons-from-history.com/Presentations/Articles/CIO%20magazine%20-%20IT%20failures.pdf

SalteeDog

ChRoMe wrote: »

Every single project ever.

I'm not joking.

He's not. Requirements changes are a fact of life. It's how they are managed and how the success of the project is measured that determines the eventual outcome.

Media999

SalteeDog wrote: »

I don't have anything topical, local or particularily recent. I'm sure there are loads but most will not be public. Here's a textbook example:

Canada's gun registration system
In June 1997, Electronic Data Systems and U.K.-based SHL Systemhouse started work on a Canadian national firearm registration system. The original plan was for a modest IT project that would cost taxpayers only $2 million -- $119 million for implementation, offset by $117 million in licensing fees.
But then politics got in the way. Pressure from the gun lobby and other interest groups resulted in more than 1,000 change orders in just the first two years. The changes involved having to interface with the computer systems of more than 50 agencies, and since that integration wasn't part of the original contract, the government had to pay for all the extra work. By 2001, the costs had ballooned to $688 million, including $300 million for support.
But that wasn't the worst part. By 2001, the annual maintenance costs alone were running $75 million a year. A 2002 audit estimated that the program would wind up costing more than $1 billion by 2004 while generating revenue of only $140 million, giving rise to its nickname: "the billion-dollar boondoggle."
The registry is still in operation and still a political football. Both the Canadian Police Association and the Canadian Association of Chiefs of Police have spoken in favor of it, while opponents argue that the money would be better spent otherwise.

http://lessons-from-history.com/Presentations/Articles/CIO%20magazine%20-%20IT%20failures.pdf

Spot on.

Would be perfect if there was an Irish example that people could relate to. Surely our government has wasted money on some system that was obsolete before it was completed. Just hard to find one

SalteeDog wrote: »

He's not. Requirements changes are a fact of life. It's how they are managed and how the success of the project is measured that determines the eventual outcome.

Understood completely.

This is for a very long report. A nice epic fail that people could relate to would be good. Even if all projects evolve and change i have to follow the guidelines and give examples of both pros and cons of freezing requirements.

Not a great topic to write a report on. Gonna take me a while.

SalteeDog

Do some Googling for info on the Gardai's PULSE system. I recall that being well over-budget and schedule. Their fingerprint management system also appears to have been a problematic project.

SalteeDog

Here's another one: the HSE PPARS system. It was a big project with many flaws and I'm not sure if requirement churn was a major part of it but have a read of the Comptroller and Auditor General's report on it - it may prove useful to you.

EDIT> Just noticed the report states that "႒ An inability to definitively ‘freeze’ the business blueprint or business requirements at a particular
point in time in accordance with best practice. " was a contributing factor to the project failure.

Media999

Ill defo take a look at them. Nice one.

Edit.

That report is spot on. Tons of relevant info there. Nice one.

seamus

PPARS was the first thing I thought of. What should have been a pretty straightforward SAP HR & payroll implementation became a hundred million euro nightmare. I think the amount of scope creep in that would be enough to give analysts and developers nightmares.

They could have built a system from scratch for a fraction of the cost of modifying SAP to do what they wanted. Somewhat indicitave of the celtic tiger mentality that they paid €40m to Deloitte over the life of the project for nothing more than advice and support - no actual implementation or development.
That's not really within the realm of a failure to freeze, but it is one of the hidden costs that result from a failure to freeze requirements.

Media999

This quote from the report sums it up nicely

Since PPARS was being implemented as a single system in a non-standardised operating environment within legally autonomous agencies each with significantly different organisational structures, cultures and processes, the project was faced with changes to requirements as each new agency implementation progressed. This made the project particularly complex with the result that the technical configuration and subsequent testing required was greater than had been anticipated.

Rest of the report takes the same approach. Perfect example to use.

http://audgen.gov.ie/viewdoc.asp?DocID=888&UserLang=EN

seamus

Just an extra note I thought of, and perhaps not within the scope (:D) of what you're talking about, but in my experience of many many creeping projects, a large chunk of scope creep comes from the client's unwillingness to change their process, or perhaps a failure to understand that improvement requires change.

In many cases when you're planning a major project, for some reason the client (and/or the end user) wants the new system to look and feel exactly like the old one. They want you to change the system, without them having to change their business processes.

The two are fundamentally incompatible and you end up modifying and in many cases completely crippling a superior system in order to make it work just like the old clunky one used to.

This I understand was the heart of the problem with PPARS - none of the agencies were willing to alter their processes to accommodate the new system, so the system was altered to accommodate them. And of course they all had their own ways of going about each process.

In order to avoid creep, you need to nip it in the bud early and ask them why they want a new system if they don't want the processes to change.

SalteeDog

That's been my experience too. In terms of business transformation, typically the IT system is only one part of the solution. It needs to be accompanied by real process change and that usually means organisational change too. In that context it's obvious why public sector projects (which may impact a highly unionised workforce) often face deeper challenges than would be encountered in the private sector - although the private sector is certainly not immune to organisational interia either.

djk1000

ChRoMe wrote: »

Every single project ever.

I'm not joking.

This.

PPARS in the HSE and the Garda Pulse system as two examples. I don't think e-voting would fit as it wasn't really a scope creep issue.

Earthhorse

ChRoMe wrote: »

Every single project ever.

I'm not joking.

djk1000 wrote: »

This.

...

djk1000 wrote: »

I don't think e-voting would fit as it wasn't really a scope creep issue.

So not this, then.

Sparks

Have you looked through the usual sources for examples? Comp.risks, or even a basic google search?

tricky D

Vague and unreliable recollection of the first ROS system around 2000 being Java based and the requirement for accessibility was called for late in the dev when it should have been there from the start. This was simply incompatible with what had been developed so a carpet and brush were used.

fergalr

Media999 wrote: »

Bit of a strange one this.

Im looking for an example of a major system that went wrong because requirements were not frozen and the client changed their mind.

Anything that was in the news would be ideal. Did the government mess anything up? I can settle for something that wasn't a particularly big story if thats all you know.

Maybe something like the voting system but i need more details on how a change of mind caused problems.

This thread is an april fools joke, right?

Media999

fergalr wrote: »

This thread is an april fools joke, right?

Not at all Fergal. Why so?

fergalr

Media999 wrote: »

Not at all Fergal. Why so?

Ah - I thought it was a gag for 1st of April - ask on the Software Development program if anyone knew of any examples when requirements changed.

Because, as Chrome says above, its very common.


Pretty much the entire literature of software engineering is filled with examples, of projects going from bad, to worse, to astoundingly bad, to sort-of 'whoops the planets have crashed into each other' type-of-scenarios.

Just look up software engineering case studies; its pretty hard to find examples of large projects where everything didn't go wrong; and thats generally after things have been retroactively made look more expected than they actually were.

Edit:
It'd be interesting to have a study, if one doesn't exist (I dont know the literature) that was a compilation of large Irish software engineering projects; I'd go to a 'lessons learned' talk on that.
I'm sure that sending an e-mail to these people could be fruitful, I'm sure they've collected examples like this when they were applying for government funding etc: http://www.lero.ie/

xxyyzz

Changing requirements is a fact of life unfortunately. In new systems in particular I find that users generally only have a vague notion of what they want until you put something concrete in front of them. The waterfall model was grand in theory until you added users.

DublinWriter

OP - it's crucial to differentiate between project failure due to:

(a) changing requirements subsequent to go-live
(b) requirements not being initially understood
(c) requirements being initially over-ambitious

Most project failures I see are due to (b) and (c) in conjunction with poor project governance (i.e. nobody owning the project and no project champions from the business side). P-Pars is a good example of this.

As far as I know, PULSE didn't fail as a project, it just had initial budget overrun and IR issues with some unions.

Rarely these days do you see a complete failure due to subsequent requirement changes. An example of this happening would be Megacorp A developing a ERP system, then close to going live they decide to take-over Megacorp B.

ChRoMe

Cant believe I didnt link to this earlier