June 10, 2008 at 7:23 am
Never a good situation to be in, too often the case. This specifically refers to Penny's comment, but applies above also.
<><
Livin' down on the cube farm. Left, left, then a right.
June 10, 2008 at 7:28 am
In my experience the biggest reason for software project failures has been a lack of "buy-in" by the people who will be using the software and lack of true support from management. First, if the end-user does not see a benefit they won't use it. I was involved in writing a warehouse management system and the key user would not assist and said he would not use it, he'd rather track it in Excel and have to spend a couple of hours a day physically counting his inventory and management did not push him to it. Secondly, I have worked on several projects where management has said we need software to manage our production, then when we asked for resources (people mainly) from production to help us understand and define processes we could get no one. Then when we got the projects "done" we would end up re-writing most of it as it did not meet the needs of the end-user.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
June 10, 2008 at 7:33 am
Jack makes a great point. Often the person that pushes the project through or gets it approved doesn't use the system. They "think" that people need something new, and if the user's don't feel that way, the project doesn't get built well.
Project management is crucial, but there are things that are out of your control, like a time window of opportunity for something. If you can't get it done, it could also fail.
A big part of project management is also evaluating the project correctly and knowing when it might be doomed and when you might need to recommend it be stopped.
June 10, 2008 at 7:50 am
What I have seen in numerus occasions, is that it is more of a financial decision to keep a project going even when it's over budget and way behind. More of an amoritization issue. Once the project ends ( and un-sucessfull ) the company has to take the hit right then. Where as a completed project can be amortized for a number of years. I saw a large SAP install that someone had the guts to pull the plug on, but when they took the hit the stock plummeted and a competitor swept in and bought them up.
June 10, 2008 at 8:10 am
[sarcasm]Wow a failed SAP implementation, I've never heard of that before![/sarcasm]
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
June 10, 2008 at 9:33 am
I've actually had arguments with managers over the idea of killing a project part-way through. I thought the business case for the projects had been proven untenable, based on differences in initial assessment and actual review, and wanted to can it. The manager was in the "we've already spent so much on it we need to justify the cost" camp and wanted it continued, despite continued expense with no discernable return on investment.
I see it as throwing good money after bad. That manager saw it as justifying what had already been spent. I was overruled, the project was finished, and drove the company into bankruptcy about a month later.
So, I'm not keen on continuing a project just for the sake of continuing it or for the sake of not making some manager look like he misjudged it at inception. Kill the project once it is clear it won't be worth it.
On the other hand, it's also easy to throw your hands in the air, say, "there's no way this is worth it" and kill a project that really should be finished. There's always judgement involved in the thing. If there's any chance at all it will be worth it, or if the loss can be soaked on a good chance it will be worth it, I wouldn't quit the project.
Nobody's predictions are perfect.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 10, 2008 at 9:45 am
GSquared (6/10/2008)
On the other hand, it's also easy to throw your hands in the air, say, "there's no way this is worth it" and kill a project that really should be finished. There's always judgement involved in the thing. If there's any chance at all it will be worth it, or if the loss can be soaked on a good chance it will be worth it, I wouldn't quit the project.
In business terms, what you are talking about is called "calculated risk". IT people usually are asked questions that determine the amount of risk. But the business decision is usually made by someone else. That is why the finger of blame usually rests on the business side. In the end, they were the ones that took/did not take the advice of IT. The IT people then get to sit back and state their woulda-coulda-shoulda's.
In the end, a strong business and IT team that have a common goal works the best.
Mia
I have come to the conclusion that the top man has one principle responsibility: to provide an atmosphere in which creative mavericks can do useful work.
-- David M. Ogilvy
June 10, 2008 at 10:04 am
This is by far one of my favorite subjects. I once worked at a huge IT company that will remain nameless (EDS). The failed project went for seven years and 45M before the plug was pulled. In a nutshell, I blame the management team's poor sales effort, not the project.
Now that I am a manager and can pull plugs, I describe my feelings on this subject like this: Remember when the Hubble telescope was first launched, how it couldn't focus, and they had to send up a repair mission later to fix it? If I were the project manager on that project, I don't know if I could have done it better than he or she did, but for god's sake, I wouldn't have launched the damn thing into space!
June 10, 2008 at 11:11 am
Mia: Yep. Calculated risk (actually, I first learned that concept in game theory and military studies, but it most certainly applies to businesses as well). The trick is calculating it correctly, and not letting ego get in the way of good decisions.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 10, 2008 at 11:13 am
Steve, in response to your comment about the US being very risk-averse, my experience has been that Asia takes the cake for being so risk-averse that they will not pull the plug on a project that is not only failing, but has already failed.
I consulted on a huge project in Hong Kong over a two year period. The project was a loss-leader for a Fortune 10 (ten) IT company. The client was a major national bank.
After one year, the project had already gone so far beyond budget and time that completing it was not feasible. The consulting company tried to pull the plug, but the client wouldn't back away.
After two years, the project became an unofficial black hole for money and resources.
I don't know what happened to the project since then, but the client's profound insistence that the project be completed at any cost has stuck with me.
---------------------------
|Ted Pin >>
June 10, 2008 at 11:29 am
GSquared (6/10/2008)
Mia: Yep. Calculated risk (actually, I first learned that concept in game theory and military studies, but it most certainly applies to businesses as well). The trick is calculating it correctly, and not letting ego get in the way of good decisions.
I completely agree. There have been many people that have allowed business to mix with their personal feelings. This is where the biggest mistakes have been made (in a business sense). How many times has someone worked overtime to get something done because they "promised" they would? Your personal word is on the line. If you are a salesperson or an upper manager - how far would you go to make other people work overtime because you gave a client your word?
However, the drive for a good business should be a personal obsession - the more of yourself that you put into a business, the more you have to lose, the greater you want to make it. There is a tightrope walk there. Sometimes the visionaries need to let cooler heads prevail when the project fails.
Mia
I have come to the conclusion that the top man has one principle responsibility: to provide an atmosphere in which creative mavericks can do useful work.
-- David M. Ogilvy
June 10, 2008 at 1:50 pm
I totally agree with the "buy in" comment and would go further and say that the end user has to be actively involved with the project.
Bringing developers and end-users together results in meeting of minds. I've lost count of the number of times and end-user has said "its a shame that the product can't do this" and I've thought "but thats trivial, why do they think its difficult"? The answer is that the lines of communication are too long and the requirements have been filtered/corrupted by 'n' layers of business bureaucracy.
June 11, 2008 at 2:30 am
Failure is the pillar of success.......
You can learn something from them.
June 11, 2008 at 6:16 am
I have worked on three projects where the plug was pulled. One was for an insurance product for a Norwegian insurance company, another was for an automated loan approval system.
But the most unique method of pulling the plug was the Electronic Health Record project. On a Friday, the president of the other division telephoned the developers, managers, and CEO of the EHR project. One of the developers asked the president why he wasn't down here in person. The president said that he was recovering in the hospital from a broken back from a skiing accident. The next Monday, the president was at the office taking charge of the company.
That was a remarkable recovery. Oh wait, jellyfish don't have spines!
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply