The following is an excerpt from Tony Byrne and Jarrod Gingras’ latest book, “The Right Way to Select Technology,” available from Rosenfeld. In this book, authors Byrne and Gingras walk you through their battle-tested process to get the most out of your budget and software. Half of all technology projects fail. So if your company sinks money into a technology that doesn’t work, you and your design team are stuck with it for years. Byrne and Gingras want to reverse that trend.
Thus far, we’ve been focusing on narrative user stories as the prime mechanism for conveying requirements. Unfortunately, user stories are not always ideal for communicating all needs, particularly those related to technical topics like architecture and integration, or that relate to more operational concerns, like implementation and migration.
Here again, you may become tempted to turn to the dreaded spreadsheet to list those requirements, but we have a better idea. Instead, enumerate these issues not as checklists, but as a series of questions to bidders that will yield more useful and informative information exchange.
At Real Story Group, we call this “Advanced Questions & Answers,” and it fulfills a very important function in sharing critical requirements in a way that encourages differentiation among bidders. In particular, you advance the conversation by converting all of your “Does your…” checklist items into “How does your…” questions.
Your questions should have three components:
Here are two example Q&A couplets, from the sample RFP you can find in the appendix, “Resources and Examples.”
|Background||XYZ University is populating a YouTube channel with a growing number of videos. We are rolling out a video server solely for internal pedagogic use, but will rely on YouTube for all our public videos for at least the near future.|
|Questions||Please describe how your system supports integration with YouTube. For example, how can you facilitate the embedding of YouTube videos? Does your system provide capabilities to help manage your YouTube channel?|
In this case, we could have woven YouTube into one of the scenarios, but it didn’t quite fit, and in any case, we had some more questions around it that needed to get addressed.
|Background||XYZ University presently runs one active directory forest on a single domain. We maintain security groups in AD. The university also supports Shibboleth for identity propagation.|
|Questions||Please describe how you employ AD for authentication and authorization. Can you support a mixed entitlement model where some rights derive from AD and others are set within your system? How can user entitlements management get delegated to individual departments?|
Here we could have asked in a spreadsheet, “Do you support active directory?” The vendor would have emphatically checked yes, but when you look deeper, you can see that, in fact, we had more complicated concerns, and as usual, the most important dialogue would take place more around how than what. In any case, the background we provided gave bidders useful information about our environment and concerns so that they could derive the best solution for us more effectively.
Typically, the types of questions you need to address in advanced Q&A fall into four categories (see Figure 6.1):
To be sure, you could include any of those aspects in user stories; you could even include an implementation or migration scenario in your requirements. When assisting clients at Real Story Group, we typically include at least one developer user story. By their nature, though, these systems and integration topics sometimes fit more readily into a straightforward Q&A format.
Your questions will vary based on the nature and complexity of the technology you want to purchase. Avoid the temptation to ask too many questions here, though, lest you fall victim to the same dysfunction of the endless checklist, which dilutes your priorities and could discourage the best vendors from bidding.
In any case, the key questions here revolve around how, not what. Many competing technology vendors can do the same things—on paper. Where they will tend to differ is in approach and the actual execution of particular features. “How” gets you to essential answers about intent, context, and usability much faster.
“Scalability” is a tricky concept in technology. People will say scale when talking about different things, so the term can become vague and take on a marketing-speak quality. Yet for larger enterprises—say, with tens of thousands of employees serving customers across dozens of different marketplaces—the technology choices you face start to become qualitatively different.
So let’s review some common challenges of scale you will need to address.
Enterprises rarely undertake true “greenfield” technology selections, completely unencumbered by pre-existing platforms and commitments. Any new or replacement technology you adopt needs to fit into a broader architecture. Even if you are selecting a software-as-a-service (SaaS) or other cloud-based vendor, you will likely still have to integrate with other systems, at a minimum, your identity management services.
So what’s the best way to describe these requirements? For starters, many such requirements can be readily explained and turned into questions using the advanced Q&A technique described earlier.
More generally, we advise assembling architectural background and diagrams as comprehensively as possible. If they don’t yet exist, create both as-is and to-be schematics. Include both logical (what the systems do) and physical (what the systems look like) diagrams.
Enterprise architects can create highly useful artifacts, showing how data and services flow across environments. These help bidders understand and explain more effectively where their tools can fit into your world.
Just make sure that you include narrative explanations that can explain the context for all the boxes and arrows—or be prepared to field a phone call where you fill in bidders during the selection process.
Technical requirements typically beget “must-have” requirements. Sometimes, enterprises will insist on a particular flavor of technology or license model in an effort by the IT team to prefilter out poor architectural fits. We understand this need, particularly when it comes to security consideration, but we also frequently see buyers go overboard here.
This results in unreasonably limited choices for business stakeholders, or a bias toward only the largest and most expensive solutions. In extreme cases, business owners will go out and self-procure a “shadow” solution to avoid these restrictions.
Consider the following examples: do you really need to be rigid?
We worked with a consumer product goods enterprise whose IT department was slow to embrace applications hosted in the Cloud. When some employees wanted to collaborate, they went around their IT department and signed up for a SaaS-based social collaboration service, which became wildly popular among the employees and spread quickly throughout the enterprise.
Ultimately, the IT department conducted a vetting exercise. When a security flaw was discovered, the enterprise had no choice but to shut the service down completely. Thousands of employees were left upset and frustrated.
Lesson: Even if you have recourse to tools that solve near-term business needs, make sure that you involve your IT and security stakeholders in their selection. IT rules and procedures may be inconvenient, but are often in place for very good reasons.
Make better content decisions with a system of data + insight.
Your content approach makes or breaks your digital transformation. Learn why intelligent content strategy + engineering are critical to your success.
Your content is integral to your product. You might have piloted content strategy and seen promising results. Now what? It’s time to get more strategic so you can sustain and scale. This whitepaper will help you start.
Does your content work? It's a simple question, but getting a clear answer from content analytics or ROI formulas is often anything but easy. This ebook by Colleen Jones will help you overcome the challenges.