The customer usually wants to see a plan as early as possible - its a reasonable request.

The request comes in one of two basic forms; a statement of desired delivery or a question about feasible delivery. The former is probably most common and can be quite intimidating - the project is anchored immediately to a date in the first breath and nobody has the slightest idea whether it can be achieved or not. That's not a pleasant situation for the supplier but its also a risky one for the customer but that risk isn't perhaps quite so apparent. The later is preferred by the supplier because there is no anchor - at least not one that's been mentioned - the customer is just keeping it to himself for now. When the supplier provides his first stab at feasible delivery the customer is likely to expose their anchor, especially if the feasible delivery is too late - and even if it isn't most customers will re-assess their anchor and bring it in behind the suppliers date.

That's the first poker game over - later when lower level discussions are in full flow planning poker will deal with anchoring in the sprint planning - but why wait until then? Planning poker can be played with any unit of time, even weeks or months (lets hope we don't end up using years). But is so difficult to avoid that first anchor because the senior management will start their exchange with the customer saying "We'd like you to deliver x by the end of the 3rd quarter". Next time you work with that supplier - try and encourage them to ask "We'd like to deliver x as soon as possible, can you give us some idea of when that might be?".

Even when the customer provides a statement of desired delivery they will want to see a plan that gives them some comfort - which is a bit of a contradiction - they are knowingly pressurising the supplier to deliver by a specific date but they want some comfort that it is achievable - hey you don't want much do you, eh? But this isn't as big a problem as it might seem - its often thought of as a problem for both customer and supplier because normally the result is that the supplier over commits and the customer releases sponsorship for a risky project and the only predictable outcome is failure - at least to a degree. The project might hit the deadline but not all the key features are delivered - it might hit the deadline with the key features apparently delivered only to later discover that they are riddled with bugs - the deadline may be missed altogether. This article isn't about how to avoid these outcomes but the objective is to tackle the first hurdle - giving the customer that plan no matter how unreasonable the request may seem.

Its perfectly OK to do this providing the communication of the plan and its risks is carefully articulated and the pros and cons of the method are clearly understood by all.

The pros:

1. The customer is provided with a high level schedule that they can begin to use to measure the progress of their project.

2. The supplier has a high level schedule that they can use to demonstrate the complexities of the project in the context of a time-line - the supplier can begin to illustrate against the plan why something needs to change in terms of scope or resourcing, budget or schedule.

The cons:

1. The customer may be asked to respond to change as the project proceeds and information comes to light - this may involve changing this initial plan - this is a con because its a challenge to the customer - but its a good practise.

2. The customer may ask the supplier to fit the project into this plan - this is dangerous as the most likely artifact to suffer from this will be the quality of the software.

3. The supplier may return with detailed estimates that come in way ahead of this plan - many things can happen here - both teams are nervous that something has been missed - the customer wants more in the same time frame - the customer wants to cut the budget.

The pros are all good reasons for doing this and the cons need to be viewed simply as the challenges the teams may face as a consequence of taking this approach. The key to mitigating the cons coming into play is to have a poker game with the senior management from both the customer and supplier. This opens debate about why the customer needs the software so early - their commercial pressures - and also why the supplier will take so long to produce what the customer needs. This poker game will be a refreshing experience for these guys - they will come to an agreement about what is achievable high level and will inevitably reduce the likely-hood of any surprises later in the project.