21
1.How to communicate with them so they can be follow my instructions?
The team shouldn't be following your instructions, they should be following a plan that they contributed to and signed off on. As a PM your job isn't to do or manage technical work, it is to make sure that the people who are responsible for the doing and managing are following the plan.
...
14
When I was a new project manager, I had trouble separating my previous role as a developer from my new role as a project manager. What compounded my problem was that it was a gradual move, as the project I worked on started out as just me as a developer, and eventually led to me working as a project manager and leaving the technical details to the team.
...
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
Great answers before mine!
Let me add this: I see the biggest driver to your schedule woes is feature creep. If you focus on nothing else, focus on this. When features are added like this, you get a new timeline against which to measure your schedule performance. If you are not enforcing an appropriate change process, then being on time is near ...
10
Redefine the Problem
You list several problems that you believe make your projects late. Specifically, you said that:
Deadlines are missed because we're adding many functions in that Web application.
We have people with not-so-good skills for that project.
The people who are freelancers will only have a little time to work.
These may be ...
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
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
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
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
Prioritize, prioritize, prioritize.
One month could be considered a very long time, or a very short time for such a project -- depending on the scope.
So take the scope (ie. "features"), and list items according how their importance.
Start at the beginning. Do one thing at once.
This sounds obvious, but oftentimes developers will start "a little bit of ...
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
@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
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
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 ...
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
PERT is a weighted average of Optimistic (O), Pessimistic (P) and Most Likely (M) estimates:
(O + P + 4 * M) / 6
Check the cells under PERT to see if they have this formula. Probably "Modal" is the "Most Likely" estimate.
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
