InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 21 May 2013 08:59:30 GMT20http://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxI wonder what search resurected this project .. sorry thread!! If I ever try searching for a thread from last year I can never find it.Thu, 28 Feb 2008 15:48:29 GMTcolin.Leversuch-Robertshttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxIts my 5 cents to the article.In whole it a brainwashing publication.The goal is to show romantic of professionalprogramming and make a spirit ofprofessionalism equal to independence.From other point of view this is exactly thattop managers expecting from theiremployees. Do not discuss top peopledecisions and show progress and competence.So this publication has nothing to do withthe header of the article and discussionof failing or success.Thu, 28 Feb 2008 07:54:24 GMTIgor Zaychikhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxI 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.Thu, 28 Feb 2008 06:12:37 GMTTraderSamhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxI 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:Thu, 28 Feb 2008 05:25:02 GMTAnipaulhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxSaying 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).Thu, 28 Feb 2008 05:09:11 GMTSALIM ALIhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxHoly thread resurrection, batman!Thu, 28 Feb 2008 01:50:37 GMTAndy in Pembshttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxTwo 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 .Wed, 27 Feb 2008 23:07:56 GMTChiragNShttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxJava and a web interface in 1992 is very impressive !Wed, 27 Feb 2008 22:26:36 GMTRobertWilkinsonhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>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.</P><P>This can be frustrating. </P><P>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.</P><P>Too many articles about project "failure" don't get the fact that failure is part of the process. The trick is managing failure well.</P>Thu, 03 May 2007 14:08:00 GMTRoger L Reidhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>One more point...</P><P> </P><DIV><SPAN style="WIDTH: 625px; HEIGHT: 101px" onclick=this.focus();><EM><H3 class=SEction><I><FONT style="BACKGROUND-COLOR: #ffffff">Not Me, Boss? Not My Job?</FONT></I></H3><P></EM><FONT style="BACKGROUND-COLOR: #ffffff">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?</FONT></P></SPAN></DIV><DIV> </DIV><DIV>The real sarcasm is it:</DIV><DIV>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.</DIV><DIV> </DIV><DIV>How many of yours ´ll reject the VP piece of paper system specification?</DIV><DIV>How many of yours ´ll utter "Its not my team responsability!" at your boss?</DIV><DIV>How many of yours ´ll utter "Its not your job!" for you coworker?</DIV><DIV><img src='images/emotions/whistling.gif' height='20' width='20' title='Whistling' align='absmiddle'></DIV>Wed, 02 May 2007 13:50:00 GMTjcbhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxI 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. Wed, 02 May 2007 09:34:00 GMTJohn Hannahhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxWas 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"!Tue, 01 May 2007 10:58:00 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>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. </P><P>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.</P><P>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?</P><P>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 !! </P><P>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.</P><P> </P><P> </P><P> </P>Tue, 01 May 2007 10:53:00 GMTcolin.Leversuch-Robertshttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>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.</P><P>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.</P><P>Measurement? We ask the users, "Is your job easier than last week?"</P>Tue, 01 May 2007 09:21:00 GMTCharles Kincaidhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>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!</P><P>I also would agree that an individual can perform their own role superbly while the overall outcome is an unmitigated disaster.</P><P>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!</P><P>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.</P>Tue, 01 May 2007 01:47:00 GMTStewart Joslynhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>(a bit of a rant!)</P><P>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!</P><P>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.</P>Mon, 30 Apr 2007 16:07:00 GMTSpudmasherhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxFailure 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.Mon, 30 Apr 2007 16:04:00 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>The point being...</P><P>Project failure can have multiple root causes. Project failure does not directly equate to personal failure.</P><P>Sometimes companies are learning organizations and can improve and learn from their failures. Sometimes they aren't. </P><P>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.</P>Mon, 30 Apr 2007 15:49:00 GMTL Olsonhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxThe 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 &amp; resources, then you are a succees. Not only in IT but in real life.Mon, 30 Apr 2007 14:57:00 GMTWILLIAM MITCHELLhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>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?</P><P>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?</P><P>Quit before the company goes under...</P><P>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.</P><P>--Chris</P>Mon, 30 Apr 2007 14:47:00 GMTChristopher Kleinhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>Never mind ...</P><P>What a load of ....</P><P>If you in a car that is involved in an accident thru no fault of yours, you were still in an accident!</P><P>I'm not surprized, you see things differently. You actually believe that the reports on failure are from your point of view?</P><P>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. </P><P>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.</P><P> </P><P> </P><P> </P><P> </P>Mon, 30 Apr 2007 14:31:00 GMTBrian_Sullivanhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxThe article could almost have a title of "how not to manage a project".The sucesss of a project depends on <a href="http://www.sqlservercentral.com/columnists/dpoole/lessonsfrommyfirstprojectasaprojectmanager.asp">managing user expectations</a> 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.Mon, 30 Apr 2007 13:24:00 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxIf 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.Mon, 30 Apr 2007 12:21:00 GMTGodekehttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>In evaluating success or failure, it's important to differentiate the scope. The <STRONG>projects</STRONG> were indeed failures in all of the author's examples. However, the author's <STRONG>development contributions</STRONG> to the project were successful.</P>Mon, 30 Apr 2007 11:05:00 GMTmikeyradhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxFrom 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. AOMon, 30 Apr 2007 10:05:00 GMTaochsshttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>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. </P><P>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.</P>Mon, 30 Apr 2007 10:01:00 GMTPatrick Davenporthttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>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.</P><P>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!</P><P>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.</P><P>I have had co-workers say, "It's all just data. So what?" I was never so tempted to actualy slug somebody!</P><P>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.</P><P> </P><P> </P>Mon, 30 Apr 2007 09:52:00 GMTCharles Kincaidhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxah, its sarcastic!Missed that myself <img src='images/emotions/whistling.gif' height='20' width='20' title='Whistling' align='absmiddle'>Mon, 30 Apr 2007 09:18:00 GMTAndy in Pembshttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxWell, 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 1995Mon, 30 Apr 2007 09:11:00 GMTJeff Martin-356997http://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>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...</P><P>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 <B>learnt from its mistakes</B>...</P><P>...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".</P><P> </P>Mon, 30 Apr 2007 08:55:00 GMTAndy in Pembshttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>Most of us are familiar with the serenity prayer, “<EM>I seek the serenity to accept what I cannot change; the courage to change what I can; and the wisdom to know the difference</EM>.”</P><P>This is all the author is saying.</P><P>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.” </P><P>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.</P><P>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.</P><P>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.</P><P> </P>Mon, 30 Apr 2007 08:49:00 GMTChris-232075http://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>"Sarcasm or not, this is where you should have made the effort to talk to the end users"</P><P>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.</P><P>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).</P><P>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.</P><P>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.</P><P> </P>Mon, 30 Apr 2007 08:35:00 GMTJason-262847http://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>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.</P><P>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.</P><P> </P><P> </P><P> </P>Mon, 30 Apr 2007 08:31:00 GMTAndy Warrenhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>Sorry. This article is just<EM> wrong</EM>. </P><P>Success or failure for a project is measured on all of the following criteria:</P><UL><LI>It meets budget</LI><LI>It delivers the required functionality</LI><LI>It is on time</LI><LI>(Most importantly) it's acceptable to the client <EM>and gets used</EM>.</LI></UL><P>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.....</P><P>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 <EM>still</EM> 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......</P><P> </P>Mon, 30 Apr 2007 08:14:00 GMTBald Eaglehttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxFunny article. It's like saying I never had trouble expect when I had trouble.Mon, 30 Apr 2007 08:06:00 GMTsqlAdmin-108553http://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>You know, it's a funny world we live in.</P><P>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!</P><P>I guess she is a success!</P><P>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!</P>Mon, 30 Apr 2007 07:54:00 GMTSomeguyhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspxFrom 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. AOMon, 30 Apr 2007 07:13:00 GMTaochsshttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>Yeah,</P><P>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. </P><P>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.</P><P>Kudos to the author..</P><P>Good day..</P>Mon, 30 Apr 2007 07:13:00 GMTsairam-257016http://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>Thanks for all your comments.</P><P>I wrote this article is kind of <STRONG>sacrasm</STRONG>. 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.</P><P>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. </P><P>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.</P><P>This is the main theme of the article !!! <img src='images/emotions/tongue.gif' height='20' width='20' border='0' title='Tongue' align='absmiddle'><img src='images/emotions/rolleyes.gif' height='20' width='20' border='0' title='Rolled Eyes' align='absmiddle'></P><P>Have a nice day.</P>Mon, 30 Apr 2007 07:04:00 GMTLonerhttp://www.sqlservercentral.com/Forums/Topic347466-309-1.aspx<P>WOW!</P><P>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!</P><P>There is no way that you can justify calling an unused project a success just because it met the spec.</P><P>Scott</P><P> </P><P> </P>Mon, 30 Apr 2007 06:38:00 GMTScott Arendt