Stories by Aaron Kumove

It is time to address technology driven narcissism and isolation.

...And what to do if it fails to get the green light, writes Aaron Kumove, in part two of his column on ‘getting IT project governance right’.

While you may have to ask uncomfortable questions at times, you are not there to say ‘I told you so’ after the fact of a failed project.

Last issue I discussed the divide that often exists between an IT shop and the rest of the organisation.
I suggested more than any other factor, it is this divide that is responsible for failed IT initiatives. There are a number of reasons for this divide, namely: Fear of IT, ignorance, poor communication, governance, training and remuneration.

Last issue I raised the paradox of IT outsourcing. If it is such a good idea, why are so many organisations disappointed with the results?
To a large extent I think it is because many organisations are unclear on why they are outsourcing and the particular things that should or should not be outsourced. A commonly heard mantra is, ‘We should outsource things that are not core and keep in-house those things that are.’ In other words, an opportunity cost approach.

“The IT department builds software, runs the systems, and … oh yeah, they provide a help desk so we all have someone to moan to and blame when the systems misbehave.”
While that may be what IT often does, it does not really tell us what IT should be doing, nor does it give us any guidance on how IT should go about doing whatever it does. To answer these questions we need to dig a little deeper into the often-mentioned but less-often-implemented concept of business and IT alignment. In short, how do we ensure our IT decisions are truly adding value and are not just interesting and expensive sideshows designed, albeit unintentionally, to exasperate, frustrate and infuriate? How do we make the right strategic choices and truly align IT with the strategic goals of a business?

In the last issue, I introduced the need to come up with better models to manage and govern IT. I also said one of the biggest reasons in my experience for ‘IT projects’ going bad comes down to a lack of definition and/or communication of responsibilities.
The question is how should we govern IT? Are there ‘best practices’ we can employ to ensure we have: Appropriate accountabilities in place; processes to ensure accountabilities are met; and oversight mechanisms to deal with ongoing issues of portfolio management, policy and risk management?

In the last issue of MIS I argued we need to make business owners accountable for what have traditionally been called ‘IT projects’, which I prefer to think of as IT components of business projects. That, of course, implies IT is aligned with and in synch with the business; which, by definition, means every IT project links explicitly to a stated business project or strategic initiative.
If you buy that idea, I would be surprised if you would argue with the notion that business owners should be held accountable (or at least jointly accountable) for IT components of their business initiatives.

Let’s ban IT projects! I have already stated one of the causes of the often poor relationship between business and IT – and the subsequent poor performance of business projects with IT components – is a lack of understanding between the two camps.
You will note I said “business projects with IT components”, not “IT projects”, and therein lies a very important distinction. My view is, there is no such thing as an IT project, but rather there are business projects that may comprise, to a greater or lesser extent, some IT components. Unfortunately, this view tends not to be apparent or pervasive.

We started last month with the bottom layer of the model, the messaging layer. We discussed how adopting a common messaging model to allow applications to communicate with each other can lower costs, improve time to market and ensure a manageable, scalable and maintainable way to add strategic capability.
This month we will look at the next layer in the model, the transformation layer. Having a common messaging model ensures we can deliver information effectively, efficiently and consistently between applications. It does not, however, ensure the messages, once delivered, can actually be understood! This is the purpose of the transformation layer.

Last month we looked at some of the missing pieces in the Web services model as it currently exists, those being: Security, support for transactions, and the notion of a business process.
We also debunked a commonly held view that Web services will allow one to easily turn legacy applications into components which can be accessed over the Web.

There is always an abundance of vendors with products that will, ‘out of the box’, allow you to effortlessly take advantage of the many benefits the latest paradigm shift promises to deliver. Welcome to today’s incarnation of ‘the next big thing’ – Web services.
Web services are being touted as a new way to enable electronic trading and application and process integration over the Internet. They are also said to have the ability to turn monolithic legacy applications into discrete components that can be accessed over the Internet.