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.

the arrival of process

My department - and I am the ringleader on this particular item - is in the midst of changing our processes for software development. It was fairly informal, since our customers were internal. Ask them what they want, build it, give it to them. If there was any documentation, it served the developers more than the customers, perhaps explaining a particularly difficult piece of code.

The department was getting beat up right and left - and why? A few reasons. One, we were always late with our estimates. The "estimates" were usually really loose ideas given by managers before requirements were analyzed (which of course, they never were analyzed, not formally). And an additional reason why we weren't making our dates? Our customers would bring us new requirements, or complete changes in direction, at various points of the project - causing projects to extend and extend.

There are a lot of pain points here, especially for me, taking over from a guy who wrote applications for ten years and didn't really need to document them - after all, he was always going to be here to support them, right? And now that we're offshoring some of the development, I need a better way to communicate our requirements.

I'm proposing requirements elicitation and analysis, project vision/scope statements, use cases where applicable, a change management process by which we do not increase the scope without analyzing the cost and risks, and more. I've been doing a whole lot of reading in a variety of places [Books 24 is a great subscription to have ], getting a broad idea of industry best practices and combining it with what I learned in Software Engineering school and what I've done as a consultant. None of these ideas are new, but for some reason, they had never taken root here.

I'm really happy about the changes we're going to make. Already, use cases have come in handy. When I presented a set of use cases to the stakeholders and SMEs, they immediately understood what I was trying to capture, and I was able to get much better feedback from them. It worked like a dream, just like the books said it would! And the vision document - after reading what they came up with for a vision set into a simple paragraph, they realized that they had left something out of the scope - and we were able to fix that in the early stages. Without the vision document, I'm quite sure we would have proceeded to the end before discovering the missing requirement.