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.
Related posts:
- In-Context and Power User Interfaces: One for the Sale, the Other for the Content Manager A dirty little secret in the CMS industry is...
- Leading requirements You have just mentioned that maybe the pain you...
- Is this CMS worth the money? During any CMS selection, it is fairly common to...
- My Microsoft Office CMS Analogy The other day I was trying to describe to...
- How to Select a CMS A while back, I wrote a post on selecting...
Seth – this is an excellent post. Thanks for expressing it so clearly. I suspect you’ll find firms like our parroting your “buying a car” analogy for years to come.
It strikes me that the industry would benefit from someone writing a book that compiles a hundred or so common publishing scenarios. (When you’re done, call me – I’ll buy the first copy).
rand
Hi Seth,
a very suitable analogy then a very valuable and effective recommandation for customers.
I loved your first paragraph because this is something we, software vendors, have seen countless times, with analysts and /or customers.
To be specific, I would have add to this little skit the following answer from the car dealer “by the way, your specification is impressive, awesome, terrific… but I can’t find out one single car on the market built like described in your 200 page requirements doc.” and this would reflect the actual situation we have to deal-with, every week when receiving RFPs.
RFPs built on ideal requirements and a collection of what is supposed to be best practices of the industry, the best technologies, the best patterns tends to create
- unrealistic requirements, if even consistent, from the customers
- over selling, buzz words, hyper marketing and dummy implementations just to be able to check the “yes” boxes in the RDFs, from the vendors.
In early 2009, when CMIS was in a draft stage only, and far from being released, we’ve seen customers requesting for it (and unable to explain why they needed it), and some vendors alleging to have already implemented it… just one example between many other ones.
Seth-
Great blog. This is why companies need to hire you and not just throw together an RFP checklist of mechanical parts. We are always pushing to better understand the driving business needs of our clients and while they of course include some technical requirements, those that have a well-defined grasp of their optimal bottom-line driving objectives and run their selection process accordingly set themselves up for success.
Thanks for this post, Seth!
Very much to the point.
An excellent analogy. Unfortunately too many consults and their hiring managers hang their hats on RFPs and Qs. How do we change this buying behaviour.
I wish I knew. I have clients that know the status quo is wrong but can’t break it. Their bosses insist on continuing the dysfunction because it is what they know.
Seth,
Nice analogy. Near the end where you write that, the analogy breaks down but I don’t think it does. Could you image if after the you purchase the product the dealer just gave you all the parts to the car, including all the parts for the EX, GL, GT and Touring versions then say something like now you can make it do what you’d like. Then you’d have to call an assembler to help you assemble the car components into something that meets most of your needs. Why pay for that when you can just go purchase the components and assemble an open source Segway, http://www.youtube.com/watch?v=edNx5v0Y0N4 or go with a less expensive, less complicated Bajaj Chetak. They all get you from point A to point B right.
Cheers!
So true!