If you can, work out the high risk activities. You can do this by estimating a percentage probability for them. So one might be 80% (fairly likely) and another 20% (fairly unlikely). Some risks might have a probability p=100%, which means that they would be certain to happen. Then work out the impact. The easiest and fastest way is to do this as a percentage as well. The one with p=80% might have an impact of 90%, which would be virtually a show-stopper. The one with p=20% might have an i=10%, which would mean that the project could continue and you could spend your way out of the problem. Then combine them. The one with p=80% and i=90%, will have a profile of 72%, which makes it dangerous. The other will have a profile of 2%, so that you can forget it. You really need to isolate the ones with a high probability and a high impact. Work out how you will deal with them. Add this contingency planning into your main plan. If it turns out that you don't need it, then fine. If the risk occurs, then you will be able to deal with it smoothly. (This is a very lite version of project risk management. More available on the Internet. I recommend Chapman and Ward's book Project Risk Management.)Add up the total time to do all the sections, add *at least* 50% buffer time, and you have your schedule.
But consider the following. A milestone should benefit the customer. They should get some tangible result at this point. Not a plan or a report, but something real that will have value. An asset. The initial design could be a milestone. The customer could take it away and use it elsewhere if they wanted. So it's a tangible asset. A milestone should benefit the developer. So link the handing over of an asset to the customer with the customer handing over a payment to the developer.Deciding on milestones is up to you and the developers.
One note on payments. I generally link payments to the cost to the developer. So the payment by the customer at each milestone should cover the developer's costs to date. (Not that I say 'to date' rather than 'to reach that milestone'.) By the final milestone, the customer will have covered all the developer's costs. That only leaves the developer's margin, which should be at least 25% of the costs to keep the developer in business. So, by the final milestone, the customer will have paid 80% of the total price. They will pay the remaining 20% at the end of the warranty period or after acceptance testing. So, even if a project fails part way through, the developer's costs will be (almost) covered and the customer will have assets that they can take to a new project and that they have paid a reasonable price for (which will be the cost of producing them).
Regards,
David
____ � The WDVL Discussion List from WDVL.COM � ____
To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED] Send Your Posts To: [EMAIL PROTECTED]
To change subscription settings to the wdvltalk digest version:
http://wdvl.internet.com/WDVL/Forum/#sub
________________ http://www.wdvl.com _______________________
You are currently subscribed to wdvltalk as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
