How do you “engage stakeholders” and “gather requirements” in 2011?
Outside the workplace, people and technology have co-evolved. We Facebook,” we text, we tweet, some of us “check in,” all while listening to music that is streaming to us on customized or micro-segmented “radio” channels. We connect with friends long moved away, we coordinate over space and time and find projects and opportunities – and occasionally love (authorized and not). These are not the people we were five or ten years ago. Certainly not the people we were twenty years ago. This is not a good or bad thing, despite regular claims that Google or Facebook or Twitter is the latest thing “making us stupid.” It just is.
For example, I own a Pizza Acquisition Device. No, really. I speak into it, saying “nearest pizza” and it shows me the phone number to the pizza place nearest to where I am standing. One click, and I’m talking to the nearest pizza professionals. It’s pretty cool, you probably have one too. Thanks to a simple mash up of my “phone’s” microphone, GPS chip, and internet connection with Google’s use of computational linguistics, machine learning, voice recognition, massive geocoded databases, etc. – plus the dialing function of my phone – I can always find the nearest pizza. (This is not strictly true, as the nearest real pizza is 250 miles away in Brooklyn, but go with me on this.)
Imagine if someone came to me with the need to gather functional requirements. “I understand you want us to build a pizza acquisition device.” The result would be, I imagine, a fairly expensive and clunky unit that I would wear in some fashion. It would not be as elegant as my iPhone, because it would begin with what I think I need absent the technology experience. The difference between a platform and a point solution is salient here, but I am making a different case: I am co-evolving with the technology around me.
I saw an article recently detailing how Google spent some time considering how their voice search would work, presuming that people would speak to it as if it were a friend, in full sentences. Turns out they need not have worried – we’ve already been trained to speak in search terms. I don’t say, “Hey, I’m standing here in downtown DC, do you know where I can find pizza?” Automatically, without thinking about it much, I instead say; “nearest pizza,” because I know how search engines work. We all do. Google found that the majority of their voice searches are framed in short phrases, as if they were typed into a search box. Google has trained us on how to speak to the Google machine.
If we are trying to ‘engage stakeholders,’ let’s start with where they are, and recognize that they are evolving based upon their regular interactions with consumer technology. (Keeping in mind the ever-present but often overlooked ‘digital divide,‘ not everyone has the opportunity to evolve at the same pace.) In the public sector, this means understanding that even “non-technologists” have become masters at using smart phones, auto navigation devices, music streaming services, etc. Ignoring this means you are starting not on the 1-yard line, but from somewhere out in the stadium parking lot.
If we are trying to ‘gather requirements,‘ well, let’s begin with the understanding that they are not lying about on the ground like swollen grapes. Your users aren’t waiting for you with a list of requirements that you can capture and transcribe. In fact, it’s time to retire the verb “gather” with respect to requirements and move from the hunter-gatherer to an agricultural model of civilization: We need to cultivate requirements based on the evolutionary path of users as they interact with emerging and interconnected technologies. Put more simply: We need to co-design solutions with users who are often unaware of their status as cyborgs.
Great thoughts John. It’s important to meet people where they are, in terms of technology and their comfort level with change. To do this, we at The Clearing find it’s important to identify where people are on the Innovation Adoption Curve. Specifically, acknowledging and investing in “Early Adopters” and acknowledging and ignoring “LAGGARDS“
Hi Kera! With respect, and without commenting on your offering – I am very cautious about applying things like the Innovation Adoption Curve to individual humans or projects.
These lenses, developed to better understand specific market dynamics, are far too often turned around and used as diagnostics for small group projects. For large numbers, the Curve is useful to understand the proliferation of a technology. Turning it around to fit humans into pre-determined categories troubles me as a practice. Better to analyze the specific people involved in your project, then develop archetypes to explain variance and co-design intervention projects. Bottom up aggregation is preferred – let the data precede the framework.
Happy to discuss further.
I can always spot an inexperienced BA (whether formally in the role or by default) when they open the meeting with, “So – we’re here to gather requirements. I’ll list them on this flipchart if you can just call them out.” *head-desk*
Requirements gathering is a series of dialogues, not filling out a spec sheet one time. The artists in this field know how to delve, inquire, and mine the nuggets of information out of the rocks. They can read the stakeholders/participants and adapt to the situation. They’re masters of spotting gaps and conflicts, and offering up good ideas to navigate the waters. It’s poetry in motion to watch it happen. When you’ve had the opportunity to work with a professional Requirements Artist, it’s bliss.