How to estimate a project without understanding the network path?

Question

I am trying to estimate for a project, with each resource work for some hours and i have total hours for project. How can derive the exact completion date ?

Eg.
Resource 1 - 25 tasks - 240 hrs
Resource 2 - 20 tasks - 210 hrs
Resource 3 - 15 tasks - 280 hrs

So each day requires 8 hours working, and excluding weekends.

How can i derive the date of completion of the project with this data.

NOTE: I don't know the sequence of the task, i.e, predecessor or successor.

Answer 1

The absolute minimum duration for the project is 280 hours = 7 weeks at 40 hours per week, assuming that the three resources all work in parallel with no gaps between tasks for any of them, tasks can't overlap, and that they can't pick up each others' work.

The maximum time could be as much as 730 hours (the sum of 240 + 210 + 280 hours) = 18.25 weeks, and even that is subject to the following assumptions:

• The three resources can only work on their own tasks
• There is no parallel working
• Tasks run on without gaps between them
• Each resource can only work on one task at a time

I would expect that each of the above models is flawed, but without knowing a great deal more about the project, it is not possible to give a definitive answer to your question, which is about finding the exact completion date.

If you want to declare a target date, then you may wish to choose any date between these limits, set a range of possible dates on either side of it to recognise the level of uncertainty in the plan, and qualify it with as many assumptions as you can come up with. You should validate these assumptions, which will allow you to refine the target completion date and reduce the level of uncertainty in the estimate.

However, there is an argument that states that the only true date is the one that you see in the rear view mirror after the project has been completed.

Answer 2

I'm not sure how you can know the duration of a work package without knowing what the predecessors for the work package are. I suspect that you need to back up and restart planning.

First identify the work packages/deliverables.
Then when you know the work packages, determine the dependencies. A must come before B. B and E must come before F, but C&D can come after F. Probably easiest to work backwards - Z is the final product; I can't produce Z without W and X. X requires B,C, F, & Q. W requires B, D, G, M and P. and so on.

Then, and only then, consider the duration and work hours.

Update: @DavidEspina points out that for most projects you can estimate the project duration without knowledge of path. You can use reference estimates of other projects. In that case the information you supply about resource hours is not relevant to the estimation process.

Fundamentally though if you don't know the sequence of the activities, then you do not know which activities can take place in parallel. I suppose you could estimate that the true project completion date is somewhere between the longest work package (if all work packages were performed in parallel with no dependencies & no resource conflicts) and the sum of the duration of all work packages (if all packages are linear and have only one precedent and one successor). But the question leaves me with the impression that you don't even have the work packages defined, just some resource hours to tasks.

Re-reading the question for the third time, it might be possible to build an estimate based on the most constrained resource - Resource 1 is required for 25 tasks. Let's assume that resource 1 is 80% dedicated to our project (20% overhead). That probably puts a lower bound on the project completion date - it is probable that most (or all) of Resource 1's work will occur on the critical path. That gives you an estimate of project completion date. It is likely that there are some tasks where Resource 1 does not work, but without knowledge of work packages, I can't tell if these tasks would occur on the critical path.

Answer 3

You can't derive the date of completion in a perfect way. But you can do the following:

• Best case duration: 280h assuming full parallelization and not potting additional resources on the project.
• Worst case duration: 730h assuming no floating time + an amount for drawbacks or risks

What is your idea or feeling on the real project duration? Guess if you don't have former data, experience, or experts. That's you most likely duration.

Apply three point estimation.

Nevertheless, due to the really uncertain assumptions, the estimation is quite vague.