Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1234»»

New Poll Expand / Collapse
Author
Message
Posted Friday, December 16, 2005 11:33 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Wednesday, September 3, 2014 11:26 PM
Points: 3,214, Visits: 2,336
I believe that the answer to this question lies in your own 'perspective'. Have I ever failed on a project - NO. Have I been a part of projects that have failed - YES. The reason that I have never failed is because I've always learned from failed projects. So if you learn some of the why's then you have not failed.



Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #244935
Posted Friday, December 16, 2005 11:54 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 10:32 AM
Points: 2,905, Visits: 1,825
The CEO in my last place was also the owner of the company and he observed that there is a difference in attitude between the US and the UK.

Failure is seen as something to be deeply ashamed of in the UK.

In the US, he opined that, lack of failure indicated that you weren't ballsy enough and probably hadn't pushed as hard as you should have.

I have worked for American companies and I have to say that the attitude was relentlessly positive. Projects that would fail in the UK are a success when run by an American because long after a British firm will give up and American company will keep plugging away until something is achieved by sheer volume of effort.

Another big difference between the British and Americans is their attitude to a successful person.

I know it is a generalisation but the British will look at a successful person and wonder how to cut that person down to size.

An American will look at a successful person and wonder how to elevate themselves to the same position.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #244938
Posted Friday, December 16, 2005 12:35 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Saturday, January 4, 2014 11:05 PM
Points: 968, Visits: 67
Near the beginning of my career, I worked for a company in Iowa City, Iowa that had another location in Austin, Texas. The management in Iowa City said that the Austin office needed a call tracking application. They also said that I should talk to the Iowa City project managers for specifications because "the folks down there in Austin won't really know how to specify what they need." For real - that's what they said. I was still green enough that I figured "they must know what they're talking about." :os

