|
jhwurmbach wrote: ghle wrote: let me prototype your house, give me a sign-off, then we'll start for real.
You did not ever work with an architect to build your house, right?
Actually, I did. I looked at "his" designs. The plans were not acceptable and I learned after 3 revisions that the architect did not have the vision I needed. So I paid him for his designs and went somewhere else. I did NOT pay for the house. The builder didn't dig the foundation. (It turns out most of his designs were modifications of someone else's work - i.e., house plans.)
Time, Quality and Cost - the customer can pick any two.
Regarding the prostrate surgery - the surgeon goes into the surgery with a clear definition on what he is to do, how to do it, and scenarios and tests that indicate additional procedures. It is not an unknown, neither the initial nor the additional procedures. And there is likely a known time-to-completion for each process, which helps schedule the operating room and all associated services.
BTW - Software R&D along with hardware R&D, which appears to be your project, definitely creates different time considerations.
OT - My father, chief of surgery before he retired, was told by a neighboring auto mechanic, "What we do is very similar, diagnosing mechanical problems then fixing the problem."
Humoring the man, dad said "I guess you're right. Have you ever changed a valve in an engine?"
"Of course, many times" was the expected response.
"Ever do it with the engine running?" my father then asked.
End of that conversation! 
![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
Gary
|
|
|
|
|
I break down and cry. Plain and simple.. Maybe I should become an alive organ donor. I have to die sometime anyhow
Your point? Hire a lawyer?
|
|
|
|
|
For starters, the specification that goes with the project proposal to be signed by the customer must reflect 100% what the customer wants at that time.
This should be the Step 1 of a complex process that is software development.
From this point, changing specs are no problem to the development process because they imply a re-specification and a new time line.
This is so simple, why to we (I include myself on this) keep messing up?
My short answer is :"Because we don't review the specs..."
We keep accepting new functionalities to the apps without even telling the customer they will take time to deploy.
After a dozen "small" functionalities we have a week of extra development and a customer still thinking everything will be done on the same schedule.
Now, or the initially defined schedule is perfect (it never is) or the "fear factor" we put on the time line is enough to handle this slip... none usually combine enough time and the schedule gets out of control...
Then you try to explain the customer you had to do all that extra work but it's too late, they just don't care about it, it passed too much time since they have ask you to do it and you actually said you would do it without any comments...
What I mean is, there must be a specification,this specification must be updated as there are changes to it and this update must be transparent to the customer, "he" must know about the development changes so there's no surprise when "he" expects to receive the product.
|
|
|
|
|
AlexCode wrote: What I mean is, there must be a specification,this specification must be updated as there are changes to it and this update must be transparent to the customer,
That is what I am saying with other wordes "iterative", "agile".
Deep, detailed, multi-volume specifications are enormously costly in itself. They tend to be taken as if being etched in stone and brought down from mount sinai.
Maybe there are segemtns where this works, but as a whole you are only forcing the customers to try to stuff *everything* in there. Up to a level where no one can handle the complexity - and thats where projects start to fail.
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"
|
|
|
|
|
jhwurmbach wrote: Deep, detailed, multi-volume specifications are enormously costly in itself.
But necessary... you need something to base your development costs.
No customer will embrace an ongoing project without even having an initial budget for it.
Like I said, we need a well documented book with all the specifications and we must update it whenever there are changes to it. This is the only way we have to protect ourselves from customers saying the slip fault is entirely ours.
|
|
|
|
|
AlexCode wrote: jhwurmbach wrote:
Deep, detailed, multi-volume specifications are enormously costly in itself.
AlexCode wrote: But necessary... you need something to base your development costs.[...]we need a well documented book with all the specifications and we must update it whenever there are changes to it.
You can't update it. You can possibly write an secification-change-request. and delivert it to your specification manager. This manager will then let the specification-change-request-steering-comitee decide upon your request.
See what I mean? A deep, detailed specification is unchangeably fixed. It is an valuable asset to both sides, developer company and customer. Sometimes, both use it like a weapon against the other side...
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"
|
|
|
|
|
Yep, that's what I mean too.
The structure you must present the change request to depends on how big the customer's organization is, but the basic idea is there.
You need to present that change-request proposal that is based on their changes demand... so they must approve that time-line changes or the changes won't be made at all...
It makes no sense that a customer can ask whatever he wants and you must do it if it wasn't specified on the initial specs.
New specs, new definition, new time-line...
I know this isn't linear, and the customer relationship usually requires more flexibility than this but it helps if we preserve the basics in mind when time comes to discuss the project issues.
|
|
|
|
|
Often the customer isn't clear what they need and come up with a list of specs that, if fully defined, would generate a project of several man-years without really delivering quickly what the customer wants. if a list of requirements is seen as a wish list which can then be processed by the project manager into a list of those items which need to be done first (along with essential dependencies) and the team can get started on those then a working product can be produced (and corrected if necessary) earlier in the project life cycle. Obviously there are issues with budgeting such an approach and a lot more details to be worked out with the approach that I don't have the space or time to go into here but I find that my projects are up and running faster with a lot of the wish list dross excluded. Want the customer really wants (whether they know it or not) is the essential functionality that lets them do their job as easily as possible. Everything else is icing on the cake.
OK, you guessed it, I'm a ScrumMaster. See the Control Chaos Web Site for more details on SCRUM.
Life in the fast lane is only fun if you live in a country with no speed limits.
|
|
|
|
|
SCRUM is just a new hype and absolutely not the silver bullet! It is nothing more than a box of project management rules which were valid and known years before SCRUM was born.
In my opinion it is not nessesary to give those rules a name (for example SCRUM - or XP or Agile or whatever). Also I think it is not the best idea to live 100% under these rules.
Just pick the parts you need to manage your development departmant. So you will get you own project management rules and you can call it "Ultra-Scrum" or "PX - Programming Extremist" or whatever.
|
|
|
|
|
AlexCode wrote: I believe it's a lack of a full & deep
I thought you were about to say "full & deep sleep!" 
Marc
|
|
|
|
|
That too! 
Another bad think project managers usually do is to force after hours when they're not necessary.
Sure the project is on delay but I only believe in "after hours" development when the release is to be made on the next day... maximum in 2 days, never more.
If a PM exposes a team to a long non stopping effort the bad side effects are greater that the profit we get from it...
|
|
|
|
|
AlexCode wrote: Another bad think project managers usually do is to force after hours when they're not necessary.
I had a manager who once recommended I put in 70-80 hour work weeks (there were no upcoming deadlines, he just thought this is what an engineer should normally put in). I wrote a letter to the president threatening to sue for labor law violations. Mr. Manager became my best friend after that. 
Marc
|
|
|
|
|
Nice boss you add there...
It's easy to look good on schedule like that...
Sadly enough there's a lot like that and after a short while project start slipping too.
|
|
|
|
|
AlexCode wrote: I believe it's a lack of a full & deep book of specifications. From this we get all sort of problems... nothing good can be expected from a bad
Not much good has come from over written, inflexible specifications either.
I shuddered when I read "book of specifications."
regards,
Paul Watson
Ireland & South Africa
Fernando A. Gomez F. wrote: At least he achieved immortality for a few years.
|
|
|
|
|
Sorry, just want to start asking what you mean by "shuddered", I don't know what that means, sorry.
by
Paul Watson wrote: inflexible specifications either
I never meant to defend fixed specs, I just defend that every peace of it must be documented for the good sake of the development process.
I even defend that when things get big and a lot of money is on the table the meetings should be recorded.
This is the only way you can defend yourself when a customer blame you for not delivering the "goods" in time. Not delivering in time in large-scale project mean that you must pay a fee (usually a big and nasty one) for each day of delay so you better document yourself when time comes to defend yourself.
|
|
|
|
|
AlexCode wrote: Sorry, just want to start asking what you mean by "shuddered", I don't know what that means, sorry.
To shiver convulsively. If you saw a dead person in the street, you would shudder.
regards,
Paul Watson
Ireland & South Africa
Fernando A. Gomez F. wrote: At least he achieved immortality for a few years.
|
|
|
|
|
I'm lucky I get anything done with the amount of other work I have to think about!
You don't have to be mad to code, but it helps.
|
|
|
|
|
I know that sometimes people just want us to do something for them, but they don't realize that we need very precise instructions. I often get the feeling that the users don't take the time to thorougly think about it. I like ot write code and help people and all that, but when people don't respect my time and my work, I'm very angry.
Something like this fell on me just last week. It went something like.
"Hey, could you do something for me? Parse this file and drop all lines which are like this."
And I was there, like,
"Sure, I'll just write some regex, and in 30 minutes tops it'll be done and compiled."
I did that, and after half a day, they added,
"actually, I only want the last few lines, the ones after the line which starts like this"
So, I thought to myself,
"in 2 minutes, add a boolean variable, another regex, and it'll be done"
Eventually, after a couple days,
"I need the info from that line you had to skip, so will you please add 3 columns with some data you'll get from a crystal ball." Actually, that last one, I had to figure out by myself, asked the question, and got the answer "Yes, I'll need that too". After thought, I should have done it secretly, wait for them to realise they needed it, and then deliver it.
I hope they don't ask me for a web report next. 
I should start making people realize what I must be given to properly do my work.
"Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra
|
|
|
|
|
Donkey Master wrote: I should start making people realize what I must be given to properly do my work.
Sure you must make them realize that you need proper information.
But that is what separates a software developer from a programming monkey, I think.
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"
|
|
|
|
|
#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 --
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
