How to estimate delivery date with unidentified tasks

Question

Given a software project which is complete when all of its deliverables are delivered, in which each deliverable has sub-deliverables, in which each sub-deliverable has multiple tasks assigned to it

It is possible that not all tasks have been identified at the start of the project, and that some sub-deliverables require many more tasks to be completed during the course of the project before the sub-deliverable is complete.

How does a project manager accurately account for these unknown tasks in the beginning, to provide a more accurate approximation of project completion date?

Answer 1

By estimating iteratively.

Look into the cone of uncertainty.

At the start of the project, the amount of uncertainty is high, and the cone wide. Thus, your estimate would be 'between 2 and 6 months'.

Partway through, the uncertainty lessens and the cone thins. One month in, the cone becomes '3 to 4 months'. 3 months (12 weeks) in, it becomes '13-14 weeks'.

Answer 2

To add to @Sarov's proper answer, when your uncertainty is high at the beginning of the proposed project, you need to build in that risk in your commitment you're making to your client. Using Sarov's example, if your estimate (an estimate should always be a range as Sarov suggests) is between two and six months, you need to identify your "most likely" within that range and then choose your commitment somewhere in that range that represents the degree or risk appetite you have. If you have high confidence in the work, you can choose a value closer to the two months; however, if it's a first of its kind for you and you have high uncertainty, then your value should be closer to the six months. The challenge here is trying to stay competitive for the work, and then if you win at the higher value, to not allow something called student syndrome or Parkinson's Law to take over where you end up using all the time you have allotted.

Answer 3

Plans are worthless but planning is everything. An original estimate presented at the starting point of a project, will for sure evolve as we keep adding more info to our knowledge base. And everyone should be prepared to quickly adapt to this newly added information.

An estimate is a communication that should be alive in an agile context.

It's unrealistic to expect to finish something at the estimated time, when the estimation is being done at the beginning of the project.

One tool that can help you keep on track is Giving clear goals to the epics: If an epic has a clear goal, everything we would be potentially adding needs to go through the goal filter

A quick example:

1. The stakeholders bring new "useful feature" and wants to add to the list visible in the admin user page a checkbox on each user that marks them as a favorite user.
2. A developer realizes that due to a technical constraint the users can't have more than one role in the product.

Say your goal is

A. "Do the user administration page".

When 1 happens, it is not clear if this is or not part of the feature, and you might end up with the never ending features, a page can always have tweaks and fixes.

When 2 happens, you might need to analyze if the not having more than one role is acceptable.

Instead say, your goal is

B. "Have a User Admin page that lets the superUser handle the minimum roles necessary to handle the page with the three actors we have".

When 1 happens, it gets crossed out right away. And what happens if the client really wants that? Well it should be in another epic, for sure. They can then decide if they want it or not.

When 2 happens, you will already have the team thinking if goal filters the problem or not before you get to hear the problem, and taking faster decisions to move forward (such as asking what to do with that, already knowing that it won't fit this epic's goal)