Is your Requirements gathering just an Ice-Breaker?

 Do you need requirements for tech projects? YES! 

Do you need buy-in from stakeholders? YES!

Then combining those two needs in one process is efficient! NO! STOP IT! …Ahem… I mean, <deep calming breath> Probably not, and here’s why.

Requirements gathering is a tradeoff

Requirements are a give and take. The client gives requirements and gets expectations. They are saying the problems they have with the system and what they want to see done differently, and you're there to implicitly tell them that it'll get done. Now, as a consultant, you'll offer disclaimers to say, we aren't promising we'll do this, but that message is precisely the opposite of the function of the task: making a list of problems to fix with the intention of fixing them. So the client SHOULD think that you're making a list of things to ensure are included. 

It's All Fine Until Sign-off Time

The real issue is that the Requirements are (should be) Tech Stack, but Buy-In is (100%) Human Stack. Requirements create the baseline foundation of a Tech Stack project, and the expectations should be Technical expectations. When they are combined, the expectations shift to Human Stack (belonging) based expectations and center around belonging which shifts the requirements away from Tech Stack. This is invisible until sign-offs. Technical deliverables (which meet requirements) should be 100% Tech Stack. An operator will input the value, and process automation, field update, and notification email are executed. The sign-off should only consist of Input -> Outcome if it works, it's signed off. (In fact, sign-offs should be framed in Prove It Doesn't work language.) But customers don't want to sign off because they don't know why the operator would input that value, don't understand the field updates, and aren't sure they can change the email template. All valid, but all Human Stack. 

Why Buy-In Is Human Stack

Buy-In is Human Stack because it's about belonging. The base code of the Tech Stack is 0/1 - "True/False," but the base code of humans is "in/out" or belonging. We need to know that we're in, not out. When getting a client "Bought-In," the core idea is to get them to feel included. The CRM doesn't care if a user feels included or not when it runs automations, but we know that a user's sense of belonging will be directly tied to their participation in the system. More inclusion means more participation means more adoption. 

Why Crossing Streams isn't 

1. Requirements Are Overhead Multipliers:  Every requirement gathered has about ten steps of the process something like: documented, listed, groomed, entered into a PM tool, assigned, completed, tested, timelined/gannt’d, and checked off. That’s 10 steps for EVERY requirement. Even the bad ones. Which a lot of them are, yeah, I said it, but you were thinking it.
2. Bad requirements require the same overhead as good requirements. Don’t tell me this happens in grooming where you merge them. Because you have to circle back to the client and explain why it’s either merged or sidelined, and that’s its own five steps. And BA’s work checklists are without enough context to know if it’s good or bad. And no consultant will risk relational capital at the outset of a project to undo buy-in and potentially create negative momentum. Also, more tasks make big budgets look more justified, so it helps at the beginning of a project that was slow to start and needs to look like work is getting done.
3. It sets bad expectations: Requirements Gathering as Buy-In creates expectations. And those expectations then need to be stewarded (usually through the PM process). The problem is that most users don’t know what they want, and asking them wide-open questions about pain points and future functionality creates wild expectations that aren’t grounded in reality. This is especially true for products companies with an off-the-shelf products.
4. Don't waste a Buy-In opportunity on a temporary process. Buy-in should be used to develop long-term patterns of tech behavior. Teach the client how accomplished you are by introducing them to a long-term system that demonstrates THEIR ability to do the tech. Using Requirements Gathering for buy-in is like doing Ice-Breaker Bingo, gathering the cards at the end, and then project managing all of the results. 
5. Buy-In should come from trust in a consulting team's competence and expertise. The competence and authority would be best used to demonstrate a consulting team's ability to move the client's behavior, not the tech stack. While a lot of goodwill and expertise can be developed in the requirements gathering process, fundamentally, it should filter OUT less helpful input and prioritize more helpful input. 

Ok, so if they are two separate functions, how do we do them? Glad you asked. 

How To Gather Requirements

The goal is to get the right requirements as fast as possible, and there's (usually) a shortcut. There's almost always someone in the client's organization who knows what should happen in the current system. They are probably the DBA and likely being ignored.  Consultants won't be surprised to hear this because they were that person before they left and became consultants. Find them, and you found all the requirements because they’ve been gathering them for years, and (more importantly) they’ve filtered out the crazy ones like: “We want the app to make handwritten QR codes with a real pen.” The key is to credit them with the work and help staff see their value. 

How To Create Buy-In

Buy-In comes from ownership of the work. Creating ownership happens by increasing positive engagement and decreasing dependence on outside consultants. To create Buy-In, we use our Human Stack methodology, Digital Guidance. It gets the client into their system quickly and focuses on a few key actions that develop confidence and resilience. Well, eventually. At first, it's just a bit overwhelming, and that's ok because when they start to grasp it, they have a sense of ownership... which is Buy-In. And it is, and those emotions create the type of buy-in that lasts and develops trust in the consultant's ability to help them drive their technology.