How to Introduce Uncertainty without Scaring a Customer?

Question

Recognizing uncertainty is fundamental to an Agile mindset. When leading the transition to a more agile mindset, how do you tell your customer that you, as a development team, generally operate in a world of uncertainty, when they have always looked to you to simply "get the job done? "

Answer 1

While not being a trained expert on the Agile ways, I would try to not bother the customer with uncertainty in the way of "you might not get what you asked for", but rather give him certainty that something (and be it just confirmation of the viability of a solution) can be done.

I think agile methodologies can help here. Take Scrum. Your team should commit to certain things for the upcoming sprint. You don't want to commit something you might not be able to deliver due to uncertainty. So I would try to phrase the commitment differently, to state that the goal for this sprint is to identify possible solutions for this problem. And another story later is to implement one of them (or some workarounds). Of course those risky, critical points have to be identified as early as possible in a project, so that the investigation "stories" can be done soon enough (especially if there is a risk that the entire project might fail because of them).

I realize that investigative stories like that might not be proper Scrum stories. But personally, I don't care :) I believe it's easier to sell a story like that to the customer than tell him that you will do Story A in the next sprint, but it might not work.

Answer 2

I used to use a commuting analogy.

You know it normally takes between about 40/45 minutes to get to work, so there's a basic level of uncertainty there: 40 to 45 minutes, but you don't know whether it'll be 40 minutes, 45 minutes, or somewhere in between. So you allow 45 minutes.

But on a bad day (e.g. when the traffic is unusually heavy, or a train is cancelled), it can take up to an hour. This only happens about once a month, but if you want to be certain you'll arrive on time, you allow an hour.

But maybe once a year there's a horrendous delay (e.g. multiple car pile-up, two trains cancelled and the third one delayed), and it takes an hour and a half. So you have to decide whether you want to allow 90 minutes every day, and get in 45 minutes early most days, or accept that you'll be late every so often.

If you want, you can take this further by drawing a Normal Distribution graph, with percentage bands, explaining that increasing certainty has a cost, and ask him what level of certainty he would find acceptable.

Answer 3

Thank you for your reference to my book "Making Sense of Agile Project Management". You're on to something very important, in my opinion. The level of uncertainty in a project is one of the most important determinants of the project management approach (either agile, traditional, or hybrid).

An example I've used in some of the talks I've given to PMI chapters is an example of building a bridge across a river...it would be ridiculous to take a very agile approach for that kind of project..."let's build the first span, see how that comes out, and then we'll figure out how to finish the rest of the bridge" - that doesn't make any sense at all!

The mistake many agilists make is assuming that the customer doesn't have a clue of what they want and that you need to start from scratch as if there were complete uncertainty and it's futile to develop a plan. That is rarely the case - I’ve never worked with a customer where there was no expectations about what the project would cost and how long it would take to complete it. There’s generally an expectation that you will do the best you can to develop a plan based on whatever information you have about the project and continue to refine that plan as the project progresses.

In some cases, where the uncertainty is low, you may be able to develop a fairly accurate estimate and plan (e.g. building a bridge). In other situations where the uncertainty is high, the plan may be very thin and sketchy and subject to a lot more adjustment as the project progresses; and of course, that needs to be mutually understood with the customer.

I have a model I’ve developed called “Managed Agile Development” that consists of two layers: a plan-driven “macro” layer and an agile “micro” layer…the plan-driven layer can be thick or thin depending on the level of uncertainty in the project. It has worked great in several situations I’ve been in.

The key to getting this to work is developing trust with your customer. If you don't have trust and credibility with the customer, it will be very difficult to get this to work.

I hope that helps...

Chuck Cobb

Answer 4

I think it comes down to selling the benefits of the approach. Using the agile approach, your customers still get what they want, and they start getting some value sooner, and they don't need to have all of the details hammered out before you start. So you are giving them a better experience with delivery starting in a shorter timeframe, and more opportunities on their part to control the scope of the work - and hence the spend - over time.

It might be difficult to put all of this into a proposal to the customers, however, if it hits them "cold". If they are used to getting a fully-costed proposal, and you present them with something that is not what they expect, they are going to be uncomfortable, which is not what you want them to be. So, you really should be thinking about warming them up to your preferred way of thinking, well in advance of producing your next proposal to them. Consider developing a presentation that explains the approach and the benefits (from the customer perspective) and then sitting down with your customers to see what they think of the way ahead. Be prepared to be challenged, and don't expect a rousing success the first time out - but keep the door open for ongoing discussions on the subject. Some ideas take a while to sink in!

If they are still reluctant to accept what you are saying when you have to make your next proposal to them, you still have the option of producing a conventional (some would say old-fashioned) proposal that won't upset them, and you should be able to retain the customers' business. If the feedback from the customers is more positive, and they are happy to buy in to the Agile approach, you have a win-win result.

Answer 5

I think it is rare for a customer to cope with the notion of uncertainty in a typical buy-seller relationship. Most of us to some degree suffer from a serious case of illusion of control in ourselves, wherein we have a tendency to believe--really believe--that we can control our environment. The notion of random results affecting our own performance is foreign. Accepting it when we buy services from others is even less appetizing.

For the really savvy buyer with strong business acumen and with a buyer-seller relationship that moves towards a trusted adviser and true partner, then the introduction of uncertainty is possible. Without these two variables in place, I think most customers would think the seller is trying to make up excuses early to blame uncertainty and the randomness of results for their poor performance.

In most cases, I think the notion of uncertainty is best left with the seller and its risk management processes. You are left with active mitigation, early communication, great customer service, and hope your customer can tolerate you when work randomly falls to the unfavorable side of things.

Sadly, though, this works against the customer. This sort of forces sellers to pad their estimates, to push their targets to the right side of the curve, causing the schedule and cost to grow. While this increases the likelihood of success, the customer pays for every piece of it.

Answer 6

Make them dream, I mean share your vision for them to see the final result in their imagination. If the customer is uncertain, it is because he thinks you are not able to acheive what you are saying you want to achieve for him. Simon Boulanger, BAA MBA Bth ACS FLMI