[mclean]

It's all fun and beautiful with 4 hours tasks until you get system, where you need 1-2 weeks for every task to get in context. In posts like this i allways miss some practical advice, how to brake those large tasks into small ones.

[jdlshore]

That comes with experience. It's nearly impossible to teach because the right way to break large tasks into small ones depends on the task. It can always be done, though, because the act of programming itself involves breaking large things into small things, then smaller things, then smaller, ..., then individual lines of code.

[danenania]

Yes, but then there's also the issue that by the time you've analyzed and broken down a large project enough to accurately estimate it, you've also done half the work of planning the system. This doesn't work so well when estimates are unpaid and project approval is far from guaranteed.

[prirun]

My solution to this has been to work a project in two phases. This is for 6-9 month projects. The first phase is billed hourly, to develop the project requirements and milestones. In this phase, I'd break things down as much as possible into the number of days I thought tasks would take and develop a very detailed plan. The client never saw this plan; it was for me to develop the schedule. I'd also keep notes of any potential "gotchas" that came to mind. Ideally, this detailed plan has things broken down into 1-3 day-sized bites. If I think something will be easy, I use 1 day. If I think probably 1 day, I'd put 2. If I think I might run into trouble, I'd put 3 days.

Now go back and look at the gotcha list. What can be done to eliminate these contingencies? Maybe you need to do some investigating or experimenting right now, before doing the schedule, to eliminate the uncertainty (and get paid for this under the hourly contract). If you can't eliminate the uncertainty, you have to keep it as part of the schedule, as an assumption: "Assumes the X library will be available by <date>". This assumption list is crucial, because if someone else doesn't meet their deadline, it lets you off the hook and you can make a schedule adjustment.

When you present the project schedule, have milestones with deliverables at reasonable intervals, like 4-8 weeks, and take payment for each one. This has lots of advantages:

- if the client scraps the project (often happens in big companies), you've been paid for your work.

- if you miss a deliverable, you will know early that there is a problem with your schedule. It's better to tell a client early that there is a problem and make adjustments rather than try to make it up and act like everything's fine

- if you _really_ miss deliverables, the client has time to can your ass and get someone else to do the work

- when you know you have to actually turn something over to a client to prove that you have met a milestone, it's a powerful motivation to stick to the schedule and not get distracted too much.

So, hourly consulting part first, then fixed part. If a client wouldn't agree to the hourly part to develop the schedule, I probably would pass on the project.