February 27, 2019 at 9:59 pm
Comments posted to this topic are about the item Pulling the Plug
February 28, 2019 at 1:04 am
I think you are referring to the sunk cost fallacy.
Concorde is an emotive subject, a magnificent achievement and in many ways a victim of circumstances. The oil crisis of the 70s, the British inability to sell, political chicanery. In later years it was profitable though if you look at it in LTV terms it probably wasn't.
But the value of Concorde was far more than can be expressed by the short-arms-long-pockets brigade.
For those who visit Cambridge, UK take a trip to Duxford aerospace museum and see the Concorde prototype. Notice the old guys manning the display, get talking to them. They are immensely proud of that aircraft. The ideas that built Concorde came from the Avro Arrow (cocked up by the politicians and still a sore point in Canada), TSR2 (cocked up by the politicians). When Concorde was decommissioned tens of thousands turned out to see its final flight, many of them in tears. Competition for a place on the engineering team decommissioning it was fierce. What price would you put on that?
What great jump forward in aviation tech superseded a machine that could cross the Atlantic in 2 hours 53 minutes?
I've decommissioned many IT systems and the predominant emotion has been "thank God that <<expletive deleted>> has gone"! The best of them has gone unmourned even when the rightness of the underpinning idea has been acknowledged.
February 28, 2019 at 4:40 am
Isn't this the purpose of pre-defined success/failure requirements? This project shall be deemed a success when these criteria are met and a failure when these requirements are met.
To be fair, I've never been on a project that has actually had failure requirements and I have been on projects that have run over budget or gone over time etc.
When a project is important enough, and most seem to be when they are started, then the idea of failure is at the back of one's mind, although failing to plan is planning to fail.
There is also the Macintosh idea — nobody remembers a poor product and nobody forgets a late product. it doesn't really matter how usable the product is, release it when promised and improve it with each iteration. Although it was released early in 1984, it didn't really become useful until the advent of the Mac Plus in 1986. The 2 previous versions were essentially beta-versions. Indeed, one could hurl that accusation at Microsoft for a few of their features.
February 28, 2019 at 5:26 am
When someone says something so profound you wish you'd heard it decades ago!
February 28, 2019 at 6:11 am
Possible that here in Ireland the "Concorde Fallacy" will be known in future as the "National Children's Hospital Fiasco". It really is remarkable how often and the extent to which people are willing to pour good money after bad. https://en.wikipedia.org/wiki/New_children%27s_hospital
Like Concorde this is politicians spending other peoples' money. Could be a lesson in that.
February 28, 2019 at 6:44 am
Mr Celko often quotes Turkish(?) proverb, 'no matter how far you've gone down the wrong path, turn back.'
It's one thing on which I completely agree with him. The time and effort that has been expended on a bad idea will never be recovered and the idea will still be bad when it's finished. Sometimes it's better to just cut your losses, admit you were wrong and start again. Yes you may look bad but you'll almost certainly look worse if you stick to your original plan.
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
February 28, 2019 at 7:39 am
Neil Burton - Thursday, February 28, 2019 6:44 AMMr Celko often quotes Turkish(?) proverb, 'no matter how far you've gone down the wrong path, turn back.'It's one thing on which I completely agree with him. The time and effort that has been expended on a bad idea will never be recovered and the idea will still be bad when it's finished. Sometimes it's better to just cut your losses, admit you were wrong and start again. Yes you may look bad but you'll almost certainly look worse if you stick to your original plan.
It's easy for one or two people to pull the plug on a project with no hope of ROI (ie: a rental property). The problem when dealing with corporate multi-million dollar projects is that there are a lot of executives and stakeholders who's consensus are required to make that decision and a lot of employees with a vested interest in keeping it funded.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 28, 2019 at 7:47 am
One of the contributing factors that fuels the fallacy of sunk costs is the way business is run. Everyone is so concerned in quarterly profit and stock prices that change hourly that they lose sight of long-term goals. Sometimes when a project is started, the scope is simple but it creeps into something much larger and exceeds the capability of the original design. Starting over from scratch at that point should not be discounted because the ideas generated in the first plan sprouted new ones. That's the definition of research and development.
February 28, 2019 at 9:02 am
David.Poole - Thursday, February 28, 2019 1:04 AMBut the value of Concorde was far more than can be expressed by the short-arms-long-pockets brigade.
For those who visit Cambridge, UK take a trip to Duxford aerospace museum and see the Concorde prototype. Notice the old guys manning the display, get talking to them. They are immensely proud of that aircraft.
I'll try to go by there sometime. I walked through a Concorde in Seattle.Not a big plane, and glad that it would be a short flight, but I wish I'd had the chance to fly one.
February 28, 2019 at 9:05 am
Sean Redmond - Thursday, February 28, 2019 4:40 AMIsn't this the purpose of pre-defined success/failure requirements? This project shall be deemed a success when these criteria are met and a failure when these requirements are met.To be fair, I've never been on a project that has actually had failure requirements and I have been on projects that have run over budget or gone over time etc.
The hard part here is that you can't always decide what a failure is at the beginning.It's entirely possible that the market changes or your business changes, or a new product supercedes what you were doing. There are changes that make you re-evaluate later and you might decide to stop working on something.
It's a battle to dispassionately evlaute a project that's late and not working and ignore the costs. However, the costs spent are gone. You have to decide if future costs are better spent on this project or something else.
February 28, 2019 at 9:07 am
Eric M Russell - Thursday, February 28, 2019 7:39 AMIt's easy for one or two people to pull the plug on a project with no hope of ROI (ie: a rental property). The problem when dealing with corporate multi-million dollar projects is that there are a lot of executives and stakeholders who's consensus are required to make that decision and a lot of employees with a vested interest in keeping it funded.
The vested interest (bonus, accolades,etc) are always a problem. Too many people don't pull together for the best interests of any org.
It's the frailty of being human
February 28, 2019 at 9:44 am
If I could, I'd give this article a billion likes. The overwhelming majority of apps that we have here are very old apps. Some using old technologies no one knows, but we keep them around. We even keep them going when it becomes increasingly expensive to do so. And sometimes users get tired of waiting for something that's being developed for them, so they move ahead and, by hook or by crook, find some other solution. This isn't always due to an inordinate allegiance to an old system; sometimes its just because following a very lengthy Waterfall approach to project management takes longer than the users can wait for. I do see positive movement towards adopting a more Agile approach to project management, but these things take time.
Kindest Regards, Rod Connect with me on LinkedIn.
February 28, 2019 at 9:47 am
When I was in college a teacher said "if your IT project doesn't have executive buy-in, its not going to make it to market/production". Over the years I've learned this is just so very true. Its not usually the IT managers that pull the plug, its the executives outside IT that do.
Years later I worked at company where all the senior developers, senior DBAs and senior project managers were assigned a huge database project. They worked on the requirements analysis, back-end details, etc for a year, then started in on the development. At the end of that second year the whole project got cancelled and all of them got laid off ... all the senior people ... laid off.
The problem was they assigned themselves this huge project. They dreamed up this huge grandiose system, got a budget from an executive who left the company shortly thereafter, but then they never got any buy-in from any other executives. Two years and probably a million $$s into the project none of the other executives knew anything about it, didn't know what it was for, and when they looked into it, didn't see the value in it. So they just cancelled the whole thing and laid everyone off. Poof ... gone !!
By that time all the other development work was being shipped overseas anyway (to Romania). So the company probably saved a million $$s that year by getting rid of all those senior people.
Executives don't have any issues cancelling a project they don't see the value in.
February 6, 2020 at 9:12 am
When I was in college a teacher said "if your IT project doesn't have executive buy-in, its not going to make it to market/production". Over the years I've learned this is just so very true. Its not usually the IT managers that pull the plug, its the executives outside IT that do.
The problem was they assigned <u>themselves </u>this huge project. They dreamed up this huge grandiose system, got a budget from an executive who left the company shortly thereafter, but then they never got any buy-in from any other executives. Two years and probably a million $$s into the project none of the other executives knew anything about it, didn't know what it was for, and when they looked into it, didn't see the value in it. So they just cancelled the whole thing and laid everyone off. Poof ... gone !!
Your teacher was absolutely right! For Data Warehouse projects not having a business sponsor is one of the biggest indicators that the project will fail.
Also, left to their own devices CTOs and architects have a tendency to design for scale that doesn't exist in the market using technologies they don't need (or know) needing techniques that few understand and requiring training no one is prepared to pay for.
A friend once joked that we didn't need software archeology, we software geology so that when we dug down through the strata of the systems stack we would come to the layer of ash that was the project no participant wanted to talk about.
February 6, 2020 at 3:47 pm
Working in a government organization, I have seen many times that either staff has spent hundreds of hours developing a piece of software or they have bought software and somewhere along the line someone did not ask the right questions and the software cannot be used as expected and thus 'thrown in the trash'. The classic case is that we had bought some voice recognition software for our clinics to transcribe their notes directly into a computer. But we found out late in the project that the 'finished' notes would integrate into the clinic software (for appointments, billing, etc.).
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply