coneblog

I’ve been reflecting about your questions in our talk yesterday. Here is my understanding of your concerns:

You believe that best practice is to have all issues nailed down, and all the pieces in place before we start the project. This is based on your experience that questions and uncertainties in front of the customer cast doubt, and put the project at risk. Your goal is to take a balky customer down a known process to a well-defined endpoint.

My situation is different. My goal is to refine an undefined process so that it can be completely nailed down, and go in easily the next 30 times, while taking into account a wide range of variation in customer situation.

You suggest that I should get things better defined before I go to the customer, and that otherwise we are flying by the seat of our pants, and figuring out things in front of the customer. I work differently…

Here is some of what I’ve learned, through making every possible mistake:

• The big risk to a project like this is getting the software or process wrong, and not knowing this until late beta or later. The later we find it out, the harder/more expensive it is to fix, whatever it is. Then you find yourself in those uncomfortable situations where you know you have a problem, the customer knows this also, but you have to soldier along and push it thru, because it is too late to change it now…
• Sitting here in the office thinking/talking about it takes us only so far – the risks are the things that we don’t know about or haven’t put together. Or, what issues do we not yet have on the issues list that will bite us later? I want to know the issues ASAP, so I can address them.
• The benefit in going to the customer as soon as possible is that, through reviewing preliminary versions of software and processes with the customer, we identify the issues early enough to address them properly before we start the Beta. The questions that we have not yet asked come from working with the customer.
• The fallacy around figuring everything out before going to the customer leads to several problems: a) We get entrenched in our model of how things work, and don’t listen when the customer tells us otherwise; b) We delay the inevitable collision with reality, and push out the date when we have all issues identified and resolved. c) We miss an opportunity to work collaboratively with the customer, and enlist their expertise in identifying and solving problems

I hope this gives you some perspective on why I am doing what I am doing.

Larry Cone