2

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?

  • Who is going to develop the software? An external vendor? – Stephan Apr 4 '11 at 17:46
  • @stephan no. the guys who work at the company. they have full access to accounting and any other stuff. so, viewing what the company could provide is no problem for them. but, estimating the time is real problem here. – tugberk Apr 4 '11 at 18:43
1

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.

  • @Traroth thanks for the response. as you can see, I have written a comment on the @ashes999's post which indicates my start-up plan. but I have no idea how to start the budgeting. I know that first, I need to get a hold of a decent plan which I think I have the prototype of my plan as above. But as we are the actual workers of the firm (not the guys who are hired out side of the firm) so we won't make any offer. nevertheless, we need to budget the project by thinking 'How much would we offer to a company, if we were building this project for another company?'. – tugberk Apr 4 '11 at 18:58
  • @Traroth my actual qu. is, how to start the budgeting after planning? I mean, should we create a hourly fee for ourselves? for example, 'ok, I have been writing code for 3 hours in a row, let's add $ 300 to the budget of our project? and also, I will order a big pizza now. so add $20 for that as well.' kind of budgeting? – tugberk Apr 4 '11 at 19:00
  • Ok, I will edit my answer. – Alexis Dufrenoy Apr 4 '11 at 19:10
  • @Traroth that'd be a nicest thing which happens to me today. thanks ! – tugberk Apr 4 '11 at 19:13
  • @Traroth thanks for the update. you have explained it very deeply and detailedly. – tugberk Apr 4 '11 at 19:22
4

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:

  • Estimating based on similar projects (if possible)
  • Estimating based on similar products/pieces built in different projects
  • Three-point estimating (weighted average of best-case, worst-case, and average case)
  • Top-down and bottom-up estimating (yes, both)

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.

  • @ashes999 thanks for the answer. I have been thinking to start planning by dividing the project into scopes. first Creating database structure, second implementing the data access layers (repository patterns maybe), third creating the service layers (accessing the data with data access layers and process the need), forth implementing restful services, fifth admin control panels and the last creating the end-user interface. that's my goal here. of course, this main divisions will be divided into their own small categories. do you think I am on the right track here? do you suggest anything more? – tugberk Apr 4 '11 at 18:52
  • @tugberk it's really hard to say without knowing more about your project. You're the best person to judge that. Personally, I prefer (heavily) an Agile approach, where you implement functionality piecemeal. Read up on it and try it out, it's great for most software projects. Each slice of work would have data-access, process, restful services, etc. in it. On the other hand, you do need to plan your architecture first. – ashes999 Apr 4 '11 at 19:02
  • @ashes999 we plan our database architecture on very unprofessional way (I am embarrassed but with word document or excel doc :S) I am not proud of it but it worked so good so far. but (again) I am feeling that it is the wrong way. where do you think we could also plan the architecture besides the database? honestly, (and by feeling embarrassed again) I am no experience and knowledge on agile. I know that some firms are offering solution for that (e.g. telerik's TeamPulse) but don't how to make a use of it efficiently. – tugberk Apr 4 '11 at 19:08
  • @tugberk if it's working for you, stick with it and don't change it unless you're 100% sure that changing process is the right move. Word docs are great; I like Google docs because they're online and collaborative. Just use those and you should be fine. For agile, just google and read about it... – ashes999 Apr 4 '11 at 19:12
  • @ashes999 I am really curious how the guys on Microsoft or Orchale does that. do you think they use pen and paper for that? :) asking this just for curiosity :) – tugberk Apr 4 '11 at 19:17
2

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.

  • wow. thanks sir. that is really helpful. I need to read it several times to embed it in my head. I have couple of questions : can you more detailedly describe this sentence if you don't mind Don't use single point estimates, but a range (Most likely - Worst Case) and can you give me an example for this sentence (again, if you don't mind) Perform risk identification (use the WBS!) and add specific risk mitigation tasks where required – tugberk Apr 4 '11 at 20:46
  • I updated my answer. Hope it clarifies things. – Stephan Apr 5 '11 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.