As we know, software projects fail at alarming rates--typically somewhere around
80%. There are many reasons for this. One reason is that the programmers get the wrong
requirements. Changing requirements and scope creep are separate issues that need addressing
on their own, and I'm not going to talk about that right now. There are more things afoot
with this Getting the Wrong Requirements business. Often, the programmer or analyst
interviews with customers are simply ineffective. The interviews don't get to the bottom of
the issue, or we come away with an incomplete understanding of what the customer wants.
In Extreme Programming, there is the concept of the User Story, which is intended
to capture a use case in its simplest form, and leave details open to continuing
conversations between the customer and the programmer/analyst. The idea is that
requirements change, and because of that, our documentation gets out of date quickly,
and you have a lot of people trying to maintain documentation that generally isn't
trusted anyway (because it's known to often be out of date or incomplete), and that
such maintenance is, like, a waste of time.
I can see that. I agree with that, even, that it's good to focus on the software product, communicate through code, talk a lot with the customer, and not on chasing around these massive documentation tomes.
However. There are many problems here.
The first of which is that the "customer" doesn't exist.
The Customer Doesn't Exist
What we talk about when we talk about customers in software development is often this
necessarily idealized concept of the customer. As if there is one person who can answer all
of the questions. Who knows enough, is available enough, is approachable enough, is articulate
enough. Often the customer consists of more than one person. A committee of executives, perhaps.
You may need all of a few of them to get a decision or clarification.
It is therefore a good idea to get something more out of them when you have the opportunity
than a User Story card with some cryptic phrase like "[Make ecommerce here]" scribbled on it.
But even when we record enough about what the customer states, adjusting as requirements change, we still don't get it right. Why not?
I have observed that frequently customers will give you the Solution, but not the Problem.
This is a Bad Thing. It is your job to write great software, and the customer's job is to help you
do it. They help you do it when they give you the Problem, and you determine the right Solution.
You are a professional. That is your job. This kind of thing makes me nuts.
I don't tell the dentist where to drill, or if he really should give me a root canal or not. I do
as I'm told because I don't want my teeth rotting out of my head and on such matter he knows bloody
well better than I do.
Yet in IT we let customers railroad us all the time. The same customers who wouldn't dream of telling their dentists that the porcelain bridge is actually inappropriate in this case, and shouldn't he
really use this new polymer she heard about from her stock broker.
Notice in your customer's conversation whether they are giving you the Solution instead of the Problem. And don't allow it.
Everyone will pay later if you allow it. You'll pay, the customer will pay, the customer's customers will pay. It's part of your job as a developer/analyst/architect to notice this, put a stop to it, and _force_ the customer to clear her head and forget what all about what her 14 Year Old
Nephew Who Is Really Not Too Bad At Front Page And Had Some Good Ideas Regarding This told her she could do.
This can be surprisingly difficult. People don't like bad news. They don't like to pay for something they didn't choose. They might not trust you entirely, and think you just want to play with that new toy or get it on your resume.
But that's the name of the meeting in your little digital invitation after all, "Requirements Gathering". It doesn't say "Solution Telling by Customer Meeting". But in the current culture, Front Page is the New Word. Whereas in the 80's only a complete dumbass Luddite geezer didn't know how to use Word Star, and secretaries who took dictation went the way of all things, for the last few years we've been smack in the middle of in the age when only complete dumbass Luddite geezers don't make their own web pages with copied and pasted applets. They know all about it now. They just program their VPN with HTML and send it up to the HTTP and 6 phone calls later to a help desk or that 14 year old nephew and they're good to go. What that means for you 8 times out of 10 in that any given customer now feels sufficiently on top of things that they can tell you what it is they need. I just need a floating applet in the shape of a cube that I can rotate and get my files by clicking on them as the cube rotates around. I saw it at my wife's work, and that's just what I need. 8 times out of 10, that's not at all what they need.
Your Customer is Not Your Customer
Here's another strategy. Pretend, as you develop software and work in requirements meetings, that your customer is not your customer. It turns out that this is a very easy thing to do, because it is true.
Your customer's customers are your customers.
If your customer's customers win, your customer wins.
If your customer's customers win, you win.
If you're writing an ecommerce application, take care of the things that you know people who will shop at that site will need. They'll need SSL. They'll need encryption of stored data. Your customer may not mention this. If you know that your customer is leaving out things your customer's customer will need, get it addressed.
If your customer willingly and knowingly doesn't care about certain important things that your customer's customer cares about, consider stepping away from the project. It's Teenage Suicide (don't do it). Just because Sally customer doesn't want to pay for SSL every year and wants to store credit cards in plain text because it's six hours less you have to get paid to encrypt them, it's not okay to just agree. You're killing your customer's customer when you agree to work you know is a bad idea.
Customers all have Windows ME, and iPod Shuffle, and some old $30 Lexmark printer in their garage, and this entitles them to judge whether or not SSL is a requirement. It's idiotic. Yet we in IT put up with it, because it's easier to do it wrong and then gripe about it to our sweethearts who get to find out what heros we really are because we would never have been so stupid to use an Active X control when Flash can export XML.
If you're the guy who hangs around the garage telling the mechanic what to do, how about you stay home. If you can fix it yourself so great, then stay home and fix it yourself, and leave room on the mechanic's schedule for nimrods like me who only in the last 6 months learned the difference between a tire and a wheel. I need the slot, dammit.
You can recognize meetings where you're going to get the Solution instead of the problem in this way: as you are in the meeting talking to the customer, you find yourself nodding your head, saying little, things vaguely make sense--but the details are sketchy, and when you get out of the meeting you have no idea what the customer actually wants, why they want that, or how to build it.
You can recognize this kind of meeting if the customer is sketching forms for you.
If they are saying anything at all about checkboxes or applets or CSS or XML.
Requirements gathering meetings are not implementation meetings. Just forbid the use of implementation-specific terms unless it's part of the domain, or an absolute. Now one can't be rude, but you have to be disciplined enough to just strike these things from the record, as it were, in the Perry Mason courtroom of your mind.
So how do you maintain the discipline in these meetings, which can be deceptively difficult? It requires a paradigm shift.
In 1649, Richard Lovelace wrote a poem called "To Lucasta, on Going to the Wars". Here it is:
Tell me not, Sweet, I am unkind
That from the nunnery
Of thy chaste breast and quiet mind,
To war and arms I fly.
True, a new mistress now I chase,
The first foe in the field;
And with a stronger faith embrace
A sword, a horse, a shield.
Yet this inconstancy is such
As you too shall adore;
I could not love thee, dear, so much,
Loved I not honor more.
So what does Lovelace teach us about customers on software projects? That you must honor the customer by fixing their problem. Their real problem. Their real problem is not that they need hand holding. Or chocolates at meetings. Or someone who should know better to simply nod their heads in agreement with every utterance. We must not be afraid of our customer. Even if it's the boss. Sometimes if our customer is the CEO of our company, this can be difficult. I understand. It's our job.
They knew in New Orleans that the levees would break. Engineers told them. They made it clear. Years in advance. They could have fixed it. They were told how. The city and the state didn't want to spend the money. They feds didn't want to spend the money.
This frequently happens in IT. It happens every day. I understand. That doesn't mean we get to float through customer meetings griping under our breath that it'll never change around here.
No One's Customer
You cannot solve the customer's problem without solving at least a couple of IT's problems along the way. Frequently, companies are divided up for accounting purposes such that HR would have to pay IT for a project from their own budget. Sometimes this practice is so rampant that the departments are even divided into their own companies. That's fine. I'm not an accountant. But sometimes when this is the situation, we frequently find our IT infrastructure in shambles after years of doing projects for other departments. That's because everyone is our customer, but we're no one's customer. Your company may not like to pay for IT keeping up its infrastructure. They'll deploy Windows XP to 20000 desktops with no discernible improvements over Windows 2000 with the exception of the possibly useful feature of the built in wireless driver manager. But we can't upgrade the SAN. We can't afford another Admin. If you're in such a company, I can't help you. I don't know the cure. If you know the cure, let me know. Because we can't control that. It's not our money.
But the requirements gathering meetings, _are_ our meetings. Our name is on it. It's our shot to help call.
If your customer doesn't want to talk about security, because security is expensive, isn't sexy, and isn't even a _feature_ in the customer's mind, you must force the conversation.
You cannot love your customer so much, love you not IT more.
The customer doesn't want to pay Microsoft for 5000 seats in Active Directory. No one wants to pay Microsoft 5 cents for anything ever again. It somehow just doesn't seem right. But if they want indentity management, there's just no good way around it.
You know what the problems are going to be. The customer probably doesn't. You know that any website worth writing will be hammered non-stop with DoS attacks. Customers don't care. Because security is not the problem they asked you to solve.
In fact, as my friend Barney says, "security is never a problem. Until it's a problem." Then _you're_ the jerk who didn't impress upon me the dire need for SSL and data encryption--I _told you_ that security was important.
Have the conversation now. I just use security here for simplicity. The issue may not be security in your app. Maybe they'll pay for iris scanners till the cows come home. It's something else maybe. But I bet it's there.
I've actually found that there is little predictability in what customers will or will not pay for from project to project. Even the same customer. But I think I know why this is. I've found that this is generally because the customer wants what his golf partner (read Bourgeois rival) just got His IT Guy to do. Hm, you know I overheard in the clubhouse that the CIO of Dial is putting in RFIDs. I better put in some RFIDs too. Let's find something to put them in.
This all sounds so obvious. We all know this. But I see it day after day.
Do not agree to things you know you shouldn't agree to. That includes deadlines, cheesy specs, incoherent requirements. Later they're going to forget all about the fact that you "really tried" to get them to buy the firewall between the web server and the app server. You must make it clear: If you don't buy the firewall, your app will fail. It may take 6 months or a year, but it will fail.
And don't be that guy, the guy that lets the company shoot itself in the foot with your name. If it means you have to walk away, walk away. How many failed projects does it take before the customer decides that you're the common thread in their continual project failures? Two, max? Probably one.
I suppose when the fingers start pointing, and they eventually point at you, your can point at your analyst and your analyst can point back at the customer. And the world will keep turning. But it's not required that we're so passive. They want to know. They might fuss a lot, and really make it seem like they don't want to know. And once they know, they may still not want to pay for it. But then, at the least, we've done an honest day's work.
The onus is on us to get better requirements.
