|
#2 and #4 go together quite often, where the client doesnt understand what is needed, gives the task, and later changes the specs...alot...and often, as they refine what the actually want. Plus, of course, it sometimes just so happens that you are given the task, and the timeframe to fit into, and you're just not asked...and all that, along with being given additional tasks to finish at the same time.
So yeah, I vote for most of the options.
"impossible" is just an opinion.
|
|
|
|
|
Agreed, I'd have voted for most of the options too. All the mentioned reasons happen most of the time except for #3 that happens less often.
|
|
|
|
|
As a self-employed web-developer I think this is the most common reason that causes delay. I have had this problem so many times, when all of sudden client don't like something they said they loved it before.
Anyone else agree??
- Stop thinking in terms of limitations and start thinking in terms of possibilities -
|
|
|
|
|
Typically, in small companies, the development team are subject to the following turbulent turmoils:
1) Sales team has astronomical commitments to the client regarding the features and the date of promise.
2) The clients, who seem to make the most of the hapless state of affairs of the small vendor who might not have stringent processes would try to extort as many things as possible at the same price.
The result is that poor development fraternity would reel under acute stress and pressure.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Agree,
I work for small company. 2 weeks ago my boss called a meeting to 'happily' inform us the feature he sold to a client, which are none existent and will take us 3X more time than the promised date. Go Figure... 
/* I can C */
// or !C
Yusuf
|
|
|
|
|
I could not agree more. 
Yes, everything on that list is relevant and often more than 3 or 4 options apply at any given time, but changing specs is (particularly at the last minute) not easy or fun. People always seem to think that it'll be a small nuisance you can overcome in 30 min.  Not realising that you might have to change the way the whole app works just to accommodate that "little change".
-- For a moment, nothing happened. Then, after a second or so, nothing continued to happen --
|
|
|
|
|
Parth wrote: all of sudden client don't like something they said they loved it before.
As a self-employed web-developer, isn't that the best you can get? Lots and lots of hours to bill?
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
I certainly agree that changing specs is one of the biggest problems. What I do is to write down those specs, tell my client what it costs, when it will be done, and then do the job. If the client changes their mind about the specs, I write the new specs down and call that version 2 ... I don't start implementing any new stuff until version 1 is done.
When the client suddenly changes his/her mind, then it is a whole new project.
Ask not whether it is useful. Ask what it is useful for.
|
|
|
|
|
This is why agile development is so magical.
|
|
|
|
|
JasonCordes wrote: This is why agile development is so magical.
Thats also why in most cases it is so mythical
codito ergo sum
|
|
|
|
|
This is why agile development is so magical.
Thats also why in most cases it is so mythical.
Only if you work for Ogres, Cyclopians, Trolls, and Orcs.
If your customers buy into it, it works fantastically.
|
|
|
|
|
I don't work with Ogres anymore
They take the word deadline a little to serious.
codito ergo sum
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
