19
Hat tip to Nvoigt, Nvogel & D. Espina - all good answers, with particular emphasis on D. Espina's "sometimes, knowing one of your team is overly optimistic, you simply add your own margins to their input."
I'll just add one more frame to the question - this is a problem in risk management. The core, fundamental responsibility of the PM is to ...
15
In Scrum the team aims to complete the sprint goal by the end of the sprint. It shouldn't be necessary to estimate day-to-day deadlines since the delivery date is always the end of the sprint. I suggest you could stop trying to lead, stop estimating and allow the team to self-manage.
A team of three people is quite small however, and one problem may be just ...
13
I won't say that it is all about communication, but I think a large portion of the problem you see can be contributed to communications that could be improved.
I work in the same field, and I've seen this behavior from many clients in different industries. What took me a long time to understand was that the way I initially present estimates can have a huge ...
10
The short answer is never give a fixed time estimate, always give a range. And then clearly document this in emails or the project plan (writing).
Long Answer:
Fifty some off years of software development has proven fairly conclusively that estimating an entire project, before any work is done, has a success rate of around 20% or less (based on 80% of IT ...
10
@DavidEspina has it right - I'd like to add a few thoughts
This question illustrates one of the reasons tool recommendations are out of scope - CodeGnome's law says you need to decide how to solve the problem before you look for a tool. You haven't yet defined your problem, so no tool can help; tools are more likely to obfuscate the problem by providing ...
9
Your first course of action should be to secure some legal counsel and get their opinion. Asking a message board for legal advice is only marginally better than doing the same for medical advice... at least in your case you only stand to lose money.
That being said, unfortunately this kind of thing is not uncommon. Customers change their minds all the time, ...
9
TL;DR
Targets and estimates are two different things. You're confusing the two, and setting your team up for failure.
Targets vs. Estimates
A target is something you assign to your team, such as "I want this set of tasks done in a month." Management targets are fine so far as they go, but they rarely provide a means to get there. For the actual ...
9
You asked in terms of scrum, so that is how I'll answer. However, there are a number of red flags in your question that lead me to believe you aren't actually doing scrum (and I am far from a scrum purist).
The scrum answer would be:
as PO, you are responsible for the product backlog and priorities, not for process improvement. If you see an issue, you ...
8
When projects and project managers are out of sync, this is an issue at the organizational level. The organization needs to resolve this problem if it chooses to advance in its project management maturity level. That said, it is quite common. Usually, you see this question from the PM point of view, who is trying to ensure its matrixed resources are ...
8
I've always heard (and experienced) it as "Adding more developers to a late project will make it later."
Every new developer requires ramp-up time to be familiarized with the project's architecture, domain, etc. This requires time not only of the new developer, but of a mentor as well. So, your initial velocity will be slowed down. Eventually, though, it (...
8
Notwithstanding your approach and whether you are performing it properly, research the affects of planning fallacies. A planning fallacy is a specific form of Optimism Bias, where we have a tendency of under estimating adverse variables that could impact our performance and, therefore, we predict far favorable results than what is most likely. The bias ...
7
While Joel's answer is good, the reality we face in this business is we have to make commitments, we have to price our proposal with a price, not a range of possible prices.
Estimates should always be a range; however, you must also provide a target, something within that range. And then on top of this, the business may dictate another target...a target ...
7
It sounds like the idea you're concerned about is a rather over-simplified version of the point raised by Fred Brooks in the (rightly) famous essay The Mythical Man-Month. What Brooks pointed out is that you cannot just treat developer man-months as an infinitely elastic resource -- so doubling the number of developers does not halve delivery time.
There ...
7
I'm sorry, but you are trying to solve the wrong problem. Your team isn't delivering much because your management has no expectations from them to do otherwise.
There is a saying in my country that literally translated means "As you teach them so you have them". Management taught this team that nothing happens if they don't deliver much, taught ...
6
There are so many classic issues contained in this approach it is hard to know the best place to start! Firstly I will say this, an Agile approach may suit you better because of the way it handles functional requirements and technical debt (bugs and issues) however I personally have no direct experience with that model. I'm sure someone will come along and ...
6
Issue Log & Risk Registry. (hat tip to @David Espina, without whose answer I would have missed this).
You're responsible for your project(s). Anything that you can solve relative to those projects, you're obliged to solve. These are examples of things you cannot solve, because they are artifacts of dysfunctional organizational process assets.
Things ...
6
Your story suggests three issues you are facing: 1) project management maturity, 2) an understanding of schedule variability, and 3) human performance factors and biases.
You describe a work environment that has very little project management processes and capability well defined. You describe a lack of planning processes, a lack of risk management ...
6
Joel Spolsky once wrote: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/
The mythical perfect estimator, who exists only in your imagination, always gets every estimate exactly right. ...
A typical bad estimator has velocities all over the map....
Most estimators get the scale wrong but the relative estimates right. Everything takes ...
5
So, there are a few things important to note.
#1 - Assumptions - You assume one functionality takes 3-4 days to implement. Has this been confirmed with your team? Some tasks might be shorter (or even longer) depending on the work being done. One of the first things you should do is get with you team and get rough estimates (is this 1 hour, 1 day, 2 days) ...
5
There is a difference between estimates and planning values and I find most either ignore or confuse the two...probably the latter. Work effort is probabilistic and a proper estimate should reflect that and be provided as a range of possible results. For example, an estimate to build a wall might be six to 15 days, most likely nine. If you built that wall ...
5
Basically if anything does not go according to plan you are screwed. The problem is that you promised to deliver fixed features (scope) for a fixed budget (resources) before a fixed deadline (schedule).
Scope, resources and schedule define what is called the iron triangle of software development. The idea is that if you change one side of the triangle, the ...
5
Product is currently in beta stage and never been public, only client
team and the team of testers have access to this.
How often is the client checking in? Do you have regular reviews? You want the feedback loop short and actionable.
The requirements are very much agile and I'm keeping hard to keep everything persistent during sprints and day to ...
5
I'd like add one more option on the table. In many cases estimation isn't really necessary. Situations when it can be useful:
You need to sync with other teams which depend on you
You need to predict the budget and decide if the project (or a feature) is worth starting
In any case, if you estimate there has to be some decision made based on the estimates. ...
4
There is no tool or technique that will guarantee you will come in on time and within budget. Work is probabilistic. If you need more certainty, such as you don't have the funds to pay for overruns, then your only option is to bid a lot of fat. Bid in the 80th or 90th percentile of your estimate for both time and money.
You won't win the work but, if you ...
4
I assume as an interview question, the primary purpose of this question is to see how you think through these ideas and decisions. In that regard, it's a fair question for an interview. For real life, it's an overly-simplistic question that ignores far too many other factors.
First, there is the argument to be made that neither Scrum nor Kanban is a ...
3
When the client request for the timeline estimate they are looking upto the PM as an expert who can tell them what they need to communicate to stakeholders that the client is working with. So while communicating the time estimates it's important that the factors defining the time estimates and criteria of meeting those should be highlighted. Many a times as ...
3
TL;DR
Why are estimates treated like deadlines?
Because human beings are inherently bad at statistics.
Because business schools teach managers to set targets.
Because the project manager has failed to educate stakeholders about the difference between an estimate and a target.
Examining Each Item In Greater Detail
People are bad at statistics.
...
3
CodeGnome provided an outstanding answer. To add to it slightly: I have observed in my experience that backwards planning is done nearly exclusively. Deadlines are typically driven by some business or legal need; thus, the project has no alternative but to work backwards from there. The problem with this method is that the resulting plan may have no basis ...
3
Mikado Method
On a technical basis, this sort of "reverse planning" can be done using the Mikado Method. The best in-depth treatment of this method can be found in The Mikado Method, Ellnestam and Brolund, 2014. While not optimized for project management, parts of the method (e.g. visualizing the dependency tree) may be useful in scoping a project, ...
3
If you combine this:
My goal is ready to use application for employers and employees. [...] The bad thing is that i have ten days to finish this application.
with this:
We use something based on scrum, making everything in system as needed of working time evidence.
then it's quite clear, that you have just one run. No sprints, no Scrum. Another ...
Only top voted, non community-wiki answers of a minimum length are eligible