First thing you need to do is create the Work breakdown Structure (WBS) up till Workpackage level. The WBS describes the end-product you need to deliver as well as the processes needed to deliver it. This will need a number of iterations on discussions with your stakeholders to make sure that everything is included that is required. You need a pretty good idea of what done looks like.
The end-result should be broken down in sufficient detail into the functional components that will add to the capability the product needs to support. Each will be a workpackage.
Next each work package needs to be estimated. Ashes has given some typical methods for getting a valid estimate. As estimating seems to be a problem, I would advise to develop each work package (or lowest level WBS element) into all the tasks required to complete the deliverable (= task definition). Each task is then separately estimated into ideal work hours or days. Meaning that if someone would work uninterrupted on this task it would take him x hours. Again, estimating is done by subject matter experts and/or the people who will perform them.
Don't use single point estimates, but a range (Most likely - Worst Case).
This means that, instead of estimating
a task will take 10 hours, detail the
estimate in the most likely effort of
8 hours and a worst case of, say 14
hours because we don't know technology
XYZ very well and it may be a
piece of cake but when factor X
doesn't match with Y than we have to
reconfigure Z, hence the 14 hours.
How much effort or how long a task
really takes is not deterministic (10
hours) but follows a probability
distribution you have to account for.
Think of your daily commute: does it
take exactly the same amount of time
each day? By taking into account the
worst case, you can work out a margin,
but you manage against the most likely
(because Murphy does not always pays a visit
and to prevent student's
syndrome (take all the time
Note that, if you're not sure yet which technology to use, you will either have to make assumptions or (better) make an estimate for each possibility.
Estimating is best done with a group of people, instead of individually.
Summing all these estimates up will give you the required budget in hours or days for each work package and ultimately for the whole project, and possible alternatives of execution.
Next make your network of all work packages (this is the plan you are going to follow) and schedule the tasks and assign people or profiles to each of them, so you also know the cost estimate and the delivery time.
Perform risk identification (use the WBS!) and add specific risk mitigation tasks where required.
Check out each WBS element for
possible risks and create a risk
response/mitigation plan: these
'actions' of your risk response plan
must be added somewhere, either in a
work package of their own or in the
affected work packages. These tasks
must then be estimated as well.
Make sure these cost items are identified so that you know your contingency budget and how it is applied.
The final schedule is based upon the most likely estimates or any other way of calulating it (eg PERT), but make sure you also calculate some margin, in both time and money. As estimating seems to be a problem, you better argument to take the difference between the most likely (or average, or PERT or whatever ) and the worst case. Since you will manage against the former, that should be ok.
Don't forget to add any material costs, licences, ... to complete your budget.
Hope this makes sense.
A final word: track time!! So that you can use it for the project after this one. Not only to be able to compare with previous realised work packages or tasks (if you track time on this detail), but also to track how well you're doing the estimations. If you notice that you under-estimate by a certain %, you can use that 'evidence' next time as a separate margin or even to adjust the most likely estimates.