September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
I don't think a formula / equation will help.
You can set deadlines based on historical performance to gauge deadlines. The maturity and experience of your team will also factor in how long things will take.
Speak with your team and get their input on how they feel about the deadlines you set. There could be over allocated resources on your team.
Communication and priority setting is key.
Agile methods often avoid emotional "time" estimates and instead use "points". This concept helps many teams calculate a "velocity" that removes some of their estimating biases. Here's a link to the concept (there are many good links on this concept). https://www.sitepoint.com/whats-point-agile-points/
My experience comes from design and engineering projects, so not IT. I am not aware on any formula for what would be an acceptable delay ... mainly because delays are hardly acceptable to any client (internal, external, sponsor, etc). Even when verbally or written accepted, they remain hard to swallow by the affected stakeholder.
In my view, setting deadlines is very much related to the assumptions you made on:
1. preparedness of the whole process involved (do you know exactly the steps and components of the process? does your team know it?)
2. availability of input resources (quantity and quality of data, people, machines, knowledge)
3. performance of the resources (people, machines, automation, knowledge)
4. general risks for the business you are in, as well as specific risks for your operation (do you have an understanding of them, are you prepared with a response, does your sponsor know about the risks and approved the responses?)
So, on setting deadlines look again on your estimates and the assumptions you made in working them. To build in some more realism, you can work the 3 point estimates. For example in engineering, for a certain design activity the PM would consider the same activity performed by 3 people of different performance caliber: the slowest (S), the most common (A), the fastest
(F) and can calculate the average as: either (S+A+F)/3, or (S+4A+F)/6. To know what S, A and F would be, you need to relay on your people and make sure they share the same assumptions in estimates with you.
In addition, be aware what is considered by the industry the norm on either the estimate, as well as "in delay". Nonetheless, you can have an open discussion with your Client (internal or external) about "what is still acceptable for the Client" when it comes the delay, and understand the circumstances that makes the delay still acceptable.
Hope this helps!
What is the root cause of the delays?
Who is setting the deadlines? Is it the person doing the work or a subject matter expert (SME) estimating how long the work will take, or a manager saying when it needs to be finished?
If the people doing the work are estimating how long it will take, you can look at historical data to see if they are consistently off on their estimates. If an SME is estimating the work, you need to look at the skill level of the people doing the work. The SME may be estimating based on an experts ability, and the person doing the work may not be an expert. If the deadlines are being dictated, you need to talk to the person setting the deadlines about options for setting and meeting realistic deadlines.
Are your team members dedicated to their projects, or do you have prioritization issues spanning multiple projects or other work? I have project team members who are also support staff - support always comes first.
Are estimates based on Effort (actual time needed to complete the work) or Duration (the window of time in which the work needs to be performed)? It may take two days for someone to find two hours to complete the work.
You never, never get accurancy in your estimations by definition of estimation. Estimation is the best guess based on availble information and available time to estimate. Take a look to Barry Bohem "Cone of Uncertainty". Beyond that, what I use from years in multiple organizations and no matter the approach (Agile or not) or the life cycle (iterative, waterfall, etc) I use is risk as the indicator to manage delays. Supposse that your organization accpet a risk of 20% for each initiative or for an especific initiative. That is the percentage of time/cost/quality you must take into account to define all your triggers or warnings related to your project.
from a traditional scheduling perspective, you could look into the use of buffer management (an element of critical chain) as a means of externalizing the impacts of schedule uncertainties from individual activities to a chain of activities.
Delay in project completion does not have any formula, but need to be attached to some risks(known / unknown). These risks need to be communicated to stakeholders as per your anticipation/reasoning at the initial stages of the project and need to be continuously assessed, monitored, controlled and managed. I have experiences that stakeholders are reasonable as long as you keep them informed and I believe that it is better to provide a top class solution (ofcourse based on case by case) even though it entails more time. So, don't be afraid of delay in projects. Please remember that estimation by definition means that you may go wrong with timelines. That is why previous PM experiences and stakeholder management are key to successful project delivery(although delayed).
lessons learned and taking inputs from leaders or other project managers who has already worked on similar projects will really help you create a better estimate. always allocate more time , that is approximately 25% extra time from what ever you estimate for completing first 30 % of task/deliverable. once the the project is on track and by this time your team will be equipped for fast tracking and can handle expedited tasks if necessary and manage the timelines .
Continuously improve your estimates over time based on your own historical information until you get shorter delays, but some delays can never be avoided.
I appreciate your suggestions and I will definitely take them into consideration.
The concept of the 3 point estimates is very interesting, we'll have to check whether it could be applicable in our case, considering the diversity of the projects that we handle. I am assuming it is very useful for repetitive tasks that are performed simultaneously by a team.
Have a great day!
Please login or join to reply