Wednesday, January 2, 2008

The Top Seven Mistakes CIOs Will Make in 2008

CIO Magazine recently interviewed 250 CIOs from a variety of organizations and asked what their top ten goals are for 2008. As I read this article, I realized that of the top ten goals, seven have virtually no hope of being attained. Why is this?

In my January ObjectWatch Newsletter, I discussed why so many CIOs are heading down a path of failure in the coming year. The article is available without cost or registration at the ObjectWatch Web Site. Feel free to comment on the article here.

7 comments:

Mark Blomsma said...

Hi,

While you make an interesting point your example is flawed. You assume any system of 7 (or 14) dice can be split in 7 partitions which do not influence eachother. Reality will be that the succes or failure of any of the 7 partitions will influence the succes of the others. And unlike dice there is no black/white success with IT projects. Succesful projects typically achieve somewhere between 70 to a 100% of their original goals. 1% of a missed goal in one of the 7 partitions may lead to 100% failure in another (extreme case).

Cheers,

Mark

Anonymous said...

Very good. Please, keep publishing your ideas here. I'm sure it will help a lot to have more people thinking on how to make EA start to create business value.

KCassio Macedo

mrinal mitra said...

I like the approach discussed here. However, looks oversimplification of the problem. In most of the cases partitioning the business process is the most complex task by itself. Any business process that has evolved for a period of 10 years (for example), the activities are sometime so tight-coupled and inter-dependent that it might even require an organisation restructuring to partition them! IT process is the younger one and it generally follows a business process. We, the IT solution providers quite often recommend 'distributed and managable business components' to a business process but the achievement statistics need to be collected.

However the IT process can be partitioned so that the turn-around time is kept to small.

Anonymous said...

The other factor in complexity is “barnacles” which are the processes, procedures, habits and patches that accumulate on any computer system from the day it is first commissioned. I am convinced that the value of IT systems is being lost due to barnacles and complexity. Barnacles force people to work around the computer system or to bridge the gap between the computer system and a manual process. Barnacles make the Finance area spend $5 million on SAP and a further $20Million customising SAP so it produces the same reports as the old system. Complex IT solutions often reflect poorly conceived business processes. These processes have evolved over time to cover over actual or perceived problems. Like ship barnacles they act to slow the system and increase the cost of maintenance and operation.
The best solutions seem to be those where the business is actively pushing the IT areas to make the end to end business process work. Many cases the IT team should provide a simple facility and step back to let the business adapt. They only then step in when the business cannot change a process that makes maximum use of the system.
Business processes like IT systems should be reviewed every year and have the barnacles scraped off.

Alracnirgen said...

Complexity, I consider comes from layers of interpretation and the varied perspectives of the people involved. People in themselves are complex and non-uniform, so simplification and partitioning can be interpreted differently as a result of the people involved in the process. I agree that there are interdependencies, in reality between the dice and this will influence the outcome or the grade of simplification or complexity, even if you try to determine partitions using a mathematical model. Other influences, that would need to be represented and I don't know how mathematically are company history and culture. I suspect that even if you selected best of breed packages to implement to match a Company's Business functions, the inherited "architecture" would vary per company even if they were in the same industry. But this is stimulating - please keep up the good work.

Terry Young said...

Is the relationship between the complexity of a system and the cost to build and maintain the system linear? My experience is that doubling the complexity more than doubles the cost to build and maintain the system.

Anonymous said...
This comment has been removed by a blog administrator.