This is perhaps an addition to this question: 'How do you convince a client to use Agile Methods'.

But I was not 100% convinced by the answers on that question. What I am asking myself is how to convince a client when you have to work to a very tight schedule?

I already know that by using SCRUM I can follow up the project on a day to day basis and that it has advantages compared to waterfall. But how do you convince your client to go in iterations, not knowing when exactly the project will end or what it will cost...

i.e. A project has to be put in production on the 1st of January 2012, and it is now the 1st of July. How do we get our client convinced that a bunch of iterations will get us to the final result?

Without knowing the exact timeframe or the budget to be spend, I find it rather hard to convince a client of going in to this.

I was in this situation at a client, in which they did developments without a specific method or framework. They did waterfall as they thought it worked best. In the end we convinced them of how Scrum works, who could do what roles, but they didn't do it because of the risk they saw in this. (no specific cost to execute it and deadline)

Perhaps you have good ideas how to convince these type of clients...

4 Answers 4


As one of the respondents to the linked question suggested, it really depends on what the client's problem is. If the client has a process that they are happy with and it is working for them, why are you trying to convince them to switch? If it ain't broke, don't fix it. If it is broke, you can tailor your message to address the specific pain points that client is experiencing.

You mentioned the client was using waterfall, what has their success rate with waterfall been? There are studies that have shown vastly improved success rates of agile projects. If the client's success rate of waterfall projects is the standard 15%, this would be a great metric to start with. A few other potential discussion points...

  1. Have they ever gotten waterfall projects delivered that included features that were rarely or never used? Likely they have, and if so that is waste. You could explain how agile works to deliver them working software on an incremental basis starting with the most important features first. This way, they can use and evaluate the working software and then determine the next most important feature. In this setup, they can get to a point and decide that the features they have provide enough benefit that they are okay with leaving out the rest of the features to save money instead of paying for them anyway just because at the beginning of the project they thought they might need them. Not only that, but with each deliverable, they could choose to begin using that in a production environment while additional work is completed if it would provide value over the current state.
  2. Do their waterfall projects usually run over schedule? If so, by how much? If this is a large number you can explain the benefit of the agile planning method using some analogies. A common example is moving a pile of mulch. Have the client imagine they have a huge pile of mulch, a wheelbarrow, and a shovel and need to move all the mulch from point A to point B. Have him estimate how long that will take. Now tell him you will allow him to go ahead and move 3-5 loads, and then estimate again. Which estimate do you think would be more accurate? Then you can explain how that relates to the method of planning and estimating used in agile. So you may not know day 1 how long a project will take, but after a few sprints you can get a pretty good estimate and that estimate is almost guaranteed to be more accurate than the waterfall estimate.
  • I like the saying, "If it ain't broke, there is still time to fix it".
    – Jason M
    Commented Jun 17, 2011 at 5:20

Aside from your desire to use Agile I'm not sure why you're trying to convince the client.

Here'e the problem - if your client has a project, and you don't know how to explain that Agile or Scrum will bring their project in on-time and on-budget, then maybe they're not the right solutions.

You also said that Scrum has some advantages over waterfall, which is true. The reverse is also true though, like being able to project cost and schedule, which your client obviously values. You can (and should) follow-up day to day with both.

So going to your question of how do you convince your client - first you make sure that Agile/Scrum is the right answer. If your certain of that, then the reasons why should be fairly easy to explain to your client and convince them. But if you're struggling for how to convince them, then maybe's it because they're not the right answers.


I have to agree with Trevor. I'm not sure why you have to convince the client.

I don't have problems with this, my clients trust me to find the best method to deliver the project. I tend not to use PM jargon with them, though. So, it may seem to them you are trying to apply a methodology for the sake of the methodology rather than the project.

Here are some of the ways I discuss how we'll approach the project.

"Given X and Z, I think it makes sense that we plan in detail to this deliverable and then we'll know enough to plan the next stage."

"We know a lot about the work involved. I think it makes sense to do some pretty detailed planning to the end so we can get a picture of the whole effort."


I think there are 2 main issues :

  • can you at all suggest a change in project methodology ? (large customer tend to have corporate official way of doing that is mandatory for everyone)

  • what is the customer stance regarding to scope ? Do they understand that fixed price mean that the scope is the variable of adjustment (unless you make addendum to the contract to pay more)

If the answer is no to at least one of these questions, then don't bother, it's a lost cause

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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