5

What should be the best way to handle situations where the time taken for parts of a project go "over budget" or over the estimation that was made for them while you are also trying to achieve a high quality product to present to the client.

What are some tips for achieving the best balance here and a way to manage the developers that are working on the project(s)?

4

In the end, your goal is to provide a solution to a problem for a client. Your role as a project manager is to communicate with developers on the project, clients, managers, and other stakeholders.

There are times when something must give, and that is either quality, functionality, or delivery date. As soon as you suspect that the project will go over the estimated time, the first thing you should do is communicate this possibility to all of the stakeholders.

By informing the client of the problems early, this puts the ball in their court and avoids any nasty surprises. Based on discussions with the clients' stakeholders, the client may decide to drop some features, the client may decide that quality isn't as important, or the client may decide that pushing back the due date is acceptable. This largely depends on their business goals, such as how flexible their schedule is or how important it is that the product be reliable.

In my experience, most clients will respect you for watching their back. Like you, your client has people that he or she must answer to, and if you keep them from having to deliver awkward, last minute bad news to their stakeholders, they will not only feel more in control, but the project will also run much more smoothly.

  • +1 to the importance of communication in this circumstance. – Mark Phillips Feb 10 '11 at 14:26
3

Keep the client informed. As a general rule, when something has a 50% chance of messing up your project, tell the client that its a risk. When it reaches 75%, tell them that its a fact. You can always outperform a lowered expectation (but its better than being caught in a death spiral of trying to catch-up).

As far as the developers, you need to cut scope and have them laser focused on the key items that can be delivered in the shortest time so you can start giving your client something they can use.

  • +1 for asserting one can "outperform a lowered expectation". This is a great rule to live by. – jmort253 Feb 12 '11 at 6:19
1

Unfortunately there is no easy answer. I think this is a very common issue that happens in many projects. The short answer is increase cost, but in many cases that is not simple.

Below what I will try to do if I was you:

  1. Make sure to compare the requirements from your client to your "development" tasks. Try to avoid giving things that are not part of the requirements to make your client happier, I know that sounds wrong, but you are in a though spot. Remember you are bounded to give what the client ask nothing more, at least in theory.
  2. After I compare, I will see if I am doing something that should be considered a change. I will seek your sponsor's help, if you find a few of these.
  3. I will make a list of the features that you are building, and sort them using the frequency that the client will use that feature. This will let you know if something might be deploy after launch.

Post a comment and let me know if this makes sense. If not, let me know and I will clarify.

Thanks, Geo

0

The problem is with "Report Performance" and "Cost Control". You don't perform them properly, that's why the budget is in charge of you, not vise versa.

The solution is to make sure you do cost control regularly, and your team members report performance to you often enough.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.