Freelancing...
-
Don't be so Naive. Things don't work like that in the real world
Kind Regards, Gary
My Website || My Blog || My Articles
cykophysh39 wrote:
Things don't work like that in the real world
Actually, they do in some small cases. We have had customers lay everything out in massive detail, we have had customers give us general requirements. In any case, we always have a "response" report which lays out method and details as we understand it. In the case of the former, it is just a reformat of the customer's list and may only add VV&A if the customer didn't include it. The customer will also generate a response, either accepting, or making changes (striking documentation). Yes they can always come back and say, "we wanted this back ..." but the fact that the negotiation process is formal and on paper allows fewer mishaps. Fewer, not avoiding them, just fewer. It doesn't work for everyone, but we have to work off of formal requirements and planning, and usually fixed price. But as I said, that is the industry requirement. However, risk is laid out too in the response. Anywhere there is R&D there is a creative process in which discoveries are made, or technology advanced, that is not as easy to judge. Thus risk is associated with any R&D based change and identified specifically such that there is no question as to what items constitute the most risk to project delivery and if a partial delivery is even possible.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I work as a freelance programmer for a couple of years. Things went rather good until recently - I have some "recurring" customers, etc...The trouble is that now I receive "job requests" asking for a "flat price" for projects they barely describe. I cannot give a "flat price" and a time estimation without knowing how much work involves the project, so I answer by asking for specifications and technical details. In almost every case, there is no answer...The same if I specify my hourly rate - these guys seem to take into consideration only "flat prices" per project... Does anyone of you have such an experience? How do you handle these "requests"? Did anyone of you tried to hire a freelancer? If yes, do you ask him/her to specify quotes and time estimation without providing technical specs? Any advice?...Thanks...
Refer them to Rent-a-Coder; they'll be back, specs in hand.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Refer them to Rent-a-Coder; they'll be back, specs in hand.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
And Christian can give some good references on the subject :-D
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
I work as a freelance programmer for a couple of years. Things went rather good until recently - I have some "recurring" customers, etc...The trouble is that now I receive "job requests" asking for a "flat price" for projects they barely describe. I cannot give a "flat price" and a time estimation without knowing how much work involves the project, so I answer by asking for specifications and technical details. In almost every case, there is no answer...The same if I specify my hourly rate - these guys seem to take into consideration only "flat prices" per project... Does anyone of you have such an experience? How do you handle these "requests"? Did anyone of you tried to hire a freelancer? If yes, do you ask him/her to specify quotes and time estimation without providing technical specs? Any advice?...Thanks...
Offer them a flat price for requirements gaathering.
-
I work as a freelance programmer for a couple of years. Things went rather good until recently - I have some "recurring" customers, etc...The trouble is that now I receive "job requests" asking for a "flat price" for projects they barely describe. I cannot give a "flat price" and a time estimation without knowing how much work involves the project, so I answer by asking for specifications and technical details. In almost every case, there is no answer...The same if I specify my hourly rate - these guys seem to take into consideration only "flat prices" per project... Does anyone of you have such an experience? How do you handle these "requests"? Did anyone of you tried to hire a freelancer? If yes, do you ask him/her to specify quotes and time estimation without providing technical specs? Any advice?...Thanks...
I did several fixed-fee projects but have since switched to hourly-billing. From my experience, I can say that, for every project, I always doubled my private initial estimate to give a price, and it always ended half or less of what I should have charged. So if I thought it would take 10, I would charge for 20 and it would take at least 40. Customers don't know what they want, don't have time to review your requirement documents, don't have time to read your spec... and midway through the project want something they initially said they would not need ever. Now that I am billing by the hour, I am on my way to buying myself a Porsche (still very very far, though! :)) Seriously, hourly-billing is the way to go. You might lose a few customers that are not willing to take the risk, but you will be happier. If they don't totally agree, you could share the risk with your customer. If the project goes over 25% over the original estimate, you absorb half of the hourly rate (so you charge half). Just be sure to adjust the estimate as requirements change.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
cykophysh39 wrote:
Things don't work like that in the real world
Actually, they do in some small cases. We have had customers lay everything out in massive detail, we have had customers give us general requirements. In any case, we always have a "response" report which lays out method and details as we understand it. In the case of the former, it is just a reformat of the customer's list and may only add VV&A if the customer didn't include it. The customer will also generate a response, either accepting, or making changes (striking documentation). Yes they can always come back and say, "we wanted this back ..." but the fact that the negotiation process is formal and on paper allows fewer mishaps. Fewer, not avoiding them, just fewer. It doesn't work for everyone, but we have to work off of formal requirements and planning, and usually fixed price. But as I said, that is the industry requirement. However, risk is laid out too in the response. Anywhere there is R&D there is a creative process in which discoveries are made, or technology advanced, that is not as easy to judge. Thus risk is associated with any R&D based change and identified specifically such that there is no question as to what items constitute the most risk to project delivery and if a partial delivery is even possible.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
VV&A
Verification, Validation, and Auditing??
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
-
El Corazon wrote:
VV&A
Verification, Validation, and Auditing??
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
dan neely wrote:
and Auditing??
sure! ;) actually it all depends on who you ask. Sometimes I feel like the Accreditation/Authentication step should also include Auditing/aggrandizement/agglomeration/assumption and even occasionally augur. Luckily I have yet to pull out Tarot cards as part of the verification step. Close, but not quite there yet. ;)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Dave, Jaiprakash, I have a very bitter experience with customers requiring this "extra stuff"...just when I was sure we made a "deal", everything changed, and I had to re-negotiate...eventually I spent more time negotiating than working for his project :| And please take into consideration that analysing the requirements comprises work for which I seldom get any payment... :|
My point exactly! :-D
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Don't be so Naive. Things don't work like that in the real world
Kind Regards, Gary
My Website || My Blog || My Articles
I myself has done this way... was successful many times !!!
Regards, Jaiprakash M Bankolli jaiprakash.bankolli@gmail.com My Blog Suggestions for me
-
cykophysh39 wrote:
Things don't work like that in the real world
Actually, they do in some small cases. We have had customers lay everything out in massive detail, we have had customers give us general requirements. In any case, we always have a "response" report which lays out method and details as we understand it. In the case of the former, it is just a reformat of the customer's list and may only add VV&A if the customer didn't include it. The customer will also generate a response, either accepting, or making changes (striking documentation). Yes they can always come back and say, "we wanted this back ..." but the fact that the negotiation process is formal and on paper allows fewer mishaps. Fewer, not avoiding them, just fewer. It doesn't work for everyone, but we have to work off of formal requirements and planning, and usually fixed price. But as I said, that is the industry requirement. However, risk is laid out too in the response. Anywhere there is R&D there is a creative process in which discoveries are made, or technology advanced, that is not as easy to judge. Thus risk is associated with any R&D based change and identified specifically such that there is no question as to what items constitute the most risk to project delivery and if a partial delivery is even possible.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)