My Projects Have Never Failed
-
WOW!
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.
Scott
-
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.
-
Yeah,
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..
Good day..
-
From The Article: Communication failed and I am sure that as a result, the HMO users felt, at least to some extent, that the project had failed. So who failed, when the people who need to talk to each other don't?
Sarcasm or not, this is where you should have made the effort to talk to the end users and get them to make an additional request to IT to have the doctors grouped for them. Even if a percentage of the doctors were grouped by IT based, it would have made the project a more successful. The end users would then see that IT was working with them and not against them.
I did not see this article as sarcasm. I see it as a developer doing ONLY development and not taking the extra step or steps to understand the business rules and politics of the companies she worked at.
AO
-
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!
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.” -
Funny article.
It's like saying I never had trouble expect when I had trouble.
-
Sorry. This article is just wrong.
Success or failure for a project is measured on all of the following criteria:
- It meets budget
- It delivers the required functionality
- It is on time
- (Most importantly) it's acceptable to the client and gets used.
If you fail to meet any one of these criteria then your project is not a complete success, and therefore a partial failure. Yes, scope and functionality can change during the course of a project, but their associated measures should change in line.....
You may do your job efficiently and deliver your bit of a project to time, budget and quality requirements, but if it don't deliver overall you are still party to the project failure. I would inherently mistrust anyone working on a project who displayed this kind of sentiment. It smacks of teflon shoulders......
-
I think there is some value in understanding as a employee/manager that you can do your best, do good/great work, and still have a product that fails for any number of non-technical reasons, some or all of which may be beyond your control. I think it would be seriously flawed to only a call a project a failure if didn't work at the technical level. I can't say that I agree with the article as written.
IT people take most things literally, while everyone else in the world doesn't, or at least to the same degree. When they say 100% uptime there is just no telling what they really mean without digging in from multiple angles. Get the players in a room with a whiteboard and start to ask questions. Here's an example. Several years ago while managing a developer and dba team I was invited to sit in on a high level meeting about something that wasn't really about development, but my boss wanted me there to just stay in the loop. Imagine my surprise when the big dog starts out by talking about how our data model is preventing the entire company from succeeeding! I listen a bit and try to avoid the standard defensive stance, and when they get to a break I ask if the could clarify what they meant by data model - turns out it was the questions they were asking on the phone, nothing to do with how we stored or reported on the data.
-
"Sarcasm or not, this is where you should have made the effort to talk to the end users"
I think something is missing here. Not every developer has the exposure to the business world. There are project managers, business analysts, systems analysts, QA teams, etc that perform that task. There are project sponsors on the business side (especially for internal IT projects) that are responsible as well for ensuring that the requirements match the needs. For a developer to even think to say "Should we be populating the data for them" in the HMO example is not necessarily his role. And not necessarily his expertise, either.
As a VP of Technology in the financial services industry, I try to empower everyone to step up - offer advice, constructive criticism, bring up problem areas of a project, etc. However, when the business analyst works on the requirements, why should the developer question every requirement? Not to say that if they notice a problem, say something. But for the basic tenents of a project - the developer is not necessarily in a position to know what the correct requirements are. It is beyond the developer's control, for the most part (of course, those developers that DO have insight into the business SHOULD stand up, but only the really good ones ever can).
For that - it is up to the business analyst, one of the most underrated positions on a software development team. They need to be immersed in the business, understanding the pains and nuances of what the business users do. A good business analyst should have asked the right questions in the HMO project, such as "is there a way for us to prepopulate the data". I cannot overstate that having a top notch BA on a project can mean the difference between a successful project and one that falls far short of expectations.
The PM should then manage expectations. If a project is really successful, maybe the expectations won't need to be managed at all. I'd say that is a rarity, though.
-
Most of us are familiar with the serenity prayer, “I seek the serenity to accept what I cannot change; the courage to change what I can; and the wisdom to know the difference.”
This is all the author is saying.
I have an anecdote of my own. My boss is the Director of Technology, and ironically, is about as technically savvy as a toddler. He is infamous for underestimating development time. When provided with a development schedule, he’ll always ask, poke, prod, bully, cry -- “I don’t understand why this would take so long.”
Inevitably, to make the boss (i.e. my customer) happy, rather than sticking to the truth (ex: the enhancement will take a month), I learned to let him persuade me that he’s probably right, and I’m probably wrong (the enhancement will take three days). For some reason that I can’t fathom, he doesn’t get too upset when a project takes significantly longer than projected, but he gets terribly upset when provided with realistic projections up front.
Unfortunately, in my experience with prior employers, my boss is more the rule than the exception. As I believe the author is saying, we developers/DBAs can’t control management’s refusal to thoroughly define a project, despite our best efforts to persuade them (unfortunately, sometimes it’s best to keep your mouth shut). We can’t control constant change orders during development, despite our best efforts to inform them of the cost. We can’t control management’s seemingly deliberate naiveté about development schedules. We can only accept what we can’t change, change what we can and have the wisdom to know the difference.
My interpretation is that the author is simply saying that she is not going to fret when a project fails for reasons that are entirely outside her control. On the other hand, she will give herself a pat on the back when she has done her best. In my opinion, that's a great attitude to have.
-
This article reminds me of the mindset I had in the first year I left college... and I'm glad it has had many responses, and has got people thinking! A big thanks for writing the article - we need more of these that are though provoking...
Most of the concerns I have (and there are many) with this article have already been commented on, but I would also be interested to know in any of these projects whether there was a follow up meeting between the developers, managers, project managers AND clients in order to get to the bottom of what caused the projects to fail so that the company learnt from its mistakes...
...and Yes, as has been mentioned above x times... You SHOULD take responsibility for your actions, not just sit in your cube saying "it's not my fault".
-
Well, I had a nice rant composed in my head and then I saw the author's post about this article being sarcasm. Unfortunately, there are a lot of developers out there that think the way this article sounded. Using "it matches the spec" is a lame excuse for not providing what the user wants.
Maybe the reason the web based report project took so long was because you were trying to use a language in 1992 that didn't come out until 1995
-
ah, its sarcastic!
Missed that myself
-
Some of the projects that I'm involved in are considered warehouse projects. Receiving, put away, moves, picking, packing, shipping, and order processing. On those I say that it is important to know who you are relly working for. Not my company, no. Not the executives at the customer company. Not the IT department. It is the folks on the loading docks and in the asiles acutually moving this stuff around.
I have to know warehousing inside out. I even have to be up on all the transport laws. I don't want some driver to wind up in jail because the paper work my systems print is wrong. Is this my responsibility? Damn Right!
I have worked on health care systems dealing with medical records includuing treatment planning. Screw up here and somebody could die because of a software mistake.
I have had co-workers say, "It's all just data. So what?" I was never so tempted to actualy slug somebody!
This could all stem from the fact that I don't have kids. My projects are my children. They came from me and I send them out. I want to be proud of them. Like children I'm responsible for their behaviour.
ATBCharles Kincaid
-
Quality is conformance to requirements. From an IT perspective, the project can fail when the development team goes too far from good requirements. From a client perspective the project can fail because it doesn't live up to some dream the user had but never enuciated. However, IT can't be held responsible for the failings of the user.
If IT did the best job humanly possible to get good requirements out of the user, and the users don't like it, the project might have failed from the perspective of field use, but when a "lessons learned" meeting occurs, the blame should be layed squarely at the users' feet.
Viewing 15 posts - 16 through 30 (of 54 total)
You must be logged in to reply to this topic. Login to reply