April 30, 2007 at 10:05 am
From Earlier: "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. The...
Wow, if the article was written as sarcasm, I must have been reading it too literally. A wink, wink, nudge, nudge at the end of the article would have probably made that more clear.
However, I must agree with Charles. Even if you don't have access to the end users, someone above or below must have that access. I have seen problems in a piece of code fester and live long after they should due to the "No my code, not MY problem" mentality.
A walk around the areas where your programs are being used is most of the times very enlightening for developers and programmer (business) analysts alike. Users will almost always find the most unexpected and interesting ways to use a program.
Great discussion.
AO
April 30, 2007 at 11:05 am
In evaluating success or failure, it's important to differentiate the scope. The projects were indeed failures in all of the author's examples. However, the author's development contributions to the project were successful.
April 30, 2007 at 12:21 pm
If the projects failed due to political, financial or governance reasons it is hard to fault the developer in the trenches. Everyone has the rug pulled out from under them sometimes.
What *is* disturbing is the *number* of examples this developer has. Part of career management and personal development is moving out of the trenches and up the food chain to where more accountability is part and parcel with the job.
I have had failures that were out of my control... and I have had failures where I can squarely point at myself as a cause. Some of those failures were used and even considered successes... but I knew the flaws and limitations that shouldn't have been there.
Critical thinking is part of the road to getting past such failures. Understanding which failure modes were caused by external forces and which failure modes you can avoid in the future is a requirement of successfully moving *past* the point where everything is "someone else's fault".
In other words: I think that this point is in part "correct" in the assessment of personal responsibility, but points to a deeper problem in the career management of the poster.
April 30, 2007 at 1:24 pm
The article could almost have a title of "how not to manage a project".
The sucesss of a project depends on managing user expectations and keeping them informed as to progress. It sounds from the article as if the project gets handed over to the customer as a completed article and the customer is in total shock as to what they have received! If it gets to this stage then the project is almost certainly to fail from the commercial perspective.
If the customer doesn't feel it is "their" project then watch out.
A customer who feels that they are having a system foisted on them can make its deployment an impossibility. Perfectly good systems/tools get rejected for emotive rather than rational reasons. I have even seen users accept a manifestly inferior product simply because they HAD been involved in the selection process.
April 30, 2007 at 2:31 pm
Never mind ...
What a load of ....
If you in a car that is involved in an accident thru no fault of yours, you were still in an accident!
I'm not surprized, you see things differently. You actually believe that the reports on failure are from your point of view?
The people who spend money on this sort of thing, don't care how you 'feel'. They are concerned with users and the bottom line.
Think about it. Does it really matter if 'it was not your fault', if the company you work for goes under. You are still out of a job.
April 30, 2007 at 2:47 pm
So if you had a project that you worked on for 3 years, met technical, database and user expectations and deadlines along the way but then the product simply failed to sell because someone didn't realize that the market was saturated this is the fault of the developer? or the project manager?
I imagine the answer is the project manager. The project manager is supposed to tell 'the boss' that the market cannot support the application, but what if they still want it done?
Quit before the company goes under...
I read the first paragraph of the article and was thinking that it was 'sarcasm' but as I continued to read it started to sound too much like real life unfortunately.
--Chris
April 30, 2007 at 2:57 pm
The last four paragraphs of the article sums it all up - you can never have total control of a project, but if you do the best you can to complete an assignment with the available information & resources, then you are a succees. Not only in IT but in real life.
April 30, 2007 at 3:49 pm
The point being...
Project failure can have multiple root causes. Project failure does not directly equate to personal failure.
Sometimes companies are learning organizations and can improve and learn from their failures. Sometimes they aren't.
Sometimes an individual can have a big impact on that cultural choice in an organization by being a catalyst for change. In order to do this, they need to understand and analyze what factors contributed to the success or failure of a project. Then, the individual with that knowledge becomes all the more valuable because they can take credit for the correct things, learn from the mistakes, and make other people aware of opportunities for the company to improve. And if no one will listen, you can decide like others did if the company is a good fit for you or not.
April 30, 2007 at 4:04 pm
Failure of a project is definitely something I think you can measure and a few people have given some nice criteria.
However personal success or failure is something different and something that you need to measure yourself. Did you give 100%, do the best you could, try to make a difference, etc. As the last few people pointed out, sometimes you just can't effect the overall success.
I think the article is a little sarcastic, but there's some truth in there. You can be a part of a "losing team", but still be successful in your career. I'd like to think that Janet has had some success at other projects and these 3 projects don't define her career.
It also reminds me of some discussions on interviewing I've had with people. Myself and others have interviewed people for high or senior level positions, only to be stunned by the lack of knowledge these people have. But at the same time, some of these people have been successful in their situation. Is it that they haven't learned enough or did they learn enough to do a good job? It's all in the perspective.
April 30, 2007 at 4:07 pm
(a bit of a rant!)
I feel its down to the politics of the business to deem a project to success for failure. Of course the business (if the project comes from management) will never deem a project a failure, if they do, heads will roll! I worked on a major security upgrade project for a government department recently. The department was moving away from the norm, in that every other department was following one track and they wanted to be different. So they came up with this very elaborate solution using 13 servers per environment (we're only talking 3000 users here and the original system was all done successfully on SQL Server 2000) - but they moved to Sun products on a Windows environment. The Sun products had never been tested on Windows before and after months of analysis and past 3 go-live dates. It was deemed that Sun needed a patch to fix their product. So, after the patch was applied and tested a new go-live date was announced, a few drinks were had, free lunch - but further issues were found. So go-live was delayed. Again new date, new problems, repeat cycle. It was (is!) a real embaressment. Last I heard there was a new go-live date but no-one was allowed to use it and still problems exist. Management continue to call this project a success when it is now 8 months overdue and well over budget - the only reason "the workers" say it hasnt failed yet is because the architects who designed the elaborate solution (because they want to fly round the world and promote themselves!) are hand in hand with upper management. Is it any wonder the architects are called "The Teflon Team" - sh*t dosnt stick to them!
Any project that is overdue and over budget due to bad design, bad code and or bad management is a failure, because it hasnt met the budget, the design or management requirements! There are too many business managers out there being blinded by science and being led down the merry path.
May 1, 2007 at 1:47 am
I doubt that there are many IT projects of any size that can be deemed a complete success in all respects. There is always something that could have been done better, differently or more cheaply. The post-implementation review process is there precisely to identify those 'failings' and, if it doesnt find any, can itself be deemed a failure!
I also would agree that an individual can perform their own role superbly while the overall outcome is an unmitigated disaster.
But a project requires team work and the ideal team is a team of peers. Whatever my nominal role, I should have equal respect with all other members, take an interest in the overall project and contribute in whatever way I can to its success. If I see something going wrong, whether or not it is my nominal responsibility, it is my duty to my colleagues (and to myself) to point it out and offer a solution. If they reject my suggestion and the project fails as a consequence, then it was, at least in part, my fault for not being persuasive enough!
At the end of the day, it's a question of the attitude that you bring to your work - and life in general. You also will find that (positive) contributors usually end up with more interesting projects and more successful careers.
May 1, 2007 at 9:21 am
I'm currently involved in a project that is sort of unique. It's for a multi-billion dollar company. We threw out requirements, specs., milestones, etc. I am in daily contact with supervisors, plant managers, logistics co-ordinators, I.T. managers, network gurus, shipping clerks, and on and on. Everybody from CIO and CFO right on down to people on the production floors, in the warehouses, and on the docks.
It's cool. Way cool. If I need something they stop and send it to me. Likewise when questions come up I stop and dig it to the bottom. Success? Oh yes. Finished? No where near. We are constanly making adjustments to a system of sub projects that is in production, on line, and darn near real time. The list of enhancements to come is a book. Only one volume so far.
Measurement? We ask the users, "Is your job easier than last week?"
ATBCharles Kincaid
May 1, 2007 at 10:53 am
Having been within a project that failed big time, maybe £10 million down the drain and lots of jobs lost,from CIO down it's not an easy call.
What I'd probably observe from the article and many of the posts is that the projects were not managed correctly - however that's an easy statement to make, and I can draw on my above example where the DBA team expressed their concerns , well we actually said the implementation was unworkable, what actually happened is that we were told to get on and do as we were told or face the sack.
The pressures and reputations of too many are at risk in a large project and often too many decisions are made without input from the "right people". On a simple level how many DBA's get to have to install database applications which don't work, are full of security holes etc. etc. but were no part of the selection process?
I was part of a BI selection process where we rejected a major BI vendors tools, the Vendor took exception and attempted to get the decision overturned by going to the Managing Director , the argument the Vendor used was that they did not expect to present their products to technical people being more used to presenting to boards of directors. So for a major application around £1 million it should have been decided by non technical people !!
Very tricky and to be honest I'm surpised some companies manage to stay in business and it may explain why IT is so often seen as the enemy within a business.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
May 1, 2007 at 10:58 am
Was Betamax a failure?
Technically far superior to VHS and much more compact and yet due to market forces it was eclipsed by VHS.
Similarly the last European Ford Escort sold by the boat load, even though it wasn't particularly reliable and was certainly well behind in terms of the way it functioned.
It just goes to show that no matter how excellent your product it can still fail for reasons that are grossly unfair. In the words of the song "Life's a bitch and then you die"!
May 2, 2007 at 9:34 am
I must agree that with those that have said if the customer isn't happy, the project has failed. You have to accept that you are sometimes going to be assigned to projects that fail. That doesn't mean you are personally a failure. Ultimately, however, there is one criteria for success and that's a happy customer/end user. The project at the HMO was most certainly an abject failure and the resources devoted to the generation of the single report at the software firm are ludicrous.
Viewing 15 posts - 31 through 45 (of 54 total)
You must be logged in to reply to this topic. Login to reply