« The Adoption Paradox
What Is the Definition of Done (DoD) in Agile? »

Six Degrees of Separation Between Good Projects and Bad - Bad Client

August 24, 2011 | Author: PM Hut | Filed under: Requirements Management

Six Degrees of Separation Between Good Projects and Bad - Bad Client
By Sean kenney

I have been consulting for a number of years and in the time I have spent many days and nights dealing with project issues. I have concluded that there is generally 6 buckets that you can typically put project issues in. They are:

  1. Bad Client
  2. Bad Statement of Work (SOW)
  3. Bad Requirements
  4. Bad Process
  5. Bad Leadership, and finally
  6. Bad Resources

Naturally, this is easy to remember by memorizing the acronym CSRPLR. Really, I am kidding. That is a ridiculous acronym, but not quite as bad as NASCAR (National Association for Stock Car Auto Racing).

I have put some thought into this and I have found the buckets above generally address what has gone wrong with projects in my experience. I have also tried many ideas and strategies and have come up with a plan on what you can do about it.

This will be the first of 6 articles posts where I talk about each bad bucket and how you can work through these types of issues.

Bad Client

If you have ever done any consulting before, or worked in a scenario where you had to deal with clients, you will quickly become familiar with what a “bad client” is. You can even think back to your first service job, maybe a company that rhymes with RickDonalds, and you will quickly remember what a bad client is. My definition is similar to what you experienced:

  • Unwilling to listen
    • You: “Sir, you did not order an apple pie. You will have to pay for that.”
    • Client: “I should not have to pay for that, it was your mistake”
  • Unreasonable expectations
    • You: “I can order it for you now, but you will have to pay for it”
    • Client: “You should have known that I wanted an apple pie”
  • Unwilling to negotiate
    • You: “I can give you a 10% discount on the pie”
    • Client: “I should get it completely free”

Hopefully that does not bring back memories that were too bad. These same situations also happen in the consulting world. Here is an example:

  • Unwilling to listen
    • You: “We talked about that and it was out of scope.”
    • Client: “It needs to be in scope.”
  • Unreasonable expectations
    • You: “We can put it in scope, but we will have to change the price or the schedule”
    • Client: “It was your fault that you did not include it.”
  • Unwilling to negotiate
    • You: “Since it seems like a non-negotiable requirement, we will put it in, but we are going to have to submit a change order for additional funding to cover some of the cost.”
    • Client: “I should get it completely free, since you missed it.”

I have found 3 techniques that I have used in the past to help mitigate this situation.

  • Find out the motivation of the client and see if you can address the motivation.
  • Talk to the client and see if there are other priorities that are more important on a larger scale.
  • If you cannot avoid additional costs, use the risk budget that you should have planned in your RMP (Risk Management Plan)

When you have a bad client, using the first option, root causing the motivation, is sometimes therapeutic for the client and gives you a potential for negotiation. I have been in a situation where I talked to the client about their motivation behind not wanting to talk out an issue, and it came down to the fact that they thought I was there to “out-negotiate” them. I simply told them that was not the case and that my team was there to make everyone successful, no just our team.

The client eventually realized that as we kept talking, that I was willing to make concessions on this item, if we could get items of less priority off the table. The client at that point realized our relationship was not us vs. them, and that we truly did want to deliver the project that they would be happy with.

I was on another project where I was told that we had to deliver additional functionality that was agreed upon, but never finalized with a change order. I started talking about how we can both be successful and deliver the project with this additional functionality. I talked about removing some minor scope and they dug their heels in about the fact that they must have all scope.

I found that I had no other choice other than to use some of the risk budget that was set aside for known unknowns. This is obviously the last choice that I wanted to make, but it was set aside for exactly these types of scenarios. To put it simply, if I had not done an RMP, the project would have been behind resulting in a late delivery and over budget project. I can simply not emphasize enough about having a good RMP when dealing with clients.

I look forward to writing the other 5 buckets of this series and welcome your comments and feedback.

Sean Kenney is a software architect in Houstan, Texas. You can read more from Sean on his blog.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Wednesday, August 24th, 2011 and is filed under Requirements Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories