IT is the problem!

What has slowly revealed itself over the last few weeks is pretty insane! But I had a glimmer of insight a little while ago which gnawed at me and I'm fairly certain that this is the central issue: that IT is the source of our own woes.

Much as we would like to (and actually do!) blame our customers and clients, IT is the guilty party. Certain refrains can be constantly heard:
"They don't know what they want!"
"Why can't they make up their minds?"
"They're asking for the impossible!"
and on and on.

Frankly, in my experience, when talking to the business, I can pretty much be open/honest about what can/can't be done & how long it's going to take. I mean these guys don't know IT and a lot of them don't pretend to. They really have to go by what you say. So unless you're just plain intimidated by the business (and a lot of IT ppl ARE) in which case you'll overpromise stuff, the business will take you at your word and get on with their lives. After all, they have more important things to do like make $$. It's our fear or overeagerness to please that gets us in trouble here.

But even more than that, recent experience has shown me that I as a BA am actually afraid of my development team! I've been nervous changing requirements on them because I fear they'll get angry or lash out and give me those above retorts (in other words, treat me as if I'm the business, although I actually AM playing that role; but the difference is they'll say it to my face). Sure, I can pass the buck to the business, but as the BA, I am smart enough to know how requirements gathering works. It's done iteratively; no customer knows what they want right off the bat. Everything in the beginning is an approximation. However, dev teams think it's written in stone and proceed that way. Then when the BA comes back with more detailed/refined info or changes the plan, the grumbling begins.

What's needed is for IT to be patient; to realize that they shouldn't put much work in the beginning of a project in terms of development, and that things can change. If the initial plans are vague, then build a fuzzy prototype that does the bare minimum. but above all, EXPECT CHANGE. Because if you expect it, then you're prepared for it. If you're prepared for it, then well, there's nothing to complain about when it actually happens. I am working with an off-site dev team now and I said from the get-go that the project is going to be iterative and that we'll need to do several versions. Well, whaddaya know? We got some more stakeholders involved and they requested their own changes. So back to the drawing board! But this is great, because everyone's voice is heard & we have more information as a result of the 1st iteration as well.