The Right Way to Select Technology, An Excerpt

After establishing a solid business case, enterprises will typically turn to assembling the oft-dreaded “requirements document”—or more accurately, a set of documents, spreadsheets, and diagrams that compose a multiheaded requirements package.

Large requirements packages actually provide a false sense of security. Modern digital technology entails real people interacting with screens. Technology selection leaders need to capture those interactive requirements, but also remain realistic at this phase about their inability to fully know what their enterprise really needs and will adopt eventually.

This section will show how long spreadsheets full of “what” requirements really don’t work, and instead will focus on “how” a solution might work. The best way to reveal key differences among suppliers is to craft narrative “user stories” with “personas” (rough equivalent to use-cases with actors).

In other words, tell testable stories. Business users have stories; so do customers, partners, developers, sysadmins, designers, auditors, and others.

This section will lead you through an approach to telling those stories in a way that’s more conducive to differentiating among technology suppliers.

Capture requirements that don’t suck#section2

A solid understanding of your organization’s requirements is essential to project success. Getting that understanding will involve information gathering from various stakeholder groups, potentially utilizing a variety of techniques.

Note that at this stage, your requirements should be business- and user-focused, rather than detailed technical specifications. (We’ll get to those in Chapter 6, “Ask Questions That Really Matter”). The final key step here is to analyze and prioritize your requirements, in order to determine which ones to emphasize in the RFP and subsequent demos and bake-offs.

How not to articulate requirements#section3

Whatever you do, avoid “check box” requirements sheets where you ask the vendor: “Can you do this, can you do that?”

As a practical matter, vendors have seen all these questions and have figured out how to check all the boxes. But what’s worse is that such spreadsheets convert the understanding of what should be a human-centered, interactive activity into a bloodless series of row-by-row activities better suited for robots repeatedly performing rote tasks.

The typical pitfall here starts like this: a business analyst (BA) goes around interviewing users and other stakeholders, and she ends up with a long wish list of features. Excel allows her to categorize those features, which is handy, but because of the limitless rows, her spreadsheet will tend to emphasize comprehensiveness over business impact.

To address the challenge of priorities, the typical enterprise process asks stakeholders to rank their needs, perhaps on a scale of 1 to 5, or using MoSCoW (Must Have/Could Have/Should Have/Won’t Have) or some other methodology. Not surprisingly, this generates a scrum where users compete to identify as many rows of “Must Haves” as possible.

Ultimately, someone will ask the BA to tie back each requirement row to the business case (remember that?), so she then spends several days building new tables and cross-references in Excel. Ultimately, reviewers find exceptions and variants for each feature, so new columns get added. Now the spreadsheet is too big to fit on a standard screen, let alone print out. It’s impressive … and impressively unhelpful.

The government agency with the massive checklist#section5

We once advised a major U.S. federal government agency to select a new portal platform as a hub for small business advice. We came late to the process after an initial round of vendor demos had failed to differentiate clearly among the bidders.

The problem was Excel. Or more specifically, the entire RFP as a 10-tab worksheet, with some sheets going hundreds of rows deeps. Most of the tabs held feature requests—notably categorized by agency department rather than customer persona—with a long series of columns annotating those features. (Our favorite: the ever-beloved “Must be easy to use” requirement.) Nearly all the features were listed as “must have.” They were rigorously cross-tabbed to a long-but vague set of business objectives, but otherwise there was no prioritization.

The vendors didn’t know what to demo, although several gamely tried. Mostly, they just talked about their (voluminous) proposal responses, most of which consisted of declaring, for each row, “We can do that!”

Ultimately, we were able to recraft a more user-centered approach, with a narrower scope, that vendors could reasonably demo against.

Lesson: Stay away from long, feature-based checklists.

Applying UCD principles#section6

There’s a different way to do this than torturing your BA— and everyone else—with long spreadsheets, and it revolves around pursuing a user-centered design (UCD) approach that emphasizes narratives, which we’ll call stories here. People will disagree about the tactics of UCD, but we can generalize overall that a user-centered approach is:

• Holistic to encompass the entire digital experience (and therefore not feature based)
• Iterative, where you initially sketch light (and therefore imperfect) requirements and refine them over time via iteration
• Story-based, with an emphasis on user narratives, often called “journeys” or “top tasks”

There’s much more to UCD, but for our purposes, two key constructs stand out:

• Personas: User archetypes that guide decisions about technology effectiveness. Personas are useful in the sense that they create a common shared understanding of the user group, but with a human existence to help keep it real.
• User Stories: A to-be story about the “daily life of” or a journey undertaken by key personas. User stories are exceptionally valuable here because they offer test cases against which you can compare and contrast vendor bidders.

Information gathering#section7

You can chose from among numerous well-known methods for eliciting information needed to create personas and user stories.

• Document reviews: Including existing and prospective systems diagrams, planning documents, and analytics, but also the information that flows through the anticipated technology, like catalog entries for an ecommerce site, or forms in a document management system
• Questionnaires: Including customer and employee surveys, as well as specialized questions you might want to pose in advance of any in-person meetings
• Workshops: A useful way to debrief groups of people, as well as experiment with more forward-looking brainstorming; customer focus groups fall into this category as well
• Interviewing: Debriefing individual stakeholders one-on-one, where they may become more candid
• Shadowing: Following stakeholders around for a typical duration of time; this sort of contextual inquiry is often the most useful, but also labor intensive
• Potentially others …

Different practitioners will take different approaches, and clearly the level of effort here should be commensurate with the anticipated benefits and risks with the new technology.

At Real Story Group when we’re creating personas and scenarios, we like to take a modified contextual inquiry approach. We gather individuals with similar roles in a conference room and debrief the team as a group. Using a projector, we may ask some members to log in to show specific examples of an incumbent system to the group. When we are gathering requirements for an interactive system, we make the environment as interactive as possible to get the maximum information exchange.

We’ll send five questions in advance as the agenda for the workshop:

1. Show us briefly, on the screen, what you do.
2. What works well in the existing environment (top three only)?
3. What doesn’t work well or is missing in the existing environment (top three only)?
4. How is your work/market/environment/customer changing?
5. What else is important that we haven’t discussed?

The questions are deliberately open ended, to create as much of an open dialogue as possible. Note the emphasis on “top three”—we don’t want a laundry list of features, but rather the most important problems and opportunities.

Sometimes, it’s hard for line employees to identify potential future opportunities, so it can be useful to introduce the whole process with an educational workshop describing industry best practices or examples of what other enterprises have done with the technology. This is particularly important when selecting a type of technology that the enterprise has never used before.

The question still remains of staying aligned with the initial business plan. We like to book half-hour sessions with interested executives to understand the broader business currents and objectives underneath the technology selection effort.

At this point, a lot of raw material has been accumulated. The next step is to convert it into the two core components of the future RFP: user stories and advanced Q&A.

Tips#section8

• You will need to invest in both information and process analysis, and this will require document analysis as well as contextual inquiry.
• Avoid long, undifferentiated, spreadsheet-based feature lists in favor of uncovering material necessary to create key personas and scenarios.
• Start with the user experience and work your way back into enterprise systems.
• Avoid the temptation to broaden your scope beyond the original charter.
• You don’t need to be perfect at this (or any other) phase, so focus inquiry into your stakeholders’ most burning problems or intense needs.