13
welcome to PMSE!
In short, yes and no. Yes, because the team member will be responsible for the deliverable. No, because a team member can only provide you estimates. In your question, I'm assuming you used the term deadline as estimate, don't you?
Thinking of estimates, you're not only allowed to, but you must ask your team for estimates.
An estimation (...
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
Assuming that the decisions that you want made are valid (i.e. you aren't overwhelming your customer with details that are really your responsibility to decide on), the problem seems to be that your customer, or maybe just your point of contact, is not engaged with the project. You need to address this root cause or you will spend a lot more time and effort ...
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
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
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 (...
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 ...
6
I agree with Doug (+1) that's on customer to decide how important the project is to himself. If he doesn't dedicate enough time to the project, he may not consider it as important as you may think the project is.
It doesn't mean, however, that your team will stand still waiting for them to discuss the open points.
As you mentioned, I'd go for the first ...
6
@user1220 said it - This is where you earn your value as a PM. You have the opportunity to turn a project around. Right now this project is on a fast track to zombie status - not quite living, not quite dead, but tough to kill. You have the opportunity to change that and to transform it into something that will look fantastic on your resume.
I think @Doug ...
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
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
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
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 ...
5
Two different processes done by different roles. Organizations, in my observations, typically combine them, which is mistake. Estimating should be done, as Tiago indicates, by the workers who now the work intimately, while the targeting should be done by the business, e.g., the people accountable for success. Estimating should be probabilistic, e.g., I ...
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
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
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 ...
4
I think you have several options:
"Reboot" the project. As you infer from your question sit down with the customer and key team members responsible for producing the product. Get them to admit the project is in trouble and create a new plan that is achievable. Besides schedule be prepared for budget and scope to change. The key point to remember is to be ...
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
There are major points in most projects where you must have customer verification and validation before moving on. It is an unreasonable risk for both parties to bypass these points. And as Doug suggested, you should have in your contract where those points are such that, if the client does not do his/her part, you are held 100% harmless on delays sequel ...
3
Depending on what kind of planning you need.
If you are looking for a project management tool for planning your progress, it is necessary to do so. You may try something like JIRA.
If you are just looking for a way to share the progress with your team, you don't have to use any complex project management software. Instead, just share the files in Dropbox ...
3
Planning tools are always advantageous if used right, according to your specific needs. They improve your and your teams understanding on a plan and makes it easier to cope with deadlines. However, as it was already mentioned, a tool is just a tool. So the disadvantage would be that you still need to do the planning yourself, planning tools only enhance the ...
3
There is a joke: "Project managers are people that believe 9 women can give birth to one baby in a month." It is your professional responsibility to set realistic expectations. Going all out and working a 80+ hr. week is mentally exhausting, which in software development leads to more bugs than genuine progress. In France since 2000, the legal work week is ...
Only top voted, non community-wiki answers of a minimum length are eligible
