Leading requirements
You have just mentioned that maybe the pain you are feeling in managing your web content may be eased by implementing a web content management system (WCMS) and, all of the sudden, I.T. paratroopers are sliding down ropes with their software selection methodology and other "artifacts." You get suspicious as you recognize the same faces that "helped" you the last time around but are reassured that they have "learned aLOT" from their recent time and expense system procurement.
Spreadsheets are opened and fingers are poised over keys. They cue you with "R00001. The system shall be....?"
"easy to use?" is your diffident response.
"R00001. The system shall be easy to use. OK. R00002. The system shall...?"
Three months later, you have a spreadsheet with a thousand rows of "shalls" that any WCMS vendor (plus most ERP vendors) will say "yes" to. But, worst of all, they mean nothing to you. You are now back to precisely where you started.
What happened here?
Generic requirements gathering processes are self absorbed. They are optimized to comprehensively find business requirements, not understand them within the context of business goals. And the more the requirements are abstracted from the goal of managing content, the less they mean. Quantity and completeness are measurements of success rather than usefulness. What is more, most generic requirements analysis techniques are designed for building custom software rather than selecting software. While custom software development goes from requirements to design, when implementing an existing WCMS, much of the design is already in place. The trick to finding a WCMS is to match your needs with a pre-existing design. Generic requirements are an indirect path to that result.
In a WCMS selection, requirements gathering should stop when you have enough information to filter down the marketplace for a (3 or 4 product) short list. After that, the selection process takes a more experiential aspect where you look at the usability of the software and organizational compatibility with the suppliers that will help assemble the solution (software vendor and systems integrator). To be sure, this part of the process seems overly subjective to some - but, honestly, how objective is an aggregated "user friendliness" score of 3.2?
I like to focus on what I call "Leading Requirements." A leading requirement has at least one of two characteristics: it is important to the organization and/or it is a powerful filter on the marketplace. To be important, a requirement must critically affect daily usage or primary functions of the system. Powerful filter requirements get to the big demarcations of the marketplace - things like baking vs. frying, technology stack, content modeling, content reuse, workflow modeling, licensing strategies, etc. By focusing on leading requirements I can usually get down to 3 or 4 viable solutions that (based on industry gossip) appear to be working well at like companies and are sustainable.
By focusing on leading requirements, I can afford to take the time to document what each one really means. For functional requirements, I write "usage scenarios" that describe users using the solution to complete a business task (like publishing an article). At the bottom of each scenario, I list out the discrete requirements that were identified. These 2-4 paragraph narratives are then useful in the demo process because they become the script for the customized product demonstration.
After the product is selected, requirements are refined to determine what features will be enabled or implemented (and how) in the first release (and subsequent releases) of the system. At this point, you know the platform you are building on so you can explain requirements within the context of the native capabilities of the software. You can also adjust scope to leverage out of the box functionality and even prototype to clarify what you are talking about.
Focusing on leading requirements is not easy. It requires intimate knowledge of the business processes and also the content management industry. Still, there is no faster way to get to a short list of viable products and deeply evaluate them. If you want to learn more about leading requirements, I am teaching a workshop at the Gilbane conference in Boston. Will I see you there?