I once worked for a company where most of the programmers thought like you do. I left. It took a while but they finally went out of business. If the customer isn't satisfied, the project is a failure. Period. If you think doing your best is good enough, thing again. You may not have control over why the project failed, but it is still a failure. And if you want to keep getting paid, you better figure out how to make it a success.

A realy good motivational post and must read for the IT people of lower ranked who often faced this kind of situation. Most of the time if projects failed then failure imposed on them and in case of success, credit is given to the people who designed that project.

So I realy thankful to the author for writing such a motivational article.

I am an manager-becoming-developer, and I think that the goal of a commercial project should never be the fun of the developer writing code. I feel it's very important that the developers in my team feel good about the work they are doing, that they think the technologies we're using are cool and that they have freedom to build "art" code. But this is not the goal of the project. The project wouldn't be here without the customer and his requirements which leads to customer's money. He, and only he can say if the project is a success or not. Just as he and only he can say if the software project works correctly or not. IT will always deliver to some kind of business, so what is the point delivering something the business won't use ?

I think the keys in all the described projects was understanding customer requirements and management decisions. Both of them poorly done. Sorry to say, but the way I see it - some of your projects failed. Don't worry, some of mine too .

Any software development project - any project in fact - is a team process. The whole team owns it and the whole team succeeds or fails together. If there is inadequate information avaiable, then that is a problem for the team to solve. If a team member is not contributing adequately for any reason, then that is a problem for the team to solve. It's not anybody else's responsibility. The decision on whether it is a failure should be based on success criteria set out at inception and agreed with the ultimate users. In the real world, that often does not happen, but user satisfaction (including functionality, time and cost) has to be the only criterion.

The scenarios described suggest to me a horribly hierarchical organisation where each individual throws their bit over the wall to the next in the chain. 'Ive done my bit - the rest aint my responsibility'. Guaranteed recipe for failure according to any criteria!

I have to agree with Stewart. It is a very poor team that contains individuals with an attitude that isolates them from the success of the team as a whole.

Sadly IT tends to attract more introverted individuals who are just happy to sit in a corner and code. No problem with that at all (we need focused coders, of course) but when it comes to making a decision on whether a project has been a success there is so much more to it than in an individual perception. We are a service industry and if we are not providing a satisfactory service to our clients as a whole then we have all failed.

A project can fail even if the entire development team are well-motivated geniuses with all the resources they require. A single developer can certainly be extra-ordinarily succesful and yet participate in a project that will be deemed a failure.

When I was a young developer I soon came to realise that I couldn't let my view of my self-worth be determined by the end result of a process that I was just one small part of; I had to concentrate on doing my part of the job well, and helping my colleagues where I could.

I think the author should be very careful to distinguish between personally being successful and having a successful project. I believe the author is trying to remind us of that distinction and remind us developers that they can be proud of the work they have performed even if the project failed by any objective criteria.

But that's not quite the end of the story ...

As one is given more and more responsibility for the management of a project one becomes more and more responsible for the project's success. If one wants to take on that responsibility, they need to recognise a project failure when they see it and call it what it is. If you don't distinguish between successful projects and failed projects one can't lead their team to create more successes than failures.

As many others have posted, the success of the project is best determined by whether all parties involved (purchaser, end-users, purchaser's upper management, producers upper management, the developers, the producer's accounts department) left happy with the project.