Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

I apologize if this sounds basic, but here's the scenario: We were supposed to complete a project in August and now that it's November, it's still in progress. After asking the client to provide us with feedback regarding certain tasks, the response was along the lines of, "don't push me. You missed the deadline, so now I decide when this project is completed".

I have to admit that I was thrown off, but this brings up another question: as a web dev shop, we take on multiple projects at a time and a delay like this affects our ability to take on new projects. So how does one decide when a project gets completed? I'm thinking that I'll have to sit down with the client because, obviously, he doesn't want the project up and running in 20 years from now. He must have some vague expectation of project completion that's in the near future. So the question is how would I approach this? I'm relying on other project managers with far more experience than me who may have come across this scenario.

share|improve this question
    
Excellent question! Let me check my understanding. You missed the deadline on WBS 1.1. You're still working on WBS 1.1 and 1.2 and 1.3, but the customer is refusing to provide essential feedback on all the tasks? That's a hairy problem. –  Mark C. Wallace Nov 8 '12 at 19:51
    
Let me modify that a bit - we're done with 1.1 and 1.2 is still in progress. We're close to being done with 1.2 and need feedback about its progress before we get to 1.3. We can't move ahead without the client's approval on 1.2 (as there is a UI/Design component to the project). And that's where we're getting stalled on - the client wants to take his time to review what's been done on 1.2 so far. We provide for 4-5 days for feedback, but it's been over 3 weeks now and no word from the client (except for the response mentioned above). –  JTech Nov 8 '12 at 20:21
1  
Oh boy... you inherited it. Probably time to come clean to the client and explain the changes and how that affected the deliverables. Damage control, unfortunately –  user1220 Nov 8 '12 at 20:26
3  
What type of contract are you operating under for this project? –  David Espina Nov 8 '12 at 22:17
1  
@user1220: yup, this is inherited. I agree that it's time to redefine and explain what the deliverables are (shockingly, even this seems to be pretty hazy after reviewing all the email communication that has taken place - thankfully, the contract and SOW are rock solid). –  JTech Nov 9 '12 at 12:47

4 Answers 4

up vote 5 down vote accepted

@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 B's answer is very good. There are a couple of other thoughts I'd add. Effectively the client has imposed a constructive change - he has taken advantage of your missed milestone to completely destroy the project schedule without providing a replacement schedule. If I were in your shoes, I'd do the following:

1) Document the impact of the current change. Assume that your client won't respond on 1.2 in the near future. For the sake of argument, assume that you're stalled until 31 January. (It is a safe bet for my clients that December and January are wasted months with critical staff on leave). Revise your integrated master plan to show the effect of that delay. Prepare an estimate based on 1 month, 2 months and 3 months. Now you've got two options:

1a) I you want to keep the project alive, then propose that during the review period we alert key staff that this is a good time to take leave, spend time with families, etc. There is a lull in the project, but we expect it to restart in February.

1b) If you want to play hardball, identify your key staff. Revise your Integrated Master Plan based on the assumption that some fraction of these people will move to projects where (a) they have satisfying work to do and (b) the company isn't wasting their talent. Personally, I would begin to develop opportunities for these key staff.

I'd also do a series of simulations showing the effect of varying delays on the project. (in a similar situation in the past, I measured the slippage that resulted from customer failure to produce feedback, and then did a monte carlo simulation for all similar governance tasks. That allowed me to state that if stakeholder X continues to drag their feet, the schedule would have an X% chance of Y months of delay with a concommittant rise in total cost of $Z).

Include risks - if the project delays for 2 months, there is a 30% chance we'll lose key staff (what is the turnover rate for your company for those key staff? If your company doesn't have that calculated internally, you should be able to find it for similar companies/skill sets). Loss of key staff will delay project by X and raise cost by Y.

Calculate the point where it makes sense to kill the project. For example, if the client delays for 2.6 months, the project will no longer be profitable to the company.

Now present the data to the client and to your management. The carrot is that you have demonstrated that you're a better project manager than your predecessor, and that the probability of missed milestones has just dropped. The stick is that you have identified a point at which it would be sheer folly for your company to continue the project.

If you can turn this project around, your company, your client, and the key staff ought to recognize that you've done a great thing. Zombie projects smell foul, and that smell taints everyone involved.

