What do you do when there are many activities that were not planned in your project?

Wagner,

Normally, there is a small contingency to capture and contain these unplanned activities. Resource contingency, Schedule Contingency are looked into etc. However, if there are too many unplanned activities, then there would have been a flaw upstream that have left so many unplanned activities undefined in terms of resource, timescale and schedule.

Too many unplanned activities - Scale them to a Priority broadly defined as Essential ( Must Have), Necessary ( could have), Considerable (nice to have).

Essential - These activities are important, where they could be connected to a Predecessor activity or a Successor activity. If these activites are not included into the project, a potential risk emerges for the project.

Necessary - Activities that can be included into the project, since they have a impact on the deliverables or necessary for success of project.

Considerables - Activities that are nice to have in the project, since they deliver extra benefits or solutions that are an add on OR resulting benefits from doing the project.

Essential activities can be brought into the project at various stages, but mostly through a refined process of Change Requests/ Change management

I always use Barry Bohem`s Code of Uncertainty from the very begining of the estimation process to be aware of the amount of inherent error into each phase of the project life cycle regarding estimation. While it was born for software projects it could be used for each type of initiative. This helps to me to be aware of the amount of things I do not have information at a specific statege. When I got more information new things (activities for example) could happend and those are covered in schedule and cost by the Cone indicators. In our case for those activities we use time elapsed vs time estimated to make the control. For example, when you are at 50% of time estimated taking into account time elapsed then you are in yellow.

I always use Barry Bohem`s Code of Uncertainty from the very begining of the estimation process to be aware of the amount of inherent error into each phase of the project life cycle regarding estimation. While it was born for software projects it could be used for each type of initiative. This helps to me to be aware of the amount of things I do not have information at a specific statege. When I got more information new things (activities for example) could happend and those are covered in schedule and cost by the Cone indicators. In our case for those activities we use time elapsed vs time estimated to make the control. For example, when you are at 50% of time estimated taking into account time elapsed then you are in yellow.

Hi Sergio,

great reply as usual and more or less every time you do answer such a question i do learn something new, that is just amazing!
Never heard about this "Code of uncertainty" before, thanks for that!

Markus

Hi Sergio,

great reply as usual and more or less every time you do answer such a question i do learn something new, that is just amazing!
Never heard about this "Code of uncertainty" before, thanks for that!

Markus