Anyway, being young and foolish (I'm at least older now), I did what they said. I spent several months developing a very-cool-for-the-time call tracking application for them so that they could take incoming calls, route them to each other, perform common workflow on the calls, integrate with email, etc. We started talking with the people in Austin, and they allocated one person to test the product, and she liked what she saw.

Next step: I was flown down to Austin to install the software (couldn't be done remotely back then) and give training. Two events stick in my mind from the training sessions: the site administrator asking "where did THIS come from?" and a rank-and-file worker stating that "this is a great start, but I don't see how anybody could use it if it didn't do X." I can't remember what X was, but it was something that was an integral part of their call processing that the Iowa folks had decided wasn't important enough to implement at first. Final outcome: after months of development, nobody used the product.

It was not a total loss, though. Two good things came out of it. First, I learned something that is obvious to everyone AFTER you learn it: make sure the REAL users are involved in creating or approving specs. Secondly, the company had an annual internal "open house" where each of the departments would show off their best work. My team (which was one of the most visible) chose to demo my product (!). We gave a 40-minute presentation to all comers. People were duly impressed (of course, none of them knew what "feature X" was, so they couldn't complain that it was missing). However, one person at the end asked a really troublesome question: "how many people are using this system now?" Our answer: "we still have some work to do before we get it widely deployed in Austin."

As far as I know, that work is still waiting to be done. ;^)

Cheers,
Chris



Post #244945
Posted Monday, December 19, 2005 2:02 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, September 13, 2010 6:01 AM
Points: 1, Visits: 16

I have been in the I.T industry for 6 years, but saw at least 3 failed projects (not my fault :cool.

But bad management, no VERY BAD management. Second company I joined had a product. The specs changed each day, (the little piece of paper with hand drawing was the spec). The client "managed" the project scope etc. There were no "set" specs, they would change each time by the client. So while you worked on 1 page, 2 pages would come back for changes bec the client wanted the changes (and the deadline still stayed the same).

We had to work overtime, weekends to make "deadlines"/changes (and the project wasn't even near completion). So after 3 months at the company I and another programmer left. Last time I heard the company went bankrupt..

3rd company I joined managed to get a big contract for a rewrite of an application. They told the client , 1 YEAR. After the year, we were only 17% complete. but management wanted to go by the "book". We had to have 5 layers before you reach the database. Took you about 4 times longer to code 1 page than normal 3 tier development. When we mentioned this to management, they told us to STFU it was promised to client and we must deliver

1 year later...

Now I sit in the almost the same position again . Boss can code a little, so he thinks EVERYTHING is possible. You can design a system that let BUSINESS USERS "code".. without coding, but they can still code . Again NO Specs, each meeting with the boss he adds new "features" (which he sees on the internet).  I can see the red flags already, and I'm already thinking about jumping ship, because I can see only problems (and I'm a very positive person by nature).





Post #245108
Posted Monday, December 19, 2005 11:14 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Wednesday, September 3, 2014 11:26 PM
Points: 3,214, Visits: 2,336
"STFU" ??? Please translate ...



Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #245259
Posted Monday, December 19, 2005 12:18 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Tuesday, December 11, 2012 3:50 PM
Points: 544, Visits: 43

heh

shut the f up

i think the 'f' stands for firetruck

someone get this guy mirc




Post #245291
Posted Monday, December 19, 2005 12:25 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Wednesday, September 3, 2014 11:26 PM
Points: 3,214, Visits: 2,336

Now I see said the blind man ...

My response to STFU is BFD ...

big furry dog ...





Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #245295
Posted Wednesday, December 21, 2005 8:39 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, August 25, 2013 5:36 PM
Points: 267, Visits: 126

Having perused the responses, I find my fingers itching to send my own little opinion.

I live in a different world (non-IT) and have been investigating for a couple of years what exactly is the problem with software development. I knew I didn't have what I needed, but was curious as to why. Books don't have the answers. So I launched into some mini-development projects just to find answers. I didn't care so much whether they failed or were successful, but rather wanted to understand clearly what were the factors in play.

What I think I discovered is a HUGE opportunity. To oversimplify, failure is largely due to lack of preparation or resources (a subset of preparation). It doesn't matter who should have or didn't prepare. Blame is useless. But analysis can be very productive.

Management often does not understand the needs of technical people. Good technology lives in the realm of mind-numbing detail, with no shortcuts. So I see opportunity for management-type people to spend enough time and do enough homework to truly understand techies and speak their language. To fail to do that costs millions. To not understand that it costs millions and not discern the need for thorough, non-glamorous preparation is to identify oneself as unqualified for the position.

Technical people, on the other hand, often underestimate the complexity of what is needed (in my observations). They think that a good design can be derived from a board meeting where domain experts tell them what they need. That's like telling an aeronautical engineer that you need an airplane that can take off, fly, and then land. What kind of mess would you get with that kind of detail? So the developers go merrily off, make something that takes off, flies, and lands. But the user is wholly unimpressed.

This is where scope creep and change requests come from. I would argue that the user, including domain experts, are entirely unable to tell the developers what they need in the same way a pilot can't tell an engineer how to make a plane. The pilot knows when he sees what he wants and has what he wants, but is unable to articulate that in sufficient detail prior to starting work on the plane.

So what's the solution? Tiny, incremental, functioning prototypes. I know the industry mantra is to make prototypes as quickly as possible with no real code behind them. I understand the expense of putting a lot of time there. But being a "domain expert" in my own little world, I can tell you that from the time I designed a screenshot that I thought was "just right" until I really had a screenshot that WAS just right, was anywhere from 10 to 50 revisions average. Reason: you can't tell if it's "just right" until you actually use it in the real environment where it's proposed to live. It's surprising what surfaces that is good or bad about a screenshot when you're actually using it in real life. This means it connects to real data.

This would likely apply more to very complex work processes, not necessarily applicable in every situation. But most of the easy stuff is already done, leaving the more complex processes still to do. So much for my thoughts!!

Sam




Post #245871
Posted Wednesday, December 21, 2005 9:00 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:38 PM
Points: 31,018, Visits: 15,453
Sam,

Interesting thought. I thought my most successful IT group was one where we released a new version (web apps) every Wed, tackling things that could be done in 1 or 2 weeks only. It's similar to a scrum/Agile methodology, but the one week time frames with weekly resets allows tremendous flexibility and the ability to move directions quickly.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #245880
Posted Wednesday, December 21, 2005 9:25 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Yesterday @ 5:58 PM
Points: 634, Visits: 2,206
From all that has been said most fail to apply the Six-P Rule: Proper Planning Prevents P**s Poor Performance. Then there is the mission creep problem.

What needs to happen is you need to plan that this is the core functionality that is needed at x point. An example:


We need to be able to input all the information and print the documents for a adjustable rate and fixed rate mortgage in six months. That is all that needs to be done. But then someone pops up with "We need to import credit reports." The answer to that needs to be "No, that isn't in the current plan. We will see if we can spare a person to work on it, but it is not a priority."

In the above scenario if the answer was yes, (and more than once) then it is likely the project will fail.

We had one vendor cough up a huge program that was slow, balky, needed patching frequently and skipped QA. We used it for 2 years and then found a new vendor that took the approach of saying no. We now have a smaller faster core, with multiple bolt-ons that is upgraded every 6 months on a schedule. We are a beta tester, and 99% of the beta is workable and only needs minor work before going to production. It's a whole different world.

Just my $0.02.




----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.
Post #245891
« Prev Topic | Next Topic »

Add to briefcase «««1234»»

Permissions Expand / Collapse