Dear oh dear oh dear.... what a total cop out from the author. If the eventual users don't or can't use the system, it's a failure, no matter how good the program writing is.
If the eventual result is vastly different from that desired at the start of the exercise, it's a failure.
What we saw in the author's 'not me gov, I wasn't responsible- Ive done exactly what you asked me to do ' rant was the classic conflict of management and managing a project.
I write and administer for 80- 100 users across SQL, Crystal, MIS, and various other Microsoft programs. The golden rule is always - First define the objective: what are you trying to achieve, what's the end game, what do you want from this piece of project? Second: who is going to use it? How are they going to use it- what are they going to get out of it? Thirdly: will they use it? Will they get out of it what they need ( not what we want) to do their job?
When you start with those questions- not project management questions , but management questions - you buy into the responsibility you should be taking to ensure success. From the examples the author gave, it didn't appear that anyone had actually bought into their project - but just took the task and designed a process. That approach and the attitude that goes with it - is doomed forever- and no matter how clever at writing programs the author may be - a change of approach is advised else every project in the future will be a failure.
I really have to disagree here (edit - I mean that I disagree with the article, not with the comments). People should always take responsibility for what they do. Doing exactly what "the boss" wants, even though you know it's wrong, has been the downfall of many companies.
Take the first example, the HMO. If you only found that the users disliked the idea when the project went into production, you clearly failed to do one of the basic tasks of any software project - talk wiith the end users to get their idea on the needs and requirements!! I'd say that the failure of this project should for the most part be blamed to IT.
The second example is not so clear-cut. Maybe the IT dept did a terrific job of explaining how costly this would be, but he was a typpical butt-headed manager who wanted it his way or the highway. Or maybe the IT department was not clear enough, making this one of the many projects in which the "just a bit more" mantra gets repeated over and over again. You can't expect to blame management for spending millions on a project if you constantly ask for just a bit more, suggesting that this will really be the last time....
It really bothers me to read articles like this, suggesting that you should not feel responsible for failed projects. If a project fails, you should reallly have a long and hard think about all the things you could have done differently. Just doing what you are told is not enough.
I would agree with many of the comments. I learned a long time ago that often, if you give the users exactly what they ask for, it won't be what they want! Often our job involves communicating with the end users, understanding what their needs are and how they intend to use the product we will build, and restating back to them how we see things working if we build what they ask for. Often both sides will learn from each other and will, in turn, modify the original specifications.
If this communication does not happen, then there WAS a failure. Maybe not at the level of the coder who was simply told what to write, but certainly somewhere in the IT project management stream.
Calling project #1 a success because it met the specification? Yet the last line clearly stated that it failed because no one ever used it!
There is no way that you can justify calling an unused project a success just because it met the spec.
Thanks for all your comments.
I wrote this article is kind of sacrasm. I did a lot of projects, most of the projects had talented team of programmers working on it. It failed because of the management did not understand the extent of the project or lack of communication between the users and the project leaders.
Every time something liked this happened, I was upset, I worked 60 to 70 hours a week on a project and it failed because of poor management, poor project definition and poor communication. However when the project failed, management blamed it to the programmers, I had enough of this and that was the reason why I wrote this article.
It did not mean I was not responsible for the project, it just meant sometimes I could not control a lot of situation that caused it to fail.
This is the main theme of the article !!!
Have a nice day.
This is a really good article and it reflects the thoughts going on in the minds of developers who have been working day and night on projects which ultimately are deemed as the failure by the management. So whose fault is it? The management or business users never accept that it is because of them the project has failed. So ultimately the poor developers are to take the blame.
I totally agree that the key to the success of the project is the satisafaction of all the stakeholders in the project. But though the project is a failure, the coders/programmers have some satisafaction to the extent that they have done their part with responsibility but the project failed because of something which is not in their hands.
Kudos to the author..
You know, it's a funny world we live in.
If success is measured by whether you have a job or not, then the writer is a success. She has been involved in numerous projects that were useless or counter-productive to her clients, yet she seems to keep finding work!
I guess she is a success!
There seems to be a lot of what the Irish call "blarney" going on in the computer field. My Jewish friends call it "Chutspah". It happens in upper management, middle management, no management, and here in the developer arena. I learned a long time ago that the world is full of people who don't produce anything useful, but they still get jobs. You just have to do your best to work around them if you want to keep yours!