<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on 10 ways to avoid mistakes during project development ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-326192/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-05-21T11:55:50-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[&quot;Sell users what they want, give them what they need&quot;]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3261117]]></link>
        <description><![CDATA[That's been an adage of ours for all our working life. What it means is that what users see on the surface has to be a good match for what they say they are looking for, but what exists underneath has to be well engineered, future-proof, and covering all the cases the users have not even though about. The &quot;mistake&quot; is implementing what the user asks for, without engaging your brain.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3261117]]></guid>
        <dc:creator><![CDATA[Kim SJ]]></dc:creator>
        <pubDate>Tue, 16 Mar 2010 08:02:42 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: 10 ways to avoid mistakes during project development]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3260768]]></link>
        <description><![CDATA[Good article. All 10 ways mentioned are very effective and practicle. Specially proper and thorough testing with good collaboration among team members helps a lot to deliver good product.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3260768]]></guid>
        <dc:creator><![CDATA[deepakdabas]]></dc:creator>
        <pubDate>Mon, 15 Mar 2010 21:25:19 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Re: Learning from mistakes]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3251355]]></link>
        <description><![CDATA[Shawn,Why would anyone want to know history?http://thinkexist.com/quotation/those_who_don-t_know_history_are_destined_to/346796.htmlI agree with you but you would be missing a big part of the picture.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3251355]]></guid>
        <dc:creator><![CDATA[Alan Norton]]></dc:creator>
        <pubDate>Fri, 26 Feb 2010 11:25:19 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: 10 ways to avoid mistakes during project development]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3251092]]></link>
        <description><![CDATA[Regarding item #1Why would I want to learn from mistakes - I would rather learn from successes - I see a lot of Project Groups, Sales Team, and corporations analyzing what went wrong instead of what went well.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3251092]]></guid>
        <dc:creator><![CDATA[shawn46]]></dc:creator>
        <pubDate>Fri, 26 Feb 2010 07:05:24 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Design first]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3250675]]></link>
        <description><![CDATA[You forgot the most important. Do your design first. In our agile world so many forget that. It is possible to design excellent software.You, as most everyone also over emphasize testing. I have started to say &quot;don't test - design&quot;. Of course that is a little rhetoric, but there is a lot of truth in it.You should write correct code that does what it shall do all the time. You do that by designing first, creating a simple design document that will be thrown away as soon as you have finished the first release version. Then you write a few lines of code, execute, a few more lines, execute, and you know it's correct. Of course this is testing But the aim is to understand exactly what you write and that it's correct according to a design.Then don't listen to users!They are not software designers, and can not design the code, not even the user interface for you. There are a few exceptions for user interfaces with exceptional users, but otherwise you have to do the design.To do this you have to listen to your users!But not to do what they say they want, but to learn what they really need and then deliver something better than they expect. The wow effect is close, but it does require a lot of work.To be a professional developer you have to know better than your users their requirements and needs. You can only do that by learning from lots of different users by communicating with them and studying their profession more then they do.Lots of work, but your aim is excellence and nothing less is possible.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3250675]]></guid>
        <dc:creator><![CDATA[nils2myklebust@...]]></dc:creator>
        <pubDate>Thu, 25 Feb 2010 15:00:52 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Mastectomy mistake]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249884]]></link>
        <description><![CDATA[http://www.cbc.ca/health/story/2010/02/24/surgical-checklist.htmAbove is a recent article where a breast was removed by mistake. For the 2nd time by this surgeon. The 1st time it was hushed up. Now, infer what you will.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249884]]></guid>
        <dc:creator><![CDATA[Englebert]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 20:31:32 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[&quot;I deleted some files off the client's PC by mistake&quot;]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249747]]></link>
        <description><![CDATA[So I got out the backup...Oh there was no back up, or it woudn't restore, or those files weren't on it, or you couldn't extract just those files...Well there's the real coke up then!The fact that you manually deleted the files is irrelevant.A programming error could have done it,A power cut, a lightning strike, pour your coffee down the cooling vents. A hard drive failure or corruption.Your 'mistake' was fortuitous!Learning it from it, is not &quot;don't do that again&quot;.It's that your client was a clock cycle from disaster, is a clock cycle apparently, since you didn't ameliorate the risk in any effective way.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249747]]></guid>
        <dc:creator><![CDATA[Tony Hopkinson]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 14:15:20 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Re: Item order]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249708]]></link>
        <description><![CDATA[Ha ha!  Very clever of you!Normally I don't put the '10 things' items in any particular order.  For this article it made sense to order the items to match as best as possible the Project Life Cycle.  Maybe I  should have put item 2 first!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249708]]></guid>
        <dc:creator><![CDATA[Alan Norton]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 13:28:51 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[I am reminded of the old joke...]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249705]]></link>
        <description><![CDATA[... credited to Henny Youngman - http://www.funny2.com/henny.htmPatient:  &quot;Doctor, it hurts when I do this.&quot;  Doctor:  &quot;Then don't do that!&quot;And then there is the saying in basketball, &quot;No harm, no foul.&quot;I see that there are a lot of you who think I should have shared my mistake with others.The two words &quot;really stupid&quot; and the fact that the mistake was fixed before it could be noticed are the reasons why I felt no need to share my mistake.  I could be wrong, but I could see nothing to be learned by others:Alan:  &quot;I deleted some system files on a client's PC.&quot;Boss: &quot;Don't do that!&quot;I agree 100% that if others can learn from your mistakes you should  consider  sharing it.I would classify how to handle mistakes into three categories:1.  The mistake becomes known to others and fixed - Read and follow Calvin Sun's advice at http://blogs.techrepublic.com.com/10things/?p=270.  Take responsibility for your error and try to make something positive out of a bad situation by helping others learn from your mistake.2.  The mistake is not known to others, fixed and others can learn from your mistake -  Consider  telling others so they can learn from your mistake.  It's your choice.  You have to weigh any benefit gained against any personal damage.  Sharing too many mistakes can be item one on your next performance review.  3.  The mistake is not known to others, fixed but there is nothing to be learned from your mistake - It might make for some light humor (he did what?!) but what else is there to be gained?  It is even more unwise to share your 'mistake' with the client.  No harm, no foul.We all make dozens of 'mistakes' a week that we find and correct.  I used to have to participate in a teleconference call at one of my jobs.  It usually lasted 45 minutes to an hour.  I can't begin to imagine the litany of mea culpas if everyone on the team decided to share every little mistake.  In fact, I don't remember anyone volunteering to share  any of their errors, big or small.I do however remember the big mistake I made and I am happy to share it with you here.  I submitted a request to reindex one of our database's indexes.  The request was queued and never ran because, unknown to me, the reindexing could only be completed when there was no user activity.  By the morning, the entire system was locked up and yours truly got the opportunity to step forward, take responsibility and explain what I had done to everyone on the conference call.I am encouraged to hear so many of you say that you should take responsibility for your mistakes.  I totally agree.  I just don't think that it is wise to share every mistake and, in good conscience, I can't recommend that you share a mistake made in scenario two or three since it could damage your career with little or no gain.  That has to be your choice.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249705]]></guid>
        <dc:creator><![CDATA[Alan Norton]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 13:15:33 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Item 11]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249523]]></link>
        <description><![CDATA[Involve real users in prototype testing at early stage development.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249523]]></guid>
        <dc:creator><![CDATA[@techbridge_ca]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 09:16:35 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[People make misteaks]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249368]]></link>
        <description><![CDATA[A sophisticated manager understands that people make mistakes. We're all human. Now, two things have to happen : 1. The mistake has to be fixed. 2. The process that allowed the mistake to occur has to be fixed. And communicated to all. Chances are if you made that mistake, others could have as well. So, the experienced manager calls a meeting and explains it to all.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249368]]></guid>
        <dc:creator><![CDATA[Englebert]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 06:46:28 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Clients Lie!]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249376]]></link>
        <description><![CDATA[If you watch the TV show &quot;House&quot;, you know that many of his miraculous cures come when he discovers the client's lie.  Same is true in IT Projects.  Few clients know the real issues, so they tell you only part of the truth.  Your challenge is to uncover all the issues and build them into the plan.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249376]]></guid>
        <dc:creator><![CDATA[jalexan@...]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 06:43:37 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Had me until the &quot;Final Word&quot;]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249357]]></link>
        <description><![CDATA[You had me going until the &quot;Final Word&quot;.  While you should immediately resolve your mistake, in the efforts of fostering your very first point, you should be willing to relay and even laugh at your stupid mistake.  How wrong would it be if a colleague made the same mistake you did because you were too embarrassed to relay your mistake to them????Finally, I've always said:&quot;If you are an active developer (and haven't moved on to other responsibilities), you should be able to look back at the work you did a year ago and see ways you could have done it better, even if what you did a year ago was quite good.  Otherwise, what have you learned in the last year?&quot;]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249357]]></guid>
        <dc:creator><![CDATA[karl.werner]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 06:22:58 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Agree]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249239]]></link>
        <description><![CDATA[I agree, I'd much rather have people realize a &quot;stupid mistake&quot;, own up to it, but most importantly LEARN from it. Then I know there is growth and integrity!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249239]]></guid>
        <dc:creator><![CDATA[B@...]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 03:46:01 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: 10 ways to avoid mistakes during project development]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249254]]></link>
        <description><![CDATA[Even you're talking about a product (project development, may be a system), you've described the ITIL V3 Foundation core (IT Service Management): V model, communication policy, Catalogue, RFC approve after CAB, etc etc. That's great, because ITIL has bourned as good practices after a long research about IT best practices inside various world businesses. You can also express in this way: even you're an IT professional don't think to be the only in the universe fighting against a big project; be honest, take your time, share ALL in a trasparent way, learn from and collaborate with others (not only IT); in this way the goal will be yours. Isn't it?]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249254]]></guid>
        <dc:creator><![CDATA[nicola_gambetti@...]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 03:25:04 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Owning up to mistakes]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249251]]></link>
        <description><![CDATA[Alan - that was a clever ruse to get us writing replies! I had posted the following before reading the further article and I will willingly admit my error!I couldn't agree more. Hiding mistakes is a disastrous idea with potentially disastrous consequences.  A project leader needs to foster a culture where people will admit their errors, no matter how stupid, and learn from them. In the example how could the writer be 100% sure that the new files he copied were exactly the same as the ones he'd deleted?]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249251]]></guid>
        <dc:creator><![CDATA[mialp@...]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 02:27:57 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Dont agree with &quot;stupid mistake&quot; point in conclusion]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249245]]></link>
        <description><![CDATA[I agree. Unless Alan meant that the &quot;mistake&quot; would have no harm done, which is very rare.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249245]]></guid>
        <dc:creator><![CDATA[Suresh Mukhi]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 02:02:02 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Dont agree with &quot;stupid mistake&quot; point in conclusion]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249235]]></link>
        <description><![CDATA[No matter how stupid a mistake may seem, it has a lesson to be learned behind it. Furthermore, is a questions of honesty and integrity for owning up on ones actions. I am a PMO manager for a large multinational mining organisation and would like to sleep easier knowing that our team will homour the code of conduct and professional responsibilities. Sometimes &quot;stupid mistakes&quot; can cost an organisation millions- chances are, mitigation actions can be drawn up sooner if more info. about a problem is known upfront. Just think what would now happen to the &quot;google buzz&quot; test team if they had known about the privacy issues and &quot;bugs&quot; in buzz and not reported it. Bigger picture - consequence such as those sighted in the conclusion of the article can be attributed to environments with low maturity and/or emotional intelligence.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249235]]></guid>
        <dc:creator><![CDATA[Bgovindsamy]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 01:42:35 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: 10 ways to avoid mistakes during project development]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249226]]></link>
        <description><![CDATA[Surely item 2 should be first!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3249226]]></guid>
        <dc:creator><![CDATA[ogils]]></dc:creator>
        <pubDate>Wed, 24 Feb 2010 01:24:52 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: 10 ways to avoid mistakes during project development]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3248632]]></link>
        <description><![CDATA[Checklists are a must.  We all need to recognize we are busy and often interrupted.  Let the checklist be our memory.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-326192-3248632]]></guid>
        <dc:creator><![CDATA[lknox]]></dc:creator>
        <pubDate>Tue, 23 Feb 2010 07:36:08 -0800</pubDate>
    </item>
    </channel>
</rss>

