The Customer Paradox

We all have customers. Some of them are real live customers, people we deliver a tangible product to in return for financial reward and others are merely the next link in our production chain. Testers, for example, are customers to developers.

The one thing all customers have in common is they are happiest when they are given exactly what they want. When I think back to the times I′ve been a customer, be it in a shop or maybe a restaurant, I remember how annoyed I was when given something I didn′t ask for and didn′t want. Even more annoying though, were the times when what I was given wasn′t what I wanted and it was what I asked for. This brings me to the customer paradox, which can be stated as, "the harder you try to define your customer′s requirements, the less likely you are to deliver what he wants."

This is especially true about software development and, in my opinion, it′s largely to do with the way we approach project management. Yes, you′ve guessed it, I′m having a dig at the waterfall again. That wonderful technique that decrees that you gather all the requirements from your customer before you do anything else in your project and then have no further contact with him until n months later when you are supposed to finally deliver exactly what you thought he asked for all that time ago.

Is it just me or does anyone else think this is an extremely risky way to run projects? Not the least because of all Barry Boehm′s familiar cost of change curve, where the cost of fixing defects rises exponentially as the project progresses from stage to stage. This phenomenon was documented over twenty years ago but, somehow, instead of making us change the way we do projects, it had the effect of causing managers to implement tighter controls and more documentation at the handover between each stage, thus increasing the cost of change even further. What a strange and complicated solution to a very simple problem.

Another consequence of following a waterfall type method is that because there is no customer involvement between the requirements gathering stage and delivery, you′re unlikely to discover that you′ve built the wrong thing until after you′ve delivered it to him. I think we′d all agree this is the worst place on the timeline to find out but it is a fact that the waterfall′s very nature leaves us open to the horrendous risk of discovering just that at the very place in the lifecycle where the cost of fixing it is at its highest.

But still we do it! Despite having dropped by a quarter in the last ten years, the project failure rate is still unacceptably high at around 66%. This and the proliferation of job advertisements requiring project managers with traditional (waterfall) qualifications, can only lead us to one conclusion - the IT world has gone mad. Repeating the same activity over and over again but hoping to get a different result each time is a symptom of insanity.

There are two things that you need to know before you can predict the cost of development in time and resources. This is true of the project as a whole and of each individual feature within it. These two things are the requirements and the technology. Put another way, what we have to do and how we′re going to do it.

If we know just one of these, the problem immediately becomes much simpler. Take ′hello world′, for example. For me, it is a simple matter to create a C program to produce the required output in either Dos or Unix versions of the language. I am familiar with the requirements, as I have done this program many, many times (I used to be a programming lecturer), and the technology, as I have also worked as a programmer in both environments. Ask me to do the same in a Windows form using C#, however, and it might take a little longer, as I will first have to learn C# and the .NET framework.

Now, I can′t say how long it will take me to learn these things. Probably not long to get me to a position where I can complete this trivial example but real life software development is a lot more involved. In the real world, it′s likely that I will have never produced the required feature previously. Why would I repeat myself, where is the business value in that? It′s also possible, certainly not unusual, that the customer isn′t able to give me absolute requirements. He might not even know what he wants until he′s seen what′s possible.

All of this makes software development a complex activity, with many elements of uncertain nature, which won′t be resolved until other parts of the system become concrete themselves. At which point the solution will begin to emerge.

One thing is for sure, ignoring uncertainty is the most ineffective way of dealing with it. Would you plan a garden party for next year in the UK and just hope it won′t rain? That is, in effect, what traditional project management does. We ask the customer what he wants, tell him when he can expect it and set to work with the expectation that nothing will change between now and the day of delivery. When it doesn′t work we do it again but this time we try even harder and the next time we′ll try harder still. Even though it doesn′t work, we keep on trying in the hope that one day it will.

There are other ways of doing things, though. Tom Gilb has been pioneering evolutionary project management techniques since the 1960s and the last ten years or so have seen a plethora of ′Agile′ techniques that follow his principles closely.

When we start the project, the target is blurry. We think we know what it looks like and we think we know where it is. Traditional project managers would steady themselves at this point, take aim and fire directly at where they think the target is, expending all their resources (ammunition) on getting straight there. Of course, once they reach the target, reality bites and they realise the real target is now crystal clear and nowhere near where they were aiming. This usually calls for a blame-storming exercise followed by extensive delays or even cancellation in the worst cases.

In contrast, an evolutionary approach would start off heading toward our blurry, unfocussed target but by using feedback to regularly check the position of the target, would allow us to re-align ourselves as we progressed.

It is a relatively simple technique and one that most people would claim as ′obvious′ but unfortunately, one not practised by many. It is a very difficult process to follow if you and your customer are locked into an agreement or contract that penalises one side for creating defects and on the other side penalises or even prohibits changes to the specification.

The evolutionary style of project management introduces options into software development and gives us the opportunity (but not the obligation) to do something in the future. Going back to our garden party, we could rent a marquee. The outlay wouldn′t be much and we don′t have to use it of it doesn′t rain. If it does rain, however, our party can still be a success. We can our options open and decide at the last responsible moment. This is a much better way of dealing with uncertainty.

In software development, if we can get our customer to calculate the business value of each requirement and prioritise them accordingly, we can make sure that we do his highest priorities and the most valuable features first. These are also the features that are least likely to change. As we progress and we continue to get feedback from the customer by demonstrating to him what we′ve completed so far, he is able to make better informed decisions about the remaining requirements. My experience is that projects worked like this follow the 80/20 rule. That is, around eighty percent of the total business value of the project is delivered by the first twenty percent of effort. From then on, the project follows the law of diminishing returns and we often find customers deciding all those fancy features they thought they′d really like weren′t really worth the cost after all.

This ties up with another study by the Standish Group of industry analysts that found that 45% of all features in applications were never used and a further 19% were hardly ever used. Probably caused, in my opinion, by developers and customers being tied into a contract that specifies delivery of everything from the outset. If we could follow the evolutionary approach and give ourselves the ability to make cost-benefit analyses throughout the development process, we would probably find ourselves not bothering to build those less important features. It doesn′t take a great mathematician to work out that if we left out the two-thirds of features that were never or hardly ever used, we could finish the project in one third of the time or, alternatively, do three times as many project with the same resources.

So there we have it. To give the customer what he really wants, we have to stop trying to rigorously define it at the beginning and make our decisions based on continuous feedback. If we do this, we could also find ourselves improving our productivity. Some development teams have already had major successes with this.

First published in Application Development Advisor