Ted says: Clients don’t always say what they mean. This is 100% true. My experience is that the majority of all people in business can’t fully and clearly articulate their thoughts, either verbally or in writing. Compounding this are situations where the client isn’t 100% honest and forthcoming; these run the range from simple cautiousness to outright deceit. Thus, you typically can’t take a client’s statement at face value.

Furthermore, even if a client can say what they mean, they may not mean what they actually want. And, even if they mean what they want, they may not actually want what they need. It’s the need that should be fulfilled, but there’s a lot of obstacles in the way.

To make matters worse, these obstacles are often multiplied by the numerous layers of “clients” involved. Here’s an example based off a real-world situation (the one I was in until recently):

1. The implementor gets requirements from his immediate boss.
2. The boss gets the requirements from the business/marketing/client relations department.
3. The client relations department gets their requirements from a 3rd-party development company (who is subcontracting part of the work to the implementor’s company)
4. The contracting development company gets their requirements from the actual client.
5. The client gets their requirements from the users.

It’s easy to see how confusion and misinformation can affect the requirements when there’s this many stages between the producer and the consumer of a piece of software. That’s why it’s important to do a thorough review of a particular request to verify that the sights haven’t drifted too far off the target.

I like mining as metaphor. There’s a nugget of gold buried in a mountain of communication. You need to dig away all of the useless rock in order to find it. As you dig, you’d better be setting up struts of solid reasoning to keep it from collapsing on you… and you’d better be digging in the right direction, or else you might miss the prize entirely.

Bruce responds to my prior post on requirements:

…I think you also have misinterpreted the user’s statement of the requirement.

Ted’s discarded first sentence IS a problem statement, but only for the second sentence (password confirmation field).

I don’t think the last sentence is a goal for the two requirements, in fact it has got nothing to do with problem statement. Interpreting it as the goal causes your question 5 to yield a negative answer.

The last sentence is (I think) a statement of a second problem, which leads to the second (but already stated) requirement. I would interpret the paragraph (briefly) as…

I didn’t really put any interpretation into the validity of the first and fourth sentences, nor did I attempt to answer any of the questions I asked. I just used them to illustrate the questions & types of statements themselves.

However, Bruce’s disagreement shows exactly the kind of process I was looking for when assigning qualifiers and questions to the sentences in the first place. He brings up valid points which prompt further action:

