Let's assume that we are starting a project, but have no previous experience of budgeting a software project.
What should the guys who will work on that project do to make a decent budget planing?
Should every movement be considered on this process? I meant coding the structure and data access, creation of restful services, creating the database structure and architecture, and so on by every movement.
How should the time planning process go on?
In order to define the budget and the timeline of a project, the first thing to know is the scope of the project. Which means: you need to know what's not in the project.
Starting with the scope, you can roughly break the project down in main tasks, and get a first estimate of the planning and budget of the project.
Just keep in mind (and remind the stakeholders) that it's rough and need to be refined. Don't let such a rough estimate be written down on a contract!
To estimate, the first thing is to get a time estimate, which is rather a question of experience, in my opinion. Given an amount of work and knowing the complexity of the task, a PM has to be able to estimate the time needed to accomplish the task.
After that, cost is pretty easy to calculate. The cost depends of the consumed resources: the cost of the team is obviously the main cost. And then the tools they will use (computers, software, etc), the services they will consume (power, internet access, phone, etc). Maybe you will need to work with contractors, providers. And so on...
The cost is of course the sum of all costs for the time of the project.
The answer you're probably looking for is give large ranges of estimates (plus or minus 50-100% or more) and say: this is what we think. Because you don't know.
Planning is probably best done top-down, starting with vague items (eg. feature X) and broken down into smaller items.
If you don't know your requirements well, or if they may change, and if you're not building something static like a compiler, I would suggest giving agile/scrum/xp/etc. a whirl. It allows you to estimate remaining time to work given actual past team performance, and you only need to wait one sprint (~2 weeks) to get real data on how you're doing.
PMI suggests a lot of great estimating techniques that you can probably make use of:
A budget is harder to estimate. I don't have much experience with it, so I'm going to duck out on that part. Earned Value is generally terrible (from my perspective of software development), albeit tracking expected vs. actual costs to-date is very useful.
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 allotted)).
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.
