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.

Here's the thing: In agile, client has very important role to fulfill - if they aren't involved, agile loses much of its value.

How do you convince clients to change the way they run projects, especially with big companies and at least medium-sized projects?

I guess they don't just believe salesperson saying "that's better." And if they don't have much experience working the agile way, clients are likely to be reluctant. So how you make them to change their minds?

share|improve this question
    
This is a very great question. Tomorrow I'll have a meeting with my customer, trying to "sell" him agile. I'll get back my experience. –  davidepiazza Mar 14 '11 at 22:05
add comment

4 Answers 4

up vote 16 down vote accepted

Gradually

If you try to convince your customer (or boss, management, colleagues, etc) to do something totally differently to how they've been used to doing it, then they'll react in one of the typical ways in response to change: acceptance, panic, refusal, etc. So, I recommend a gradual adoption of Agile methods until you're there, for example:

  1. Start by having weekly meetings with the customer to discuss the 'prioritised requirements' (Feature Backlog). Ensure the priorities are set by the customer and are in Story Points units (with guidance from you).

  2. When you add items to the list, write them in 'User Story' language, but familiar enough not to confuse/alienate the customer. If you've already got some kind of specification or use cases, adapt them, but don't be tempted to totally re-write them - the customer likely won't be able to make the leap.

  3. Have regular deliverables so that the customer can see progress and the benefits of the new way of working. Make sure they know what they've just received, how to get to it (URL, download site, etc) and follow up to make sure they've tried it.

  4. Get feedback on these deliverables at the next weekly meeting so that the customer can refine the Feature Backlog according to what they want to see next. Take the time to outline this 'choose top user stories, implement, deliver, review' mechanism to introduce the concept of an 'iteration' or sprint.

  5. Assign cost estimates to each User Story so that the customer can understand the effort required to achieve each User Story and can learn how much could be achieved in one iteration. Be open with the customer about the Planning Game used to come up with the estimates.

  6. Make sure the customer can see how many User Stories have been achieved so far (budget used) and gets a clear understanding of how many of the remaining stories could be completed in the remaining time/budget.

I've done this successfully with multiple customers and found that after delivering on promises for a few weeks, they totally trusted us from then on and focussed more on which features they wanted most urgently rather than whether or not we were going to deliver. We didn't necessarily expose them to all the terminology, but they 'got' the regular updates and open-and-honest discussion about what features get implemented next.

There's nothing scary, wrong or weird about iterative project methodologies (such as Agile, XP or Scrum), its' just not the 'traditional' Waterfall method. Having a nice human explanation helps:

In traditional construction, you can't alter the foundations without first tearing down a house/office block/bridge. This is one reason that you have to get the foundations right first before moving on to the walls and roof.

In other industries, you can change any part of the system without having to start again. For example, in Formula One, you can jack up the car to change the wheels - you don't need to disassemble the whole car.

Therefore, some projects are very suitable for a iterative/cyclical approach where the initial solution is refined many times until it is just right.


I've deliberately been vague with the Agile terminology in order to convey the message easier and I've had a long day so may have got a bit muddled in there.

share|improve this answer
    
Great answer! I found this really helpful, tired or not :) +1 –  jmort253 Mar 15 '11 at 3:46
    
Very interesting, so it comes down to adapt the methods, but don't use the terminology on management level. What do you do if there is a person in the management team that saw your intentions and creates panic in the management team? –  Kennethvr Mar 15 '11 at 7:34
    
@Kennethvr: you catch this as early as possible and work with that single person to identify their concerns and also with the management team to allay any fears they have. See my edit above. –  JBRWilkinson Mar 15 '11 at 14:37
add comment

One of good answers is "you just don't."

It is perfectly possible to run agile project without showing client exact way the team works. What more, very often client won't be interested in that. The trick is they won't be interested in being the part of the team as well. They won't be actively participating in prioritization or product demo at the end of the iteration. Usually the best method here is to emulate the client within a project team. Very often the best person to do this is project manager who knows the client and the merits of the project well.

Another answer is: make it win-win

For some time I thought it is very, very hard to build some kind of agile contract which is win-win and limits risks on both sides: client's and vendor's. This presentation form Paul Klipp (slides are here) is the best approach to the subject I've seen so far. It gives incentives to both sides to finish faster and shares the pain of dealing with the slip inflicted by scope changes.

Also you can try to show them

This one is tricky as it assumes you can convince the client to give it a try. However one, pretty good, argument I heard which can change client's mind here is letting the client abandon the project after first two or three iterations at no cost. Then you have some time to show the value of your approach, possibly presenting how client's engagement helped to make the result of these first few iterations better.

share|improve this answer
    
The first link you included is broken, just FYI. –  jmort253 Mar 15 '11 at 3:36
    
Fixed it. Thanks for catching that one out. –  Pawel Brodzinski Mar 15 '11 at 7:31
    
You're welcome! –  jmort253 Mar 15 '11 at 7:32
    
As most of agile pethods imply a form or another of involvement of the customer (story game, short iterations with feedback form the customer and so on), I'm not sure the first point is really realistic. Replacing the customer by the project manager is, in my opinion, missing the point WHY the customer has to be involved! –  Alexis Dufrenoy Mar 16 '11 at 10:16
    
Actually I saw it working in many places where the organization and people wanted to work agile-way but the client wasn't interested in being involved in the process. Of course it isn't as effective as having client working closely with your team but it works. –  Pawel Brodzinski Mar 16 '11 at 13:53
add comment

Both of the answers already given are excellent and I support them. I just wanted to add one modifiying factory. At a recent Agile panel one of the speakers made a very good observation. "If things are working and running well, then getting someone to change to a whole new system is going to be a very hard sell. Pitching an change to Agile is going to have better traction if things are already broken."

Then you need to tailor your Agile reponse to what is actually broken. You don't just swoop in and "Go Agile", you have to see what has been happening and migrate from that.

share|improve this answer
add comment

Mark, as a consultant/coach you can't want change more than your customer. They have to want to change and that may mean you have to stand by and let them fail. Maybe they're already failing but just can't see it. You can try and point this but this is a tricky slope that often leads to the fragmenting of the relationship. Better to step away and be invited back later when they are ready to change.

share|improve this answer
add comment

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.