A customer struts into a car dealership, slams a 200 page requirements document down onto a salesman’s desk, and triumphantly declares “I know exactly what kind of car I want to buy.” The startled salesman opens the document to a random section and starts to flip through a few pages that describe a lug nut in excruciating detail. He looks at another random section and sees requirements about how the steering wheel should be joined to the steering column. After regaining his composure, the salesman looks up and says “from this document, I can definitely see that you are looking for a car. What do you want to use it for?” The business analyst suddenly looks confused and says “I don’t know. I don’t drive.”
This is not just a lame joke. It describes a scenario happens all the time in CMS selections. There are two main problems here. First is the obvious problem that the customer believes himself an expert in cars because he has done a ton of research but he doesn’t have the critical experience of having driven one. He can name all the features of a car and knows what they do but he hasn’t had to use them. The second issue is more subtle. His 200 page requirements document is more like a design specification for a product that has already been built. It goes into details that are unnecessary like how the steering wheel must be connected to the steering column. What kind of penalty does he give if the steering wheel is connected in a different (and perhaps better) way? More importantly, there is no way his requirements document can be exhaustive. It would really have to be 20,000+ pages to cover every detail with same depth. So entire aspects of the car are probably omitted. Maybe it was something important like which side of the car the steering wheel is on. Rather than try to design your own car in a vacuum and then go around and see which one matches it, it would be better to draw up some coarse filters (price, intended usage, etc.) and then look at cars that passed the filter in their totality and see which one feels right.
This sounds obvious for car buying but you would be surprised how many CMS buyers collect requirements like that car customer; Or do the abridged version where they just name countless features (which in car shopping would produce a list like “6 cup holders, 1 gas pedal, 1 brake pedal, 1 clutch (optional), 5 gears, 3 windshield wipers, 6 windows, 4 wheels, 4 tires, 1 spare wheel/tire … “). In many cases the requirements are gathered by people who have never used, nor intend to use, the CMS. They can’t paint the bigger picture of the user, the task, and the content.
By focusing on how people work, rather than the features themselves, CMS evaluation criteria can identify features that are important and with enough context to understand which implementations of that feature will make it useful. In the car dealership story, if the customer walked into the dealership and said “I drive like a maniac and the wheels of my last three cars fell off,” the salesman would not only know that the customer needed lug nuts but really beefy lug nuts, a good suspension, and perhaps a driving lesson.
Scenarios are the best way to capture this context for a software selection. A good scenario will describe the intent behind the task (what is the user trying to accomplish?), the context (what time, resources, and information does the user have?) and the flow (how does the person work? Who else does he need to collaborate with?). In the process of documenting a scenario, a number of features will be identified — features you might not even think of in a requirement brainstorming session. After writing a scenario, I typically list features at the bottom of the scenario to call out what functionality was used. Scenarios don’t have to be long or comprehensive. Usually 1/2 to 1 page will capture enough of the story to understand what needs to happen.
To beat on the car buying analogy once again, you could think of a scenario like the route for a test drive. If you live in a city and rarely use a highway, the best test drive would be to drive in traffic and try to parallel park and park in your neighborhood parking garage. That would be more informative than driving on the interstate. If you test drove all the cars on the same route you would notice some big differences; like that you can park the Honda Fit in a compact car space but you can’t even get the Ridgeline into the parking garage because the turning radius is too big. Your average car dealer probably will not give you much flexibility on your driving route, but your CMS vendor will (or should). Use that access to your advantage and create the most realistic driving conditions possible.
The car buying analogy breaks down in one key area. When you buy a car, you sign the paper work and then you drive it off the lot. Content management systems are not like that. Before you can use a CMS, you need to implement the software to support your content, processes, and web design. You need to configure, customize, and extend the platform. Scenarios will help this process because, once you buy the software, they turn into the user stories that will drive your implementation planning and long term road map. Some user stories will be achievable by configuring out of the box functionality; others will take more effort.
So when you find yourself slogging through a spreadsheet with hundreds of rows of requirements, think of that car buyer and ask yourself “are these requirements really going to help me find a CMS that I will be able to use to manage my website(s)?” If you are honest with yourself, the answer will probably be “no.” If it is “no,” put away the spreadsheet and start writing scenarios.
