How Do You Handle Risk?
newbie says : Hopefully a simple questions for you guys.
newbie
ross_valusoft says : Hi,
Risk of what? Risk of not being paid? Risk of bidding too low?
Ross
newbie says :
ross_valusoft>Hi,
Risk of what? Risk of not being paid? Risk of bidding too low?
Ross
Hello Ross,
Well perhaps both.
newbie
ross_valusoft says :
newbie>Hello Ross,
Well perhaps both.
newbie
OK. Risk involves threat/loss and likelihood of that threat/loss. If the likelihood of being hit by lightning is very, very low, you should not become paranoid about it, even though the loss of life is as big a loss that you want to face.
So for software projects, that presumably you are bidding on and then going to write, the threats are generally:
1. - not able to complete (technical)
2. - not able to complete (timing and or resources)
3. - not able to complete (too low a bid)
Starting with 3. If you bid too low, you may go bankrupt or be sued by the buyer, or... Best not to have that happen. how? Well do your homework. The "devil is in the detail". Discuss the requirements ad nauseum, get it clear. Write a project brief (if the client hasn't) and get the client to sign off on it. It should list the assumptions that you have made and the constraints that apply, eg you are a single programmer. Break the project down into clearly identifiable components and cost each individually. Don't forget to price the too and fro discussions with the client, travel time etc, all of which steal from your coding time. I use an Excel spreadsheet for this. It also has an addon for a risk multiplier. The client never sees it, but I use it every day to record progress and monitor my timing overs and unders. Helps estimates for future projects also.
Now 2. Heavily related to the spreadsheet and analysis in 3 above. No one can code 28 hours a day, so do not offer an impossible deadline. If the client does not like it, let him find someone else to sue.
Lastly 1. Well that should be very clear. Don't promise something that you cannot deliver. The losses on one technically failed project can wipe out the gains on 5 successful ones.
So that handles low bids. Now the risk of not getting paid...no silver bullet here.
My personal experience has served me reasonably well. I can count on one hand the number of clients that have turned bad. Unfortunately, one of them was a person in an elected office in US law enforcement and he had paid a 25% deposit. But all educations cost money. In the discussion phase I soon get a feel for the client (except for this police commissioner). If I am concerned about getting paid or the project is more than a week of coding, I might request progress payments and or deposit. Staged payments against milestones is also a good method. If the client is not happy with this, walk away. It is a two sided coin. Staged payments can mean that the client gets to see/feel/test progress along the way. I encourage changes based upon these samples provided the client understands that s/he pays for these. This is usually spelled out in the client briefing document.
And as a final comment, I suspect that the rentacoder site was established as much as a means of introducing buyers and coders as it was to act as an independent umpire for disputes, although I have read somewhere that buyers appear to be favoured in that process. But I stand to be corrected on that opinion.
Hope that helps you.
Ross
newbie says : Thanks Ross.
Can I get a copy of your spreadsheet?
newbie
ross_valusoft says :
newbie>Thanks Ross.
Can I get a copy of your spreadsheet?
newbie
Sure, but remember that I wrote it for my use.
Send me an email and I will send it to yours.
Ross
valusoft
AT
optushome
DOT
com
DOT
au
bas says : So, actually it is about handling risk on Rentacoder jobs was not that clear to me :)
I guess having read about sites like that (elance.com e.g.) that the quality of the requirements is also very important. How would you assess that before you take on a job?
Bas
ross_valusoft says :
bas>So, actually it is about handling risk on Rentacoder jobs was not that clear to me :)
I guess having read about sites like that (elance.com e.g.) that the quality of the requirements is also very important. How would you assess that before you take on a job?
Bas
Bas,
I replied to newbie's question without Rentacoder as the focus. Used them as an example later, but I apply the same philosophy to all potential clients and their jobs.
Quality of the requirements? Somewhere I mentioned the client briefing documentation. If the client is not skilled at expressing the detail, I work with him to put it in words and explain the consequences. It is a partnership process....amazing what comes out during discussions. As I said "the devil is in the detail".
Ross
bas says : Hi Ross,
Ok i see. Does the customer pay for this time to document / specify? A lot of (smaller) companies see this as a part that should be swift and cheap. It "doesn't create a real system".
Cheers
Bas
ross_valusoft says :
bas>Hi Ross,
Ok i see. Does the customer pay for this time to document / specify? A lot of (smaller) companies see this as a part that should be swift and cheap. It "doesn't create a real system".
Cheers
Bas
Hahaha, "swift and cheap"...so we are back to the iron triangle...pick two and fail to deliver on the third
Seriously, if I am invited to bid on a job, I am not going to do so without knowing what I have to bid on. If the client, no matter what size, has not or will not describe what is needed, I certainly am not going to waste my time (money) preparing a bid. OK, I may not win on the bid, but at least we have both put time and effort into communicating the needs of the project.
The company does not have the skills or resources to do it themselves, so they buy help. Why would they sabotage the project by not wanting to cooperate in defining what they need? Well, ...to answer my own question on your behalf, it might be because they expect to change the project along the way. That is ok also, we can build a means of doing that into the bid...including the costs of doing so. I have done this many times before.
As for your statement that this process "doesn't create a real system", well I disagree. Many times, the client is so close to his business that he fails to see the forest from the trees. Talking his needs through and answering the "I do not know your business, but why do you do that instead of this?" type questions sometimes leads to a business reengineering activity.
Enough from me..
alijopa says : mybe? ok onswer ===>
clifford.lobo says : Hi There,
I liked the topic, but is there something that you want to share, i did not see the reason for creating this topic wiithout any description :confused: Lets face it Business is risk and handling risk well means you are a better businessman.
Just my two cents.
Clifford.