share|improve this answer
    
While the client is difficult, I don't think it's gotten to the Zombie status ...yet. +1 for the simulations - great idea! –  JTech Nov 9 '12 at 12:51

I think you have several options:

  1. "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 forward looking and move beyond finger pointing so that you can find solutions.
  2. "Amend" the project. Similar to the first option but you aren't starting from scratch. This can be easier for people to swallow, especially if there have been no changes to the team, as nobody wants to admit previous effort was "wasted". This can turn into a reboot but there is risk that you will be hamstrung by components of the original plan that may not be in the project's best interest now.
  3. "Kill" the project. This is a business decision and not a PM decision. It is (IMHO) a PM responsibility to present a reasoned assessment of this option. If keeping this project on the books is going to affect your company's ability to take on new projects there may be a business case for walking away despite not being able to recover your sunk costs. There is also a risk of reputational costs following this path, but if your customer is already ticked off with you this may be minimal. Again, not a PM decision.
share|improve this answer
    
+1 for laying out those options... who said PM was subjective? :) –  JTech Nov 9 '12 at 14:25

This is a lump sum contract as you indicated and I imagine the sum is fixed. A fixed price contract guarantees only a fixed price-- as evident in the name. It does NOT guarantee a fixed schedule. Indeed, we target a delivery and do our best to hit it; sometimes we beat it, sometimes we miss it, and very few times we hit it dead on. That's project life.

I also imagine that your contract has explicit expectations and obligations that are required of your customer, which could include establishing work space, providing documentation or equipment, providing subject matter expertise, and providing verification and validation on a timely basis. It appears your customer is withholding that because you were late, which has an underlying message that (s)he is sabotaging your ability to make a profit almost as revenge. This is immature, irresponsible, laughable, ridiculous, and is most likely a violation of your agreement.

Here's what I would do:

  1. Stop work.
  2. Comb through the contract, statement of work, proposal, etc., and identify where and how your customer is violating the terms and conditions of your agreement.
  3. Calculate the financial impact sequel to said violations.
  4. Retain an attorney and pursue.
  5. Remove customer from your customer relation management database and allow others to win his/her work.
  6. Move on....

I suppose this might deserve an attempt to sit down with the customer to try to work things out before such a drastic action. There is something about this childish behavior, though, that makes me want to just react with the drastic action. And, with this display of behavior, the likelihood of a fruitful result is probably low. So.... My two cents.

share|improve this answer
1  
I thought about this - I think it is a valid path, and if we consider only the facts of the matter, it is probably the right path. I'm concerned that since the OP missed the first deadline, that this could rebound unpleasantly. I'm afraid that this will devolve into a long and contentious problem that will taint everyone involved. Of course, I've never travelled this road, so I may be dead wrong. –  Mark C. Wallace Nov 9 '12 at 17:35
1  
+1 for nailing it dead on about the contract terms & expectations about requirements. I wish I could upvote again as the instructions are extremely helpful if we (as a company) have to pursue the drastic option. I don't think it's come to that stage yet. I tend to have a lot of patience with clients like these if it's a first time "violation" (which it is), regardless of how condescending they can be (after all, it is project life). If this was a repeat client, then there's no question that I would follow your advice about stopping all work immediately and moving on. Thanks, David! –  JTech Nov 9 '12 at 17:37

Are there upper level on both side? Possible to escalate the issue to senior management?

client acquire project services because they expect benefits of having the deliverable (the final product) developed by a vendor.

Late is better than not delivering the products at all. Thus, may want to try understanding from the client perspective what would the expected benefits to the client.

Prepare a simple business case with expected benefits (tangible and intangible) and present to someone who can understand it (I would expect it would not be the one who you are dealing with directly.).

Late is common to software development project, but it is not a valid reason for the client's user representative to delay neither.

Though contract may not be clear, common practices does apply!!

Understanding your client's organisation structure on their executive point of view. Start from there.

Sometimes, the Top Down approach may just work in case like this.

If your client is also the top management. Then, assess the possible loss to your company versus the time and resources already and will expect to spend if continue to drag on the case. May help you to make a faster decision.

Rose from Hong Kong

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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