# How to estimate a project without understanding the network path?

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.

• Since you wrote, "I don't know the sequence of the task, i.e, predecessor or successor", the answer is, you can't. You must know the network path. Jun 26, 2015 at 12:10
• In addition to the network path, you must also estimate the duration. Work (in hours) is not the same thing as duration. Jun 26, 2015 at 12:12
• Where do you have the estimates from?
– Tob
Jun 27, 2015 at 6:23

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.

• Actually the absolute minimum duration is 280 hours, assuming that they can work completely in parallel and not taking schedule crashing into account.
– Tob
Jun 27, 2015 at 4:00
• @Tobias, I thought that was what I had said, however I have made a minor edit to clarify and reflect what I think you are saying Jun 27, 2015 at 9:18
• sorry, maybe I just read too quickly
– Tob
Jun 27, 2015 at 10:14

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.

• I think you can arrive at an estimate, especially when you estimate in a probabilistic range, for both duration and work without developing its path first. After the path is developed, I'd suspect that would impact the chosen planning values based on resource depletion, constraints, and other variables. Maybe that is what you mean, the chosen planning values. Jun 26, 2015 at 15:06
• I'm confused - you said the opposite in your comment to original question. I stand by my opinion that if you know resource hours but not the sequence of work packages that the planning process is flawed.
– MCW
Jun 26, 2015 at 15:53
• I meant, arrive at a duration and work estimate, not date of completion. Jun 26, 2015 at 15:59
• Aha! yes, of course you are correct - at the work package level. But without the network, you can't identify critical path, and you can achieve only a very low confidence estimate of total project length. I have modified the answer based on this.
– MCW
Jun 26, 2015 at 16:03
• Yes, totally agree! Jun 26, 2015 at 16:09

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.