Accept Failure

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 721105

    Comments posted to this topic are about the item Accept Failure

  • Michael Lysons

    SSCertifiable

    Points: 6478

    Spot on, Steve.

    I tried to type something more eloquent, but failed, so this'll have to do 😀

  • cengland0

    SSCertifiable

    Points: 6102

    I thought I made an error once but after thorough research, I realized I was mistaken.

  • IceDread

    SSCertifiable

    Points: 5020

    Working agile, following scrum, I find helps overview the state of the projects very well.

    This gives management and the people involved in the project a very clear view of the status of the project, amongst other things.

  • call.copse

    SSCoach

    Points: 17246

    I would certainly say that as a developer I will do almost anything to avoid failure - I just simply do not accept failure for projects I am working on - there is always a way around things. Perhaps that is indicative of an overly domatic mindset on my part. I can honestly say though that where a project I have been involved with has been abandoned it has been due to either financial problems with the client or due to the expected market not materialising.

  • phegedusich

    Ten Centuries

    Points: 1367

    Projects have two main success indicators: Does the end product do what the client wants it to do? Did the project come in under budget?

    In order to satisfy the second indicator, you have to build in time to recover from failures, not to mention fulfill the statutory, regulatory, and business rules that govern the development environment. Unfortunately, the "I want it yesterday" mindset of most clients and their failure to understand internal IT requirements for proper configuration, documentation and testing makes this a rare event.

  • cengland0

    SSCertifiable

    Points: 6102

    phegedusich (2/22/2012)


    Does the end product do what the client wants it to do?

    I've struggled with this many times. The clients give you requirements, you build it exactly as stated in the requirements but it turns out to not meet the client's needs. Then you have scope creep. They change the requirements while you're building it but the budget and timeline doesn't change.

    So, this is where it's beneficial for the developer to know a little about the business. While building the end product, the developer can find better solutions than what was initially requested in the requirements. It's best to bring those up to the client and incorporate them right away. If you don't, the client will not be happy and will eventually ask for that modification in the future. The budget dollars may already be gone and it's more efficient to put it in the beginning than after the project is over.

  • Dizzy Desi

    Ten Centuries

    Points: 1031

    I'm sorry to say that you've nailed my management's style to a "T". There are no failures allowed, only changes of direction and/or scope.

    Needless to say, the higher profile projects that management gets involved in end up being over budget by 2 or 3 times the original (we're talking millions of dollars, not just a few hundred or a few thousand).

    I'm just glad to fly below the radar most of the time, and stick with the smaller projects that are not so heavily man-handled!

  • jshahan

    SSCarpal Tunnel

    Points: 4622

    true failure should come from failing to learn from the mistakes...

    My working definition of failure for years was that no one fails until they quit trying. But what if the effort is fruitless/futile and needs to be acknowledged as a mistake?

    I'm experiencing a pardigm shift..

    Thanks, Steve.

  • GSquared

    SSC Guru

    Points: 260824

    A very interesting observation on the human mind/spirit is that we can almost all accept that there's room for improvement, but can't accept that this means there are flaws.

    It's easy to get someone (including yourself) to accept that there's more to learn. It's really hard to get most (including ourselves) to accept that this means we're ignorant.

    That's not an "always" thing. It's a "usually" thing.

    Even where we can accept that we're ignorant, flawed, et al, we usually have to deal with that having a more negative connotation and emotional impact than with the more positive version.

    Applies to what you're talking about on this editorial just as much as to any other aspect of life.

    Imagine if training in our professions were marketed as "you're incompetent and ignorant if you don't take our classes" vs "take your skills to the next level and advance your career". They both really say the same thing, but one is more likely to get the company offering the training lynched while the other is likely to get a positive response.

    Same for views on projects. "We completed the project, but there are some improvements we'd like to incorporate in our next refactor", vs "It's buggy". "We tested some approaches and found some needed improvements" vs "Everything we've done so far is flawed".

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Question Guy

    SSCommitted

    Points: 1934

    Pretty crazy how a DBA or developer can single-handedly cause or prevent a project to fail.(note that I didn't say succeed...always need help to succeed). I could have saved a project if I would have put in 40 hours of data conversion time to replace tons of manual work. Because I wasn't allowed to, a 9 month product sales project failed.

    I guess that's what happens when the business unit fails to contact IT ahead of time for support or suggestions about their business processes.

  • Rod at work

    SSC-Dedicated

    Points: 33413

    I admit to being one of those people who is intolerant of failure on my own part. It isn't a good trait, but there it is.

    However, I want to add that it isn't always us who have a problem with failure. I definitely think that management has a lot to do with it. I've worked at places where whatever project we're working on, it must work the first time. There was no tolerance at all, of failure. That type of management is probably what led me to be how I am today. (My current management is more tolerant of failure, learning from it, and going on, so I'm not talking about my current employer.)

    Kindest Regards, Rod Connect with me on LinkedIn.

  • TravisDBA

    SSCoach

    Points: 15780

    Question Guy (2/22/2012)


    Pretty crazy how a DBA or developer can single-handedly cause or prevent a project to fail.(note that I didn't say succeed...always need help to succeed). I could have saved a project if I would have put in 40 hours of data conversion time to replace tons of manual work. Because I wasn't allowed to, a 9 month product sales project failed.

    I guess that's what happens when the business unit fails to contact IT ahead of time for support or suggestions about their business processes.

    Yep, I feel your pain. Sometimes, a manager just needs a fall guy when he, or his people don't communicate effectively in the first place. Seen this many times before. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • David.Poole

    SSC Guru

    Points: 75396

    There are so many reasons why project fail. Two people have a discussion, both think they have reached a common understanding and then prove conclusively that they don't.

    Stretch that out over a large project and there are failure points from the business sponsor right down to the developer.

    My experience is that if an IT project starts stretching into double-digit months then failure becomes probable. Staff churn means that the original business drivers have changed or been negated.

    I've seen situations where team dynamics lead to project failure. No-ones fault as such, just some teams work and other don't for no tangible reason. Any follower of football will understand what I'm getting at.

  • bwillsie-842793

    Ten Centuries

    Points: 1359

    Sometimes unexpected success can be more demoralizing than failure. I lost all desire to develop many years ago when I wrote a 200+ line Dibol program that worked perfectly with no changes. I stared at the results and program for about twenty minutes.

    As it slowly sank in that I would probably never reach perfection again I lost all desire to write another program.

    Fortunately now that I work with SQL Server I am assured that I will never be faced with that sort of incident again.

    I somehow manage to make mistakes in the simplest of queries, and am thus always able to look forward to a chance at redemption...

Viewing 15 posts - 1 through 15 (of 39 total)

You must be logged in to reply to this topic. Login to reply