As a business leader, one of the things that mytifies me is how software development teams look at reports as an afterthought during software analysis/ requirement capture. As a result, the reports tend to highlight how the software works and whatever data the system captures, in various permutations and combinations without ever telling whether the problem, for which the software was developed in the first place, was ever solved.

Is it any surprise then, when the CEO looks at his IT manager, and grumbles that IT just doesn’t get the business? Nothwithstanding the advantages of running numerous “Align IT with Business” initiatives” (advantage for the consultants, that is), I’ve always wondered why CIOs / IT Managers don’t start their software architecture/design by first defining reports that clealy show whether the problem is being solved, and to what extent.

In many cases, these metrics were never defined, and it is here that IT can bring in the first “business level” contribution. Once these metrics (and reports) have been defined, then the next step would logically be to measure the current “as is” situation. Again, here too there may be instances where business function has no idea of how the problem is currently being managed, and again, IT can contribute to the business by mapping the exisiting business processes. 

As a CEO, this information now allows me to confirm whether an IT intervention is actually needed, what it’s “core business benefits” should be, and what are the absolutely essential features of the software that needs to be developed to solve the problem/ improve the situation. I distinguish “core business benefits” from a more generic ‘cost/ benefit” exercise in that while a Cost / benefit analysis normally looks at an “inside out” picture (what all the software can do versus how much it will cost to build them in) a “core business benefit” gives an “outside in” perspective (what the essentially few things that the software must do well to solve a business problem).

As an Intelligent Business software provider, at Stylus, this is a challenge we have taken on, and our RadicalRootingTM process looks at software requirements backwards, starting from the reports that tell us what problem the software seeks to solve and then allow that insight to define what the software should and should not do. It’s amazing what we’ve learnt through this, but I guess that’s the subject of another blog in the near future. It isn’t an easy ride, but as we see our clients’ businesses succeed, it confirms that it’s a worthwhile one.