1. acceptance (if everyone on the team is convinced he’s right)
2. counterargument (if someone on the team thinks he’s wrong and can explain why), or
3. clarification (go back to the requirement writers and ask for more information to confirm or deny the assumptions we’ve made

The last two actions restart the process until full agreement is achieved. If you have enough people with good reasoning skills and tenacity to see disagreements through until they’re resolved, then the results of your analysis will probably be very close to the hypothetical “most correct answer possible.”

Along the way, all of your requirements, problem statements, and goals stand a good chance of complete replacement. That’s a good thing — if you’re doing the wrong thing, it doesn’t matter how well you do it, you’ll still come out with a poor result.

My old boss, “Teflon” Ted, has written a great post on producing “digestible” requirements:

I commonly get “requirements” documents from clients that read like a college book report, just pages and paragraphs of disorganized stream-of-consciousness ramblings. When this happens, I use a little trick to restore some order to the chaos. I break it down into one long checklist of digestible tasks.

He then illustrates his process for taking a verbal description and refining it into a beautifully clear and concise list of tasks. It’s well worth a read.

Lately I’ve been getting back into the requirements ends of things after years of being implementation-only, so I’ve been especially interested in this sort of topic. I think I’ll adopt Ted’s checkbox method straight away (it’s certainly easy enough to do so), but I would like to expand on it a bit.

For starters, let’s take his example verbal/written requirement:

“We’re tired of users mistyping their passwords and not being able to access their new accounts. First of all, we want to add a password confirmation field to the sign-up form. Secondly, we want to force them to pick a password between eight and twelve characters. This should make their accounts a little more secure.”

Aside: I think he’s being extremely generous with the example requirement here. I’ve dealt directly with some of the requirement text that he’s been involved with too, and it’s usually a lot worse than this in terms of length (either overly wordy or overly sparse), clarity, and grammar/spelling.

Ted splits it into four sentences, and then drops the first and the last, neither of which are actually requirements. The two remaining sentences are then trimmed down and split up into action items and assigned check boxes.

That’s well and good, but I’d like to take a closer look at those two dropped sentences:

We’re tired of users mistyping their passwords and not being able to access their new accounts.

…and…

This should make their accounts a little more secure.

These are definitely not requirements, if you define “requirements” as “items to be acted upon.” However, they are, I think, important, and deserve to be included in a formalized / reorganized specification.

So, if I were to improve upon Ted’s method, I’d then restate the first and fourth sentence as:

• Problem: Users are not able to access their accounts due to incorrectly answered passwords.
• Goal: Make user accounts a little more secure.

From here, we can then ask several important questions:

1. Is the problem clearly stated?
2. Is the problem actually occurring?
3. Are the stated (assumed) causes of the problem correct?
4. Is the problem worth solving (or at least worth investigating further to determine the costs of solving)?
5. Does the goal really address the problem?

If you get negative answers to any of these questions, then the requirements need to go back to the submitters for more discussion before the action items are refined further. If the problem and goals aren’t solid, then it won’t matter how well the requirements are organized and implemented; the whole thing will fall apart at the foundation anyway.

Once that’s done, you can then refine the requirements, and then ask:

• Will the action items, if implemented correctly, achieve the goal (and thus solve the problem)?

Of course, all of this work should already be done in advance of anyone in the implementation department (ex: software developers/designers/architects) gets near it. That is to say, the people in the business/marketing/management department should have already asked and answered these questions. However, it’s been my experience that pretty much everyone with a non-technical background does not (and sadly, can not) perform this kind of investigation to an acceptable degree… and thus the people lower down the chain have to compensate.

Microsoft is going to set up shop in Vancouver. One of the reasons for doing so is the more favorable immigration policy in Canada:

The Vancouver area is a global gateway with a diverse population, is close to Microsoft�s corporate offices in Redmond and allows the company to recruit and retain highly skilled people affected by immigration issues in the U.S.

This is a good thing for Vancouver and Canada, a big win for those who favor relaxed immigration policies (such as myself), and a big slap in the face for those in favor of tighter immigration controls — both for economic and homeland-security reasons.

There are smart & talented people all over the world. Those people may not be able to do the work they want to do in their home countries for a variety of economic and political reasons. Many of those people aren’t allowed to work in the U.S. due to the American love-hate relationship with immigration; this practice will allow them to work in a similar (better?) environment. While they do that, they’ll draw a salary (which is largely made up of U.S. money) and spend most of that within Canada (on taxes and domestic purchases).

Microsoft is showing that it’s not just trying to lobby for an H1B cap increase (as many have claimed): they’re serious enough about a real problem to take some actions outside the realm of the U.S. Government. The message to the American closed-border crowd is very clear: current policy is detrimental to business, and if it’s not corrected the U.S.A. will be loose out in the long run.

Work is on the “down” part of the roller-coaster again.

Craig: it’s amazing how quickly a culture of getting things done right can be undone
Ted: yup, i was just envisioning the line chart in my head of [their] productivity slowly sloping upwards and [ours] dropping like a rock
Craig: yeah
Craig: are they actually getting their act together?
Ted: relatively
Craig: minor progress is still progress
Ted: i have restored order to the chaos, but order is a six pack away from being beautiful

In my experience, the default state of any organization is to be screwed-up. It doesn’t have to be that way. Most people don’t realize that.

Guy Kawasaki is another one of my favorite bloggers (of the ones I don’t know personally). He’s a technically-savvy business guy and venture capitalist. To me, he represents the “other side” (ie: marketing) to a business (versus the technical/implementation/operational side that I’m on most of the time). Unlike many people in that industry though, he’s thoughtful, logical, and eloquent. Today he writes about the things websites/companies do to ensure that potential users leave and current users remain frustrated. Here’s an excerpt:

2. The long URL.When you want to send people an URL the site generates an URL that’s seventy characters long - or more! When you copy, paste, and email this URL, a line break is added, so people cannot click on it to go to the intended location.

…

The justification often goes like this: “We create a long URL because people with Crays might break our code and see private pages. Seventy characters that can be twenty-six lower case letters, twenty-six upper case letters, or ten numbers ensures that no one can break our code since the possible combinations outnumber the quantity of atoms in the universe.” This is what keeps sites like TinyUrl and SnipURL in business.

This is the sort thing that usability evangelists like Jakob Neilsen have been saying for a while now. The significance, I think, is that now marketing-focused people like Guy are beginning to take it seriously, and speak of it in terms of customers, competition, and money. Guy reaches a different audience than do those that normally speak on subjects like this, and so it helps spread the word to the people that matter. That’s a good thing.

I see lots of great one-liners go by from time to time, especially relating to business. Now that I have a blog I have an outlet to share them with the world (or at least the 3 people who read it :-P).

This first one happens to be one of my own; modesty be dammed.

[coworker]: ok wasnt sure if that was the final decesion
Craig: No decision is “final”, it’s just “most recent”

I got this from the one-man-show behind my new VOIP/toll free/calling card service, Les.Net:

<bastard operator from hell mode: ENAGAGED>
Please do *NOT* call if you are having problems.
Especially, do not call to complain or ask if there is a way to fix it temporarily.
Each minute I spend on the phone explaining things, delays the final solution.
I realise that your communications is important, but you will just have to cope in the meantime, sorry!
I can understand if people would like to cancel and find another provider.
I will process any such request on the weekend if you choose that direction.
<bastard operator from hell mode: DISENGAGED>

(Text is his, the link is mine)

I’ve been with this guy for a week now, and it’s been a battle of the pros and cons

PRO:

• He provides great features: he’s basically a VOIP & DID (ie: phone number) provider, but he covers all the related-feature bases. He allows you to use softphones or your own ATA. He provides IAX for Asterisk.
• He doesn’t try to lock you into a service plan or force you to buy specific hardware/software, unlike many VOIP providers (I’m looking at you Vonage
• His prices are great across the board.
• He explains what his fees are up front, and doesn’t add any “taxes” (other than basic GST).
• He provides phone numbers (including toll-free ones) all over the place.
• He allows lots of customization in your service.
• If you email him, he’ll respond, usually pretty quickly. There’s no talking to a phone monkey; you get The Person In Charge.
• He’s technically very competent.

CON:

• Because he’s a one-man-show, he gets overburdened easily if things go badly.
• There are, on occasion, service problems, like I’m having now. (He says these should be fixed in a couple of days.)
• He’s weak on customer-handling; see the quote above. It doesn’t bother me so much but it might for some people
• He doesn’t explain anything up-front. If you don’t know much telephony and/or can’t be bothered to learn, this service is not for you. (Fortunately, if you ask a technical question, he’ll answer you well; I haven’t tried a newbie question yet.)
• His website is really bad from a usability standpoint; it doesn’t help the user perform tasks much.
• Lots of features, both in the service or in the website, are “in the next version.” We’ll see how that goes.

At the moment, the “pro” side is still winning out. I think the fact that he’s one guy (and a techie) attempting to run a good business (and just needing some polish) makes me more forgiving of him.