Ask HN: Best tips for getting workable user requirements from difficult managers

Anything else we should know

Big organizations operate like big organizations.

The C-suite may want a notification system. But they are probably not the people who will receive an SMS at 2am.

And if a C-something isn’t sitting in on your design meetings, they don’t want the notification system all that badly…and everyone in the large organization sees that.

But also there’s the simple fact that large organizations have a retention bias toward employees who value small differences in status…we call the jockeying for small status differences “politics.”

You don’t and can’t know the important details of the politics at play. And you are just hired help. They have long relationships and you don’t.

Politics is the important point of your meetings. Opposing the project is a display of power. Criticizing it is one too. Championing it is not.

They don’t want it and the c-suite hasn’t sold it to them. You are being paid to impose it upon them.

Sure technically it might matter if the project succeeds. But what really matters is that you get paid.

Good luck.

Addenda:

A. Success is declared not produced. Once you declare the project successful, everyone will have to fall into the party line. That's how large organizations work.

B. You can't make people happy. Their grievances have accrued over many years. And they are probably legitimate but for the fact people are getting a paycheck only because what they have to do sucks.

C. Just to state the obvious, when you are dealing with large organizations, you are mostly solving people problems not technical problems. Your fee should reflect that.

D. Grow your scope for additional money. Large organizations don't mind.

E. It is not your job is not to save your clients money on your fees. Nickling and diming is the essence of consulting.

F. Finally, if you are not working on the brand identity of a brand, you aren't really doing critical work.

First, get a sense for why the middle managers are against the system. Are they afraid of losing their jobs? Do they believe that it will add more friction to their process? You can do this by getting the stakeholders on a call and asking them to explain the why (which will make them feel included and important). Or if you can, visit them and say you want to shadow them to understand the process and in doing so get into their minds.

Once you get that clarity, work with them to design a solution that works for them, and make it look like it's their idea not yours. Make them look brilliant.

Much of success in hostile environments boils down to identifying the motivations of people and making new ideas theirs not yours.

Build a functioning UI prototype of the end result, then demo it to them while explaining that the demo matches the understanding you have gained from the answers you have received. They will then see where details are incorrect and give you corrections, which are often far more clear than responses to text and diagrams.

Also, be sure to take note of the responses. If that meeting goes poorly, there is such a thing as a bad customer, and these look like they might be one. Drop them like a hot potato, using the results of the meeting to convince your leadership.

Quick reaction: Start a rumor that C-suite is looking to axe the deadwood in their middle management, and sees "managers not aligned with the company's priorities" as obvious targets.

I know this is no laughing matter, but that was funny !

Thanks...but back at the coal face - you can't write per-spec. software when the customer is refusing to tell you the spec's. And (beyond CYA basics) there is no "re-arrange the paperwork on Project Titanic" way around that.

The fix for this situation, more-or-less, is learn what you can about the customer's internal issues, then have an experienced and diplomatic manager of your own play a few rounds of golf with the customer's C-suite. There may be some good reasons for the resistance you're facing. Or "understandable" reasons.

(Not saying that diplomacy is easy, nor that favorable results are assured.)

Do you have a project manager dedicated to analyzing and structuring requirement and communicating with the client? Seems like you need it

Their job is to remain in constant contact over email, meetings documents, slide decks, whatever it takes

Not a permanent one, we do many of this ourselves. I know what you saying is "correct" but even then it feels like we be facing the same issues.

But I like the "constant contact" about to send them a new "process flow" but a Simplified Excel Based on. The so they can edit the steps themselves. Trying to make the process diagrams less pretty, complex, something they are familiar with.(Middle Management is not very technical) Will see how that goes !

Tell the C-suite what you told us and send them a bill for your time?

> - No response to questions, after follow-up we got a meeting from middle-management

They're busy running the company paying mortgages while C-suite believe nice sounding words and budgets are all the incentives needed. Welcome to middle management. Some in C-suite will get this.

> - Got some new info, but mostly circle-talk

You're speaking different language. Speak company, not generic IT.

> - Received very negative feedback, where the middle management and only focussed on the questions or steps that where wrong ??

Again, welcome to middle management. It went wrong. There's an error. Fix the error. It's what they do. Again, speak their language.

> - General tips for nailing down requirements ?

Ask for their existing "provide us the steps or process flow for when to alert who after what time, when xyz happens" flowchart, escalation matrix, escalation tree or whatever it's called in their corporate language. Perhaps it doesn't exist. If they're ISO9001 it should, but perhaps not.

Don't ask for meetings on your terms. Go sit in the team, attend operations meetings. Understand them. Corporates are anthropological studies.