August 2, 2012
Back To Basics #2 - Close Customer Involvement Is KeyThis is the second post in a series of ten aiming to articulate basic principles for software development without the usual buzzwords, hype and fairy dust that gets liberally sprinkled when folk talk about software.
In my humble opinion, when a customer does not make sufficient time to give input or feedback on a software product or system, it's pretty much the worse thing for your whole endevour.
By "customer", I mean your actual customer. The person with ultimate decision-making responsibility. Not someone delegated to act as a sort of proxy to the decision maker.
The customer is someone who holds the power - the ultimate power - to decide what the money gets spent on, and whether or not they're happy with what the money got spent on.
They shouldn't need to check with a higher authority. If they do, then they're not the customer.
We need to distinguish between customers and people who can often get confused with customers.
A user isn't necessarily a customer, for example. They may be the customer's customer, but they're not our customer.
A business expert isn't necessarily a customer, either. They may have a more in-depth understanding of the problem than the person making the ultimate decisions - that in itself is a red flag for the customer's business, but that's a different story - but if they have to refer back to someone with more authority for decisions to be made, then they're not our customer. They're an adviser to our customer.
Lack of customer involvement is often cited in studies like the CHAOS report as the most common cause of project failure. (Although they, too, confuse customers and users in their report - and they have some pretty backward ideas about what constitutes "success", but by the bye.)
As we'll discuss in the next post, feedback cycles are critical to software development. Arguably the most important feedback cycle is the one that exists between you - the developers - and the customer.
If you have just completed a feature and require customer feedback on it before moving on, the sooner you can get that feedback, the sooner you can move on.
If you don't get the feedback quickly, it can be a blocker to development. What teams tend to do is move on anyway. But they're now building on an assumption. Some teams have to wait weeks or months to get that feedback, and that's weeks and months where they're merrily wiring all manner of gubbins into a foundation made of "maybe". If that "maybe" turns out to be a "no, that's not what I meant", or a "it's what I wanted, but now that I see it made flesh, I realise it's not what I need" then - oh, dear...
Software development is a learning process, and feedback's the key to making it work.
What can often happen is that the real customer's far too busy and important to spend any time with you, so they delegate that responsibility to someone who works for them. This is often signified by months or years of things appearing to go very well, as their proxy gives you immediate feedback throughout the process.
It usually hits the rocks when the time finally comes for your software to be put in front of the real customer. That's when we find out that software can't be left to someone else to decide how it should be. It's like paying someone to tell you if you like your new hair style.
Teams can waste a lot of time and a lot of money chasing the pot of gold at the end of the wrong rainbow.
You need to find out who your customer really is, and then strap them to a chair and don't let them go until they've given you meaningful answers.
Here's the thing. Most customers are actually paying for the software with other people's money - shareholders, the public, a community etc etc. They have a professional responsibility to be a good customer. A good customer takes an active interest in how the money's spent and what they get for that money.
If you're a movie studio executive with ultimate decision-making responsibility for a production, you would ask to see frequent evidence of how the production's going and how the final movie is going to turn out. You may ask to read drafts of the screenplay. You may ask to see videos of casting sessions. You may ask to see daily rushes while it's being shot. And so on. Basically, with other people's money at stake, you'd take nobody's word for it.
It doesn't mean you need to take creative control away from writers, directors, actors, designers and others involved in making the movie. It just means that you are aware of how it's going, aware of what the money's being spent on, and in an informed position to take the ultimate decisions about how the money's spent.
If you want to really improve your chances of succeeding with software, then you need to keep your customers close.
If the customer is unable or unwilling to make that commitment and give you timely feedback and be there when decisions need to be made, then it's probably not going to work, and they're probably going to waste their money. Do yourself and them a favour and can the project. It's obviously not important enough to warrant the risk.
Posted 10 months, 6 days ago on August 2, 2012