Risk and Assumptions

  • Mia-- Thanks for disagreeing without being disagreeable.

  • Chris (1/22/2009)


    Mia-- Thanks for disagreeing without being disagreeable.

    It was a calculated risk. 😀

    Mia

    I have come to the conclusion that the top man has one principle responsibility: to provide an atmosphere in which creative mavericks can do useful work.
    -- David M. Ogilvy

  • I have to disagree with the comment about not involving users in usability design. I've seen both ends of that spectrum, and the one that involved users a lot was a much better piece of software than the one that didn't. And I'm not talking about one project vs one project, I'm talking about all the projects at one business vs all the projects at another.

    - 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

  • On the subject of risk coming from not knowing what you're doing, I'll have to go with "it depends" on that one.

    Yes, not knowing what you're doing definitely increases risk. If you try to drive to work, and you don't know how the brakes work, you're more likely to end up injured/dead than to end up safely at work.

    On the other hand, there just simply are no valid ways to know some things that can tremendously increase risk. Not knowing a small meteor is about to land where you're standing right now definitely increases your risk, but there is simply no valid way to know that's going to happen.

    Also, as mentioned, there's no way to learn new things without taking some risks. You just have to do your best to mitigate the risk and maximize the gain, but the only way you'll ever expand your horizons in any way, is to take some amount of risk.

    The worst risks, however, generally come from people who think they know what they're doing, but really don't.

    Honestly, I like to periodically do things that are crazy risky, just to push myself. If what you're doing is free-style cliff climbing, no matter how much you know about it, no matter how much experience you've got at it, you are still at risk every time you practice that skill. I think that's a necessary part of life - taking risks just for the gain of knowing that you faced a risk, openly, knowingly, and went, "sometimes, you just have to say, 'what the @$%^'".

    - 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

  • As an adrenaline junkie (skydiving, motorcycles, competition shooting, angel investor in startup companies, etc), I just want to say that: "What you don't know WILL hurt you." Anybody who says different is selling something.

    😛

  • Apparently, I need to back up to state that, by definition, applying usability principles means including multiple doses of user testing. User testing involves creating user scenarious and then watching or filming guinea pigs (sometimes colleagues you catch walking down the hall) and, ultimately, end users using the application to determine whether it is easily able to be used as intended. Such testing is a very important and under-utilized process. If usability principles are applied when creating the interface, then when user testing is correctly applied, the likely result would be limited, if any, modifications to the original interface.

    However, user testing is not the same thing as asking the end user to provide input on designing the interface when gathering requirements. IT is supposed to provide the expertise in that department, not the end user. Again, save cosmetic issues, interface design should not be up for discussion. Any feedback comes from user testing, not the opinions/wishes of non-expert end users (if you don't ask, then usability issues are unlikely to even come up for discussion when gathering requirements).

    With due respect, I stand behind my original recommendation.

    I recommend "Don't Make Me Think!" by Steve Krug as a starting point for anybody interested in pursuing this subject further.

  • With that clarification, I agree with you. Thought you meant something other than what you intended.

    - 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

  • What you don't know will hurt you. - David Reed.

    Question:

    How do I know what I don't know without taking the risk and taking on the project? Maybe you just can't be afraid of being hurt.

    🙂

  • skjoldtc (1/22/2009)


    What you don't know will hurt you. - David Reed.

    Question:

    How do I know what I don't know without taking the risk and taking on the project? Maybe you just can't be afraid of being hurt.

    🙂

    skjoldtc, the point of the maxim is to plan and prepare as much as possible. Be honest with yourself about what you don't know... and then GO FIND OUT!

    If you don't know that your 'chute is packed properly: Repack!!

    If you don't know that your new brake pads have been worn in properly: try stopping at more reasonable speeds before you twist it up to 200mph!!!

    Take precautions. Take the risk. Risk == Fun. There's nothing like the view from outside the airplane at 15,000 feet. Or the road rush at 200mph. Do your homework (learn as much as you can) before you leap.

  • Obviously its important to try to get the user requirement specs for an application as close to "right" as possible before going live. But no matter how smart you are, how experienced you are, or how big your team is, there are always new requirements that come up after going live in production. And this is a good thing. And it is an inevitable thing too. And it needs to be expected (even welcomed) and planned for before ever going live.

    The problem is that, whether it's due to overly-complicated toolsets or overly-burdened IT shops (or both), it often takes a long time to get these new requirements/features into the applications. This leads to a lot of user frustration and dissatisfaction and the idea that building new systems is too "risky". If the systems did what people need them to do (over time as well as on Day 1) then they would not be perceived as so "risky".

    If this is all not accounted for in the selection of the toolsets and methodologies which will be used by end users and developers, chances are you will run into a bottleneck situation which will not be good for anyone.

    Of course, this is just one aspect of IT "risk", but it is a significant one.

  • "Obviously its important to try to get the user requirement specs for an application as close to "right" as possible before going live."

    I agree with this statement entirely...with the exception of the first word--"obviously".

    My experience is anecdotal, but my sense in the IT realm is that concerted effort is not typically made to getting requirements "as close to right as possible". My experience is that this step is typically half-hearted at best (nobody likes writing/reviewing/discussing functionals), resulting in significant cost and time overruns. No, putting more emphasis on requirements gathering will not eliminate risk, but doing so would undoubtedly reduce risk (and increase efficiencies) tremendously.

  • agile > waterfall

    when done correctly for your environment.

    Yes I realise that many people still aren't convinced, and that's fine, but this is my opinion and a lot of the concepts make sense when you think about it.

    I have only been involved in development for a couple of years now and so I only have my limited scope to work with, but I have been involved with a sibling company who insists on using the waterfall approach, whereas in this company we use a much more agile approach (adjusted to suit our business enviroment) and I have found that our software tends to come out faster and with more customer/user satisfaction.

    The risk is also minimised as any problems are (typically) identified early before copious amounts of money have been spent on code and other resources.

    At the end of the day, as other have said, research; don't believe a word I have said, or anyone else for that matter (although some people have made valid points).

    Jump online and look at the various ways in which you can implement the SDLC and choose a model that suits the way you and your business work and the amount of money your business has to spend on development.

    A little investment of time and effort now will save you bucketloads of cash later.

  • "Risk comes from not knowing what you're doing." I think that's true and that's part of the reason we'd had issues in our financial markets over the last couple of years.

    Madoff had been running his scheme long before the seeds of the current crisis were sown and he got through downturns before eg 1987 crash. Of course, the severity of the current crisis prevented him from continuing his otherwise the revelations would have been delayed further.

    I believe that risk is all around us and we encounter many potentially high risk situations on a daily basis. Driving a car is a risky business. Even if you have absolute control over your vehicle you cannot control the behaviour of other road users. The optimal strategy in this situation is to drive defensively, make sure you have as much space around you as possible, ensure your car is mechanically tip top AND on top of this hope for the best, namely that you arrive and survive.

    The financial crisis was really caused by lack of confidence in the financial system and long established financial institutions going bankrupt did not help to restore confidence in the system. Add in the bailout, which few seem to have understood, particularly those responsible for administering it and it's easy to see why confidence broke down.

    As far as IT projects are concerned, there have been so many methodologies and technique devised, which IMHO make it easy to lose your way. In my experience, which admittedly goes back over 30 years, most developments run into problems because the developers don't understand the users business and more importantly, where it is likely to be when the project is finished. This is not totally ITs fault, especially when everyone uses a computer at home and work for creating and manipulating data. There is often a lack of realisation that how the developers expect an application to be used and how the user actually uses it is rarely identical.

    Lack of common communication between IT and the business makes it hard to manage user expectations, but the better you are at doing this the more successful the project will be and the happier everyone will be as a result.

    Howard

  • I actually believe it was just the opposite... I think it was severe over confidence... why else would the prices on houses have gone so high? Gas prices more than doubled in just a couple of short years based on the over confidence known as "speculation". And the insanely over confident banks and other lending agencies actually thought that people that couldn't afford a mortgage could actually pay back a sub-prime loan with a "limit". It's that same gross over confidence that made people think that nearly doubling the value in the stock market in only 10 years would actually last.

    People and companies are gonna have to go back to the old ways... they're gonna have to actually earn their money for a while.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (1/27/2009)


    I actually believe it was just the opposite... I think it was severe over confidence... why else would the prices on houses have gone so high? Gas prices more than doubled in just a couple of short years based on the over confidence known as "speculation". And the insanely over confident banks and other lending agencies actually thought that people that couldn't afford a mortgage could actually pay back a sub-prime loan with a "limit". It's that same gross over confidence that made people think that nearly doubling the value in the stock market in only 10 years would actually last.

    People and companies are gonna have to go back to the old ways... they're gonna have to actually earn their money for a while.

    That's called "unconscious incompetence", Jeff. The root cause remains "not knowing what you're doing". Too many people @$&%ing around in the market (myself included, though I spent no weekends @ Bernie's) without really understanding the complete irrationality that is the current Brownian market.

    Personally, I think that the market bubble (like the real estate bubble) was fueled by people "betting" with money that wasn't their own. Buying so-called securities (or real property) with credit is a recipe for... what we have now.

    But we're going to make it better by pouring Hope™ and Change™ and Lotsa Dough™ down the swirly bowl so that people can go back to doing the same thing all over again. Joy to the whirled.

    Fortunately, I remain optimistic that if I divide what I thought I owned by zero enough, it'll come out better than playing the slots in Lost Wages, Nevada. Eventually. For large values of zero.

    :hehe:

Viewing 15 posts - 16 through 30 (of 31 total)

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