IT Governance & Business Analysis

Hey, if you're a customer with IT needs, just throw all of your ideas up in the air, and pipe each one of them to IT to be built. Heck, you're the ones that know what you want, so why should we evaluate and contradict your demands? You're the one paying the bill; it's not up to me to challenge your demands. You want a solution that knowingly will break a legacy system or process - great! We'll design, code it, and deploy it right away. And ya know what, we'll even throw in a two-pack of Sham-Wows(c)!

What are our customers really seeking with its software requests? Do they even employ sound, skilled business analysts capable of creating system requests that are well evangelized, correct, and show good ROI?

Hmmmmm, why should I care? If they want another widget, we'll give it to 'em, right? Wrong!

I can't believe how many systems I'm seeing recently that have had so much functionality bolted onto it that it's seemingly impossible to maintain. Customers surely know their business, but without trained analysts to handle at least some level of process re-engineering to understand and consider all angles of a software request (be it a new system or an enhancement), these customers cannot possibly expect IT to decipher and build exactly what's needed. Sure, they'll get what they asked for, but how responsible with public funds are we being responding to needs in this fashion? Not very...!

Well thought out business demands should come from a study of the existing IT system and all adjacent systems that it hits. Once I understand and can speak clearly to the new request or enhancement needed, it needs to be well documented and communicated. Beyond selling the idea or concept to IT governance, the BA needs to be able to efficiently and exactly convey business requirements to feed the dev team. In a very agile environment with slim resources and heavy service desk maintenance demands with those same sparse resources, we need to summon exactly what information is required to create a user story...JIRA is an example of a powerhouse platform to create user stories and garner exactly that support information needed to build the solution. Giving the BA that boundary helps assure s/he provides exactly what you and your team need to succeed. Don't forget to include a blurb on each story's "conditions of acceptance".

If you're anywhere near a public sector business, you've got to read Extreme Government Makeover by Ken Miller. Inspiring and so very, very perfectly stated. Remove the twists in your systems pipes...Another post coming soon on this topic.

Been too long

It's time to start blogging again. Yeaaaah.