22
Start with a high-5 all around! :)
Meet with your customer. Let them know you think you've completed the feature and give them a demo. Ask them if it meets their acceptance criteria. My bet is the customer will have some tweaks or changes now that they have seen it. By circling back to them right away, you've got a chance these changes can be made without ...
21
When taking over a troubled project, one of the very first things you need to do is to slow or stop the train. If you let it continue to move, you will most likely continue on the same path and unable to introduce any meaningful intervention.
You need to get the sponsor at the table to redefine the project as if it is a new project. This means the ...
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.
...
17
Is it possible to sit down with the CEO and tell him exactly the same you told us?
If he keeps sending adhoc requests to your teams, you don't have other choice than mark him as a risk and schedule the customer projects accordingly: less resources for the customer and more for the adhoc situations. Be honest with him, and discuss the situation. I don't ...
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 ...
12
Uncontrolled scope creep - the project starts with the best of intentions. It is well defined and understood, but somewhere along the way, someone asks for an extra bit of functionality, or a new interface, or some additional management information. Sure, it's not in the original specification, but it is only a small change... But unfortunately it is one of ...
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
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
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 ...
9
Some good answers, but the most important one seems to be missing, the one that addresses al of the others - the main factor that causes projects to fail is weak project management.
Looking at all of the answers so far, all of them can and should have been addressed and controlled by the PM. Scope creep, change control, project kick-off, assumptions, ...
9
First of all, it is not entirely your fault that the project went over schedule. As they asked, you did the best you could given the resources available. You told them the risks, and they agreed with it. The only points you should have taken more care of is that you took one month (1/6 of the time available) to figure out that the other guy had no prior ...
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
@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 ...
8
After I have received some of them, I have found out that the sponsor wants more than what we have been programming for. How do I handle a situation like this?
Part of what you need to do is triage the project: what can be finished, what can be finished only by scaling back and what cannot be finished in the time allowed (and needs to be dropped in "this ...
8
Interference of your planned work is part of the stochastic uncertainty of all project work and should be part of your estimates and targets, to which you alluded with the "extra padding" message. I would not recommend that you tell your CEO his requests will have to be sequenced with all the others. However, if you are able to show that lowering the ...
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
You can plan a project without a software tracking tool, you can't plan a project without communication.
The tools is just that, a tool. You use it to help you get what you want done. A hammer won't build a house, but it will make building the house a lot easier (using rocks to pound in nails is hard on the hand).
And as Zsolt says, tracking tools do ...
7
If I should pick one it would be poor or/and infrequent communication in as many aspects as you can name.
Poor or/and infrequent communication
with client leads to poor requirements, problems with scope, issues with prioritizing, decreasing feedback loop and many more, delivering different from what the client wanted
within the team leads to code ...
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
From experience turning around too many messy situations:
Weak vision - poor understanding of the end goal. (Symptom: focus on features over the business case)
Undocumented requirements - too much in peoples head. (Symptom: new requirements in testing)
Poor metrics - lack of rigorous quantifiable progress updates. (Symptom: late slips of large magnitude ...
6
I'd echo Joel's answer about checking with customer and also simpixleated's about polishing.
A few other thoughts though, on the lines of "are you sure you're finished":
You have a month project, developed in 2 weeks. Is there any plan for testing the software that has been developed? Either from a functionality point of view or other less visible ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
