Development restaurant - success is making your customer a star

In my previous post it kind of felt as if I was blaming the customers for wanting to know what something costs and how long it will take. I don't really want to blame others, change your own ways first!

The IT industry is heavily (at least in Sweden, where I work) based on companies hiring consultant companies for building their IT systems. Consultants help to gather requirements and then making the estimates and project schedule and finally (hopefully) do the work. I work as such a consultant. And I don't want to "blame" my customers. The problem on how we do software projects today may be our "fault"?
Why?
Because we almost want our customers to ask for price and schedule.
What!? Really?
Yes. Because we, as consultants, puts great value in making a good deal for our own part. It's usually a huge success (and maybe you get a bonus?) if you bring home a $100.000 project. But is it a success for our customers? Isn't it something else we really wanna do? Shouldn't our goal be to make our customers more valuable? Make them stars!

So, we need to change as well. Maybe we need to change first?

Another important thing; it's also about trust. We need to gain our customers trust. And a good plan and a  professional looking time schedule is a way to gain that trust. Making the uncertain customer feel more certain (which is actually wrong, you should be open with the uncertainty, embrace it, deal with it; another topic...). But I believe there are other ways, better(?) ways to gain trust. At least it might be worth trying.

We need to shift focus from large to small (see Neil Killick's post). Small deals might be better than a big one.

One way to explain what I'm thinking is to make an analogy myself (just like the customers "buying a car" analogy). It got me thinking about when you visit a restaurant you have never visited before. Maybe we should be more like waiters and chefs on a restaurant? Make our customers feel like kings and queens and enjoy the visit at our restaurant!
As a customer (visiting a new restaurant) you don't know what the food tastes or looks like. But you know what you order and you know what it costs (it's on the menu) and you know, roughly, how long it takes to get the food; at least you know when you get really frustrated if getting no food...
And if the food looks great and tastes delicious you will most likely visit the restaurant again, or even recommend others to visit. Maybe you bring more guests next time?
This concept is not something new to the restaurant business. It's actually the core idea of running a restaurant.

Could we do the same?
Offer our customers a menu? Just like visiting a restaurant. A taste of what we deliver? Knowing what it will cost. The menu might offer things like high quality, fast delivery, small budget etc. - the customer can choose, but one thing is a trade off for another. Or should it contain something else? The concept isn't very well thought through yet... :-)

Then we need to deliver something valuable, a whole meal, not just bring out some boiled potatoes.
And if it tastes good the customer can come back tomorrow (you need to eat everyday). And the customer probably comes back to visit us, now that they know what it's like (gained trust). Or they can visit another restaurant if they didn't liked it.
They don't have to book (and pay) your restaurant for the next coming months (without knowing what it's like), it's just one (bad?) meal. No big deal, if so. But if they liked it they can book tables at our restaurant every day for months or years to come. And maybe get a discount if they choose to do so?

The analogy isn't perfect, as always, but the bottom line is I think we need to change the way we offer our services. It's not the million dollar contracts that are most valuable for our customers (even if it might be for us), it's what value we bring them. Make them stars! And if you have made them stars... then, and only then, you get your bonus.

At least we should always give our customers options. So they (or even better: together with us) can choose the preferred way forward. Knowing what they are trading off by choosing which option(s) over another. Read more about #impactmapping at impactmapping.org if you want to know what I'm talking about.

"Wouldn't you want to know what it costs?"

When talking about the #noestimates subject, one reaction (or analogy) I quite often get is "If you would buy a car..." (you can put in anything here really) "...wouldn't you want to know what it costs?". Or similar "If you would remodel your kitchen, don't you want to know when it is finished and what it will cost?"

Yes, of course I would, there is nothing wrong with knowing, roughly, what something costs. But when it comes to creating software (building a system with software) the analogy doesn't quite fit.

Here is what I think:

First. As an individual you seldom make investments that you expect to payoff. There is almost never an expected return of investment. At least you don't make the investments based on it. But as a company, you should! If you want to invest in something, it must be valuable. Otherwise you probably shouldn't invest. Sometimes it's difficult to calculate the payoff for the investment, but it is always good to discuss it; what is the payoff if we build this software? That should at least have higher priority than what something costs. Because, if something costs $1000 and the expected return is $2000 or if it costs $10.000 and the expected return is $20.000, what would you invest in?
And if it is unimportant what the return of investment is, why is it important what it costs? (And you should then really try to shift focus).
When it comes to the question "How long will it take?" the obvious response is "Does it have to be finished at a specific date?" Sometimes it has to, sometimes not. There is quite often other resources that has to be booked or reserved (internal and/or external), that is important. But try to delay those decisions as long as possible. So the response might be "How far in advance do we have to book resources?".
And again, if something takes six months and returns $1000 or if it takes a year and returns $10.000, what would you prefer? And remember the old saying: Noone remembers a system delivered late, but everyone remembers a bad delivery.

Secondly. The analogy is wrong in another way. Building a system isn't the same thing as buying a car (or anything). Software isn't a "dead" thing. Software has a soul, a heart, a life. So a better analogy is "How much does it cost to buy, breed and educate a dog?" That is really hard to tell, it depends on so many things. Especially since dogs are individuals, just like software tends to be (or at least should be).

See my other blog posts Developers are not carpenters and Customers are carpenters.