December 21, 2005 at 9:37 am
I try to look at things like this:
1) everything breaks otherwise how would you know if it was working
2) there is always something better bigger faster tomorrow
3) you can never think of everything
4) all one can do is your best with the tools at hand and the time permitting, if you get more of either or both other options are possible
December 21, 2005 at 3:18 pm
Sam, I'm with you on this but I would say there is one over-riding cause of all project failures and that is a break-down in communication.
It doesn't matter if it is and analyst failing to extort the user requirements or the users failing to articulate their requirements. It could be management failing to consult juniors or juniors failing to warn management. At some point the communication chain breaks.
If I think back to the killer apps or applets that I have seen in 20 years in the IT industry they are all very simple in concept and execution though probably not in the execution.
1. PKZIP
2. GREP
3. Intellisense
4. REGEX
I know of someone who says that all you get for $60K of software is $60K worth of bugs!
August 19, 2013 at 6:00 pm
Yes. It's because of unrealistic project plan and communication gap between development team and business end users 🙁
August 20, 2013 at 12:53 pm
Have You Ever Failed In A Software Project?
Of course I have. More than once. Anyone who has spent more than 40 years in developing software and systems will have failed in at least one project unless they have never done anything at all hard.
The failure that annoyed me most was a project that I was stuck with running despite wanting to have nothing to do with it. It was a pet project of the founder and CEO of the company, and had no support at all from the divisional management of the unit that should have been responsible for it. I had looked at the proposal briefly as chief designer in a different division and then attended a meeting on it at which I had suggested that the requirement was unclear, that the estimated effort was a factor of 3 or more too low to do it even if the requirement had been properly understood, and no consideration at all had been given to providing a user interface. That apparently went down well, because next thing I knew the CEO was asking me to take on the technical lead / chief architect job for the project; I said no. The CEO then talked the divisional director to whom I reported, who had already refused to be responsible for managing the project, into taking on technical lead job as well as continuing with his other responsibilities. Next thing I knew I was being asked to take on project management of the thing. I said no, because it wouldn't deliver without resources. The CEO then said he would get me a team of GUI experts to handle that side of it, provide me with domain experts seconded from the appropriate division to handle the main stuff, give me the designer whose idea the thing originally had been full time, I could use several people from my own division, and the required OODBMS would be provided by another division. That didn't really leave me much option - my divisional director was in no position to back me on recommending not going ahead now that he had been persuaded to take on the chief architect function for the project. The project got nowhere, for several reasons: the domain experts were available only sporadically, because they were needed to develop new releases of the products that were making money. The expensive team of GUI experts turned out to believe in a complex multi-layer architecture to be implemented in Java, which stood no chance of running faster than a crippled pig. A project manager in that company was part of a troika consisting of a product manager, a marketing manager, and himself, and without a proper requirement specification it was impossible to get agreement on a functional description; the proposals originator was supposed to be designing the critical component that would make the product interesting, but had no idea how to go about it; and the object oriented database was a bit of a disaster because the domain experts who had claimed to need one were horrified by my bizarre idea that objects should have methods. We put together some demos for trade shows, but I made sure it was always understood that these were preliminary demos and that product was still well in the future. Perhaps the biggest problem of all was the lack of specification of what we were doing; the marketing guy repeatedly recited the mantra that the end users must see no complexity - plainly nonsense, as the end user had to specify what he wanted, and that could be very complex - and this prevented any clear definition of the critical component being reached; the product manager regularly cam up with a nice new wibni, and the marketing manager usually backed him. So this project was spending resource and achieving little or nothing. Another division also had a project that was going nowhere, and was bleeding resource as if it was going out of fashion while refusing to eliminate features that would have no commercial value and would ensure that delivery would be delayed by far more than could be afforded. Eventually the negative cash flow meant the company could not prevent itself from being bought by a competitor and most of its projects discontinued: some intellectual property was handed over to employees so they could try to set their own enterprises up to continue the work if they chose to; some products were handed over into the public domain; some projects continued in the buyer company; and some projects, including mine, disappeared altogether.
I should have walked out and found a new job rather than staying on and accepting management of that project. Or perhaps taken it on be refused to allow it to be staffed until the troika plus the technical lead (all people who had other responsibilities) had signed of on a requirement specification and a functional description - that might have been worth a try, although I think the CEO would have insisted in starting before we knew what we were doing so it wouldn't have worked. But here I was accepting a can of worms with no clearly defined requirement and a commitment to deliver whatever it was within 2 years; taking that on was maybe the stupidest thing I ever did. Continuing to try to take it somewhere useful while unable to resolve project definition and without access to the domain experts required to make sense of the thing, instead of blowing the whistle and declaring the project failed at a far earlier stage was the maybe my second biggest mistake. Before then I had I had rescued projects that were in deep trouble before then by cutting hard on commitments and pushing even harder on having properly understood objectives; I had canned projects that couldn't achieve clear definition, and persuaded people to scrap projects that had overrun the timescale during which the end product would be useful before I was involved in them. I still don't know how or why on this occasion I did something I had learned long before was utterly the wrong thing to do.
Tom
Viewing 4 posts - 31 through 33 (of 33 total)
You must be logged in to reply to this topic. Login to reply