My Projects Have Never Failed
-
One more point...
Not Me, Boss? Not My Job?
I am not responsible for and have no control over the work environment, the teams to which I am assigned, or the leaders and managers who are appointed by management to direct me. How can I feel responsible for the failure of projects due to causes over which I have no control?The real sarcasm is it:All VPs, CEOs, Managers to highest to smallest enforces the job specialization like a dogma. It (and a insane work load) leads to intimate all IT workers to do just thar he is supossed (by contract) to do.How many of yours ´ll reject the VP piece of paper system specification?How many of yours ´ll utter "Its not my team responsability!" at your boss?How many of yours ´ll utter "Its not your job!" for you coworker?
-
Very nice - I have to remind myself that these people pay me, not vice versa - so it's my reponsibility to point out what I see as flaws and issues, but if they insist - it's their decision, and my job is to do my best to implement it.
This can be frustrating.
As you can imagine, I don't always agree with my boss's approach - but one thing he does that's a good idea is "fail fast". If we don't know if this will work, go at it from the angle with the best chance of failure before doing things that might intuitively come first. Sometimes you feel like if you could do it "right" then it might not fail, but it makes sense to minimize the time spent failing.
Too many articles about project "failure" don't get the fact that failure is part of the process. The trick is managing failure well.
Roger L Reid
-
Java and a web interface in 1992 is very impressive !
-
Two important things pointed out here are if customer is happy then the project can be said to be a success (what level of success ... it depends) and the attitude we bring in to to our work. People with a postive and "go get it " attitude get to do interesting projects but i have seen such people overloaded with work too.
There are many factors beyond our control which lead to failures. One thing i have found is the desire to use technology that people are most comfortable working with irrespective of the fact that it may not be the best option.
Another related thing is fear of failure due to which people dont want to try out new things/technologies.
Personally if you have been a part of a failed projects it all comes down how you managed the failure .
"Keep Trying"
-
Holy thread resurrection, batman!
-
Saying a project is a success just because you did everything that was asked of you is arrogant. Saying that your work/ development & implentation of the specification on the project was a success would be more accurate in that respect.
I don't think you can say a project was 100% successful if the end result does not deliver what was expected. You could say it was successful on the whole, but it's just as important to recognise the failures (if any).
-
I haven't seen any projects till date which is going smooth or according to our project plan. I was involved in World bank funded project. The project was managed by some top IT cos in the world. But yet we were delayed just because the customer was not having different ideas at different meetings. We worked very hard just trying to satisfy them :w00t:
I agree with lot of people here that a success of a project is comparative thing. Even with a delay and more cost if your customer is happy then all are happy and project is a great success. :hehe:
-
I worked on a project once where I got the 'report' requirements from the Business Analysts, and it simply said they wanted a report for EVERYTHING (literally, that is what it said).
There was no breakout or list, there were no examples, nothing, it just said a report for EVERYTHING. I very well could have applied my own interpretation to that and delivered a stack of reports (would have been about 50, rough estimate), but is that using project resources (time and money) wisely?
Intuitively, I looked at this and figured out that the Business Analyst either did not have the time or the knowledge (or just didn't feel like it) to properly research and assess the needs of the customer and provide requirements information that was realistic (at least give me a list and description of each report). I took it to my boss and showed him and he agreed with me, that we should go back to the Lead BA and get more clarification because this was going to be a big endeavor (on an already huge project), and at least get a sanity check, and if they truly do NEED EVERYTHING, then get a list of deliverables and some kind of requirements for each. I also told the lead BA that it looked like someone didn't feel like doing this (we were all spread thin) and that I can give him 50 reports (and that count was just a guess), but do the users NEED these, and will they use these, or will they just get printed out, then sit on someones desk until they get thrown in the trash (how many times have we seen this).
When the lead BA got back to me, the list was down to 5 reports (a far cry from the original 50) and I had requirements for each (which is how it should have been)
So by using a little intuition and questioning the requirements (it was obvious they were lacking) we were able to get more realistic requirements that ultimately saved a lot of time and money, both of which were in short supply. Personally, I believe the requirements should have never made it to me, they should have been caught in the approval process, but at least there is some notion of checks and balances in the entire process.
Had I gone ahead and given the users 50 reports with the vague requirements I had, the chances of me getting it right would have been pretty slim and it would have made us all (the project team) look stupid.
This is analogous to asking a home-builder to build you a house without providing any input. I'm sure he could build a very nice well built home, but will it suit your needs? I'm sure it would have been a successful project to him (he did what he was asked), but most likely, he would not have met all your needs simply by guessing. Realistically, no builder is going to do this...he is going to ask you what you need and then deliver that. And so it is the same in software development...we have to use our own judgement to assess requirements (or lack of) and designs and go back to our analysts and end users and find out what it is they WANT, and more importantly, what they NEED. At least then everyone is 'on the same page' as far as project expectations are concerned and you have a better chance of overall project success.
If it was easy, everybody would be doing it!;)
-
Its my 5 cents to the article.
In whole it a brainwashing publication.
The goal is to show romantic of professional
programming and make a spirit of
professionalism equal to independence.
From other point of view this is exactly that
top managers expecting from their
employees. Do not discuss top people
decisions and show progress and competence.
So this publication has nothing to do with
the header of the article and discussion
of failing or success.
-
I wonder what search resurected this project .. sorry thread!! If I ever try searching for a thread from last year I can never find it.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Viewing 10 posts - 46 through 54 (of 54 total)
You must be logged in to reply to this topic. Login to reply