Archive for October 18th, 2011
From the fist look Agile may be obviously beneficial, however getting customer there is not that trivial as it may seem to.
Let’s take an example I’ve came across recent times.
An online service wanted to have new web application developed (for certain reasons I cannot specify it’s name). It turned to a team, giving high level detailed specifications and asked for estimates (both budget and time-wise).
Or another one: “… we’ve got budget fixed and cannot afford us more. Can we get our application for it then? How we can have guarantee that we’ll cover key functionality we need, ha?”
Or… “Just tell me when it’ll be ready and how much it’ll cost”.
Well, the scope is usual trap here. Customers may have a rough idea about scope (in some cases they could have even detailed specs defined). In both cases it ends up having either nothing specified or too much specified making them hardly answering realistic scope question and leaving team being not able to forecast or making dangerous guesses.
Familiar cases, aren’t they?
To address situations like these I combined my sales experience with known Agile benefits and came up with simple 10 step practice.
Here I go…
To get the point how to sell best it’s needed to get closer to the reasons why your customer demanding to have fixed contract: most likely he may want to be sure he will NOT spent more budget or time then he has in mind to to get the imaginary scope. There may be plenty of other reasons as well…
Only getting answers will help you to prepare your deal properly.
Here are simple steps I found working dealing with fixed contracts:
1. Prepare (before you start): think of the reasons and ways to make sure you understand limitations and rationales for fixed contract for your particular customer. Stop here and think!
If you’re not sure you understand those, do not sell as you’re not prepared yet and you may offer wrong benefits, operate using wrong terminology, stress not important aspects, etc… This is key point. Prepare your deal before moving forward (I promise another post to explain how to get clear and move forward).
2. Set the stage: explain Agile (SCRUM) rules without selling them at this point (just simply telling how it works and what it looks like process-wise from customer perspective). It is important that at this point you still do not “sell”, just take time to explain Agile. Get feedback cautiously and to see if customer gets it. Continue explanation until he gets a full picture and feels confident with “mechanics” described. It is also important not to overdo it: it should be easily understood, sound light-weight and non-technical at all;
3. Step forward: offer first planning session for free (this works). This will help customer to both get more involved and feel more secure moving forward. Explain that by this you’ll mutually try collaboration with each other “softly”.
4. Involve (offer help): some clients want to (or like to) develop specifications on their own, some want to have contractor or 3rd party side PO doing this. In both cases customer needs some help getting started with story writing as it requires knowledge and practice.
5. Agree on conditions of satisfaction of each feature (aka Definition of DONE), since it will have an impact on estimations. Do not be technical here if you deal with business people (or be if you asked to explain it to CTO or a tech guy). Again be cautious here: some tech guys have their own opinion on what is important (is not) that is hard to change (and also wrong). It may be that you end-up knocking into the closed door if you start offering without asking what is considered as important first place.
6. Follow up after first planning session by helping to re-calculate to contract details:
- story points to time, knowing team baseline (assuming established team with agreed baseline of estimation);
- sprints required (knowing team average velocity) to the budget required;
It may be required to estimate entire scope. There are known techniques to do so. Goal here not to be exact (since you’ll never be) but to create feeling how much features customer gets approximately for a single sprint budget and/or how many sprints it will take to cover entire project. Usually this impresses (because Agile teams are way more faster than others). Then move forward and SELL!
7. Sell: stress that with Agile business is riskfree, since your customer will:
- avoid big-bang integration and “surprise parties” (by releasing as early as possible);
- observe potentially shippable software every sprint, having all required qualities-in (DoD);
- be able to adjust what features are most beneficial per sprint and ensure that team working on top important ones;
- be able to get end-user experience early to steer the product in the optimal way further;
If you’ve done everything correctly already here you should have READY customer. But he’s not fully there yet (or still has some doubts). Stop. Ask for doubts directly. Take your time to explain. Continue until all doubts are addressed. But you need a final “stroke” make customer feel more confident.
8. Pause (optional): there are two options how to continue at this point.
- Let customer “sleep over” with everything above (I usually do that), but it depends on what extent is your customer “boiled” here. Short waiting is good, because it lets sale process within customer’s organization to take place (aka “inside sale” stage). Involved managers discuss here and come to the point to sign/not to sign contract with you.
But here’s the trick I apply: you should try to know by when decision shall be made and act a bit up-front in time (#9). Because if decision is made it may be too late (in many organizations it usually is).
- Continue if you sure customer is ready for another “strike”;
- option to terminate contract at any time after sprint review session (with some benefits for you, of course).
- option to swap features and do changes in scope at any planning session.
10. Close your deal.