the most brilliant blog post I've read lately

Read this - it's like my job on paper. Down to the Inventory System example - this is the battle I fight.

Gathering Requirements or Taking Orders

Here's a relevant quote that sums it all up -

So when you send your people to get requirements, are they saying, "Let me take
this problem back to the team and come back with a few recommended solutions" or
are they saying "You want fries with that?".

We've actually had a major shift here at my current company. Our IS Applications department used to ultimately report in to the business side of the house, and the site-based business side gave us orders - even when we said that the approach they were demanding was not a good solution, not workable at all in fact. But now we're working for a stronger worldwide IS organization, and now it's like we've got a new army at our back when we say that we cannot do something. But still, the old overlords are fighting tooth and nail, unable to accept that we are no longer letting them "have it their way". It sounds like we don't want to align with the goals of the business. Not true. Our over-arching goals are to solve their problems. We don't necessarily want to implement their solution however. We've got alternate solutions, based on actual knowledge of IT Systems.

That's my background as a consultant speaking. I would be hired not just to implement an application, but to help people find their way to their best implementation of the application. Yes, we customized - but generally we had to help our customer figure out the best customizations, or where not to customize and use the built-in functionality. Usually they had to populate a great deal of data elements - we would help them organize their data. If I was just there to follow the manuals and do an installation, they could have hired anyone. The reason they hired experienced consultants from my former company was because we offered that knowledge and, yes, opinion.

I often see developers who have no interest in requirements analysis. They want to get their marching orders and go straight to code. But what happens in the end? The end product doesn't meet the expectations of the customer. Because you can't take their word at face value - you have to understand all that is not said, the expectations not voiced. Assumptions that make an a** out of u and mptions. :-) With experience doing this (like I have), you learn what questions need to be asked. It's almost like mind-reading. I had one project that, when all I had done was completed the User Requirements doc, the customer told me I had just documented their process better than they ever had, and now they had a better understanding of what exactly they did. Music to my ears.

Anyway, I'm not bragging here - I'm trying to talk about how important it is for both customers & developers to understand that requirements gathering should be an interchange. That's why I don't like the word "gathering". It sounds like you are going out and picking nuts & berries. I like analysis, because it implies that you're taking a bunch of data and synthesizing it. It is a skill to be able to do that, and sometimes I'm still challenged by it. You can't get lazy - you have to stay on your game with this stuff. And the customer has to see the value too. They can't be thinking "how dare this developer suggest what we should do?". Of course, there are ways to phrase your opinion so that no one feels like anyone is being pushy, and as a consultant, I learned many strategies for that.