New Poll
-
Wow! If I didn't know better, Steve, I would think you were writing about the company I'm currently with.
-
No.
But all projects will fail.....
Eventually.
Now crayons, they never fail.
But even the mona lisa is falling apart.
As failures in general go its better to have 2 escort you out versus 6 carry you out.
Any day above ground is a good one.
-
There was a software project I was working on that still burns me up to this day. We were asked if in house we could build an e-commerce type catalog system. Basically be able to handle orders for any of the products we had on contract. We as a development team were asked to provide a set of different mock-ups to show we could indeed build a final product:
- Catalog browse
- Catalog search
- Shopping cart
- Checkout
We did all of those things in record time. Demos worked flawlessly. Our estimated cost if we went forward? Probably around $200K including implementing XML feeds from the vendors we had on contract, scaling the application, implementing appropriate levels of security, etc. So they outsourced it. For several million.
Those of us working in that organization saw it as a wake-up call and pushed the check out button. I'm sure they eventually used that as justification for the outsourcing in the first place. In hindsight, as a development team we were extremely naive. We figured if we met the mockups and pulled off a demo, the work was ours. However, our management team was being told by the eventual winners how much more the company could do. The company sold itself well. They pitched expandability, etc.
We never considered selling management on what the capabilities of "framework" were. Had we, it might have been us who built the e-commerce site. That was a big lesson learned. It's not just if it can meet current needs. What might it also do for the organization in the future?
K. Brian Kelley
@kbriankelley -
Did you ask them if they wre going to 'kiss you first?'
-
There are still plenty of software houses that don't care about quality, scalability, etc. I worked for one in the not-distant past. You can attempt to take leadership positions and provide guidance and information on a host of issues and potential issues, but the bottom line is if management doesn't want to hear about it, you won't be heard.
You can explain the "right way" to do things all day long, but if your bosses are interested only in "just getting it done" ("we'll go back and fix it later" syndrome) you end up just making software that barely limps along and requires patch after patch after patch.
-
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.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
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.
-
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
-
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). -
"STFU" ??? Please translate ...
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
heh
shut the f up
i think the 'f' stands for firetruck
someone get this guy mirc
-
Now I see said the blind man ...
My response to STFU is BFD ...
big furry dog ...
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
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
-
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: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com -
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.
Viewing 15 posts - 16 through 30 (of 33 total)
You must be logged in to reply to this topic. Login to reply