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?
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.
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... Saving Changes...
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.
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.
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/
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! Saving Changes...
Richard TummersTechnology Manager| C.A.T.Calgary, Alberta, Canada
Jun 13, 2018 9:23 AM
Replying to Richard Tummers
...
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/
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/). Saving Changes...
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/
Thank you, Richard!
This really helps!
I will definitely look into it and try to put it in practice.
Have a nice day. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Great responses thus far with a mixed bag of options. Ultimately, estimates are estimates. There are various techniques to improve estimates; 3-point, Boehn's, historical data, etc., and you could also add in some contingency time based on complexity or uncertainty in requirements.
Potentially, some of the reasoning behind late deliveries could be a lack of understanding of either what is needed or what it takes to deliver on what is needed.
Be adaptive. Use lessons learned, or some other type of retrospective, to honestly look at where adjustments can be made. No sense in simply doing the same thing each time and expecting a different result. Saving Changes...
To achieve the target set by customer external/internal, we need to see below factors
Number of resources required
Beefing up the skilled numbers if required to meet the target,
Their skills,
Skilled numbers(Sr/Jr, experience etc)
Buffer resources in case of unpleasant events,
Doing estimations(of resources, hours and days) including buffer based on experience
Capacity planning based on resource availability(consider planned/unplanned leaves), velocity, productive/ not productive hrs, required days etc
Actions based on lessons learnt
Proper project management - Risk, communications, dependencies, timely alerts, timely team meetings, issues
After doing all this at the end there are still chances you could miss the deadline but definitely there will be less damage. :(
A simple but effective approach i follow is to plan a buffer before each important milestone or commitment given to an external person or organization. This will support you improve on-time delivery rate!
You may use historical data to determine the buffer size.
...
1 reply by Richard Tummers
Jul 26, 2018 1:00 PM
Richard Tummers
...
I find a small forms of "buffering" can greatly help stress levels. As examples:
I rarely set a major deadline or milestone to be the same day as a stakeholder meeting. Instead, I virtually always choose a day or two after (where the discussion can focus on last minute concerns). Or, I chose a day or two before (where the discussion can discuss results using real go-live data, experiences, and stories). I usually feel bad stress when people have the option of answering "I should meet today's deadline as I plan to get that done before midnight in my timezone if I get no unexpected problems".
I also carefully consider moving published deadlines and milestones by 1 day to be either at the end of a month, or the beginning of a month. When the deadline is July 31, urgency seems to build through the whole month of July. This can cause good or bad stress with the team and stakeholders. I started doing this when the doctor told me the due date of our first child was September 30. We announced the due date to everyone as October 1. I feel this resulted in better conversations for the whole month of September!
Saving Changes...
Richard TummersTechnology Manager| C.A.T.Calgary, Alberta, Canada
Jul 26, 2018 7:36 AM
Replying to Visswanathan KKN
...
A simple but effective approach i follow is to plan a buffer before each important milestone or commitment given to an external person or organization. This will support you improve on-time delivery rate!
You may use historical data to determine the buffer size.
I find a small forms of "buffering" can greatly help stress levels. As examples:
I rarely set a major deadline or milestone to be the same day as a stakeholder meeting. Instead, I virtually always choose a day or two after (where the discussion can focus on last minute concerns). Or, I chose a day or two before (where the discussion can discuss results using real go-live data, experiences, and stories). I usually feel bad stress when people have the option of answering "I should meet today's deadline as I plan to get that done before midnight in my timezone if I get no unexpected problems".
I also carefully consider moving published deadlines and milestones by 1 day to be either at the end of a month, or the beginning of a month. When the deadline is July 31, urgency seems to build through the whole month of July. This can cause good or bad stress with the team and stakeholders. I started doing this when the doctor told me the due date of our first child was September 30. We announced the due date to everyone as October 1. I feel this resulted in better conversations for the whole month of September! Saving Changes...
RAJESH K LProject Manager, PMP| Bharat Electronics, Bengaluru, IndiaBengaluru, Karnataka, India
