Project Management Central

Please login or join to subscribe to this thread

Topics: Organizational Project Management, Schedule Management, Scheduling
What is an average delay in Project Management? Based on data/ personal experience can you give me a percentage?
Network:33

I am having some trouble with meeting deadlines and I was wondering if there is some kind of formula/ equation that I could use in order to set the deadlines more accurately and reduce delays.

All of the projects that I manage involve teams of 5-15 colleagues and in most cases an external supplier.

What are the factors you take into consideration when setting deadlines?

Have a great day!
Francesca
Sort By:
Page: 1 2 next>
Network:1535



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.
...
1 reply by Francesca Comnea Mihai
Jun 15, 2018 6:41 AM
Francesca Comnea Mihai
...
Thank you, Drake.

Your suggestions make perfect sense, I am sure it will get better with time.

Most of the times the project team is consulted concerning the deadline, but so far on most of the projects we couldn't avoid delays and your explication is probably right.

Have a great day!
Network:199



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/
...
3 replies by Francesca Comnea Mihai and Richard Tummers
Jun 15, 2018 6:44 AM
Francesca Comnea Mihai
...
Thanks, Richard!

This is a pretty interesting perspective, eventhough I am having some trouble understanding how to put this in practice.
Can your share a personal experience, please?

Have a nice day!
Jun 15, 2018 11:55 PM
Richard Tummers
...
Sure! This long reply describes a software development team I started leading in the middle of a 10 year, multi-million dollar business process change project enabled by software tools. The team had developed a bad relationship with the client, based largely on late delivery of promised enhancements and bug fixes. Cancelling this critical project was explored, but was not an option. The team was not familiar with agile methods.

I started by taking several days to organize the existing backlog of work in a manner where we could review the majority of it with the client, a half dozen programmers, a business analyst, and a few other active stakeholders. I ended writing a few dozen lines of code that automatically printed each item in the backlog on a single sheet of paper, with a title in 2 inch tall letters that could be seen from anywhere in the room. Other important notes were in a 12 point font (the size our local senior citizen newspaper uses).

I had never seen a "scrum master" work, so the meeting took more than 8 hours. I scheduled 6 hours on day 1 to develop understanding, and 2+ hours in the middle of day 2 to make decisions. That gave everyone time to sleep and think more deeply before making decisions on day 2.

On day 1, we reviewed and discussed the backlog of work. Each item was taped to the wall. It was a very interactive experience, and EVERYONE stood up, moved paper from wall to wall, added new sheets of paper, and wrote extra notes in pencil.

When an item was understood, the client used one colour of marker to set the importance of the work at high, medium, or low. The programmers used a different colour of marker to write an estimate of the effort required for each item using difficulty points. Easy things we believed only required changes to a few lines of code were estimated at 1 point. Other things we estimated at 5, 10, 20, or more points. We had so little credibility with the clients, that we jointly agreed to temporarily halt work on any functions that would take more than a week to code and test.

Most people had trouble understanding points. So, we loosely said that a point was "about an hour". However, we always called them points, and not hours.

On day 2, the client and I set most of the work plan for the next few weeks. The team helped slightly adjust the workload based on the best fit with each programmers skills and experience.

After a few weeks of successful delivery, I started to develop calculations relating our point estimates to working hours. Some agile methods call this "velocity" (see https://www.scruminc.com/velocity/). I included the extra project planning information about holidays, company meetings, training, illness, and other activities that take up large known amounts of time. Even though people on the team loosely thought of a point as about an hour, our team came surprisingly close to taking just over 3 hours to complete 1 point of work...

After not much more than a month, we had enough confidence to start work on some of the more difficult functions. We improved communication. The client began to clearly understand which difficult functions were more expensive than the value they would deliver. The project team began to understand which important functions required different ways of working to deliver in a more cost effective manner.

For us, it turned out that a large part of our problems were getting a proper description and understanding of the function required. As the project progressed, the programmers AND the client BOTH kept improving their abilities to describing the work. Some agile methods call this learning how to write a good "user story" (see https://www.scruminc.com/independent-user-stories/).
Jun 22, 2018 3:07 AM
Francesca Comnea Mihai
...
Thank you, Richard!

This really helps!

I will definitely look into it and try to put it in practice.

Have a nice day.
Network:816



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!

Alina
...
1 reply by Francesca Comnea Mihai
Jun 15, 2018 6:21 AM
Francesca Comnea Mihai
...
Thank you very much for your response!

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.

Thanks again!
Have a great day!
Francesca
Network:773



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.
...
1 reply by Francesca Comnea Mihai
Jun 15, 2018 6:32 AM
Francesca Comnea Mihai
...
Thank you, Aaron!

Deadlines are usually set by the Project Manager and/ or CDO. Estimates are some of the time based on the input provided by the people doing the work, especially the IT issues.

We also have project team members who are also support staff, and yes, support always comes first...
Network:1638



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.
Network:1013



Francesca -

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.

Kiron
Network:548



Hi,
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).

Amit
Network:589



Francesca,

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 .
Network:13462



Continuously improve your estimates over time based on your own historical information until you get shorter delays, but some delays can never be avoided.
Network:33

Jun 13, 2018 10:27 AM
Replying to Alina Florea
...
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!

Alina
Thank you very much for your response!

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.

Thanks again!
Have a great day!
Francesca
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

Laurie got offended that I used the word "puke." But to me, that's what her dinner tasted like.

- Jack Handey

ADVERTISEMENT

Sponsors