EDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology

Posted by Martin Holzworth Tuesday, June 13, 2006 3:51 AM

A valid argument indeed Charlie. I wonder if we lose sight that balancing risk and reliability is a business, not technology problem. We have seen far too many times that organizations want to jump on the bandwagon of whatever is the latest technology gizmo, without validated business benefit. We saw, for example, in the dot com era that sticking a “e” in front of a business generated hype that the share price could not sustain and introduced unsustainable risk. I am a firm believer that the balancing act between risk and reliability can achieve greater harmony through:
* greater consideration in changing the business
* finding 80% solutions that are proven
* IT projects taking no longer than 9 months
* An enterprise architecture approach that models the business and IT. Historically, the “To Be” state is always IT centric.
Most of the arguments I hear about agility focus on IT improvements, but if organisations truly want to be agile, they need to move quickly by balancing risk and reliability through some of the ways you suggest but also through changing the paradigm
Just a thought….

Posted by charlie bess Tuesday, June 13, 2006 9:32 PM

Thanks Martin.
I agree and one of the implications of what you're saying is that generating true value from technology requires a much wider ranging view.

Even if the technology addresses one area of the business, what is it's effect on:
* governance
* leadership
* team structure
* measures
...

Posted by Joseph Tang Wednesday, June 14, 2006 12:17 AM

Hi Charlie,

I totally agree with what you're saying about the need to action rather than simply talk about how we can improve.

One fundamental issue of change is cost- who's going to pay for it? who's going to pay for the costs of developing, planning and managing all these changes? If managers are naturally risk averse, is it then right for an organisation to say that "the next big thing" will be self-financing so go and implement it now?

Sure it might be self financing in the long term but don't we all work towards quarterly targets? Is it no wonder then that management are often reluctant to bite the bullet and be truly transformational rather than transactional when they are under this kind of pressure?

I guess what I'm trying to say is that any change in business models whether those be moving to a new infrastructure or implementing the new de facto industry standards, need to be supported in the budgets that are dished out right from the top. Rather than trying to do things cheaply without proper funding in place to implement the desired changes appropriately.

If correct budgets were given in the first place for things such as training, materials, tools et, new processes would work first time and not have to be re-worked. This would also increase the appetite for change as it was provide some assurance for managers as to the reliability of any changes being implemented rather than the waste of time it normally is because it's not being allowed to be done properly (due to insufficient resource).

Posted by David Caster Tuesday, June 27, 2006 12:49 AM

Great Comments so far, and good luck Charlie in your new role.

From my perspective, the challenge between Risk and Reliability can seldom be addressed proactively from a technology view point alone and gain the traction necessary for systemic change much less inovation.

In fact, from the CIO's and CTO's that I know, including the ones that I've supported. Most would admit that the CIO and CTO positions are pretty much the step children of the CxO family.

The business units are where the revenue is generated. The clout associated with revenue is almost always where the decision making tree begins and ends. Information Technology has become an expense to the bottom line. Often times right behind Payroll. The Business Units want faster, better, more reliabile, without interuption. The Finance Office wants cheaper, cheaper, cheaper. Both are kicking the CIO and CTO for improved performance.

How many Corporate Windows 98 users would you estimate are still doing production? I don't even have to mention Legacy systems in production. I doubt you'll find as many of either in customer facing orgs. as you will in the back office. And the reasons the non-cusomer facing groups finally get upgraded, is do to the risk of non-support finally outways the expense to upgrade.

The office of the CIO and CTO are more and more becoming the Dr. Frankenstien of the org., taking pieces and parts of everything to "keep it running", "keep it cheap", "don't change anything that's going to disrupt my revenue or bottom line unless it's absolutely going to kill us otherwise". Unfortunately, most of our outsourcing business falls under this category with the strategic applications and inovation staying behind with the Business Units.

To me, the challenge between balancing Risk and Reliability is just circumstancial with the business we receive under the CIO and CTO office. Inovation and Client Revenue focus / sharing is how we shift the Risk / Reliabilty paradigm to a greater focus on improving the clients revenue rather than their expense. It's hard to do under the thumb of the CIO because their focus is Risk / Reliability. But, more dollars are spent by most all corporations in trying to increase their revenue than reducing risk and improving reliability combined. The CIO and CTO are at the bottom of the spending decision food chain.

Since we aren't a product company, it's difficult to sell "improved revenue" to a corporation. Historically, what has been our strengths have pushed us into the commodotized "keep the lights on" side of the business. As long as we stay there, we will contniue to worry about balancing risk and reliability with the CIO and CTO on the expense side of the business instead of being enablers of growth and inovation on the strategic side of the business.

I believe we have the tools and people to make the shift. We just don't have the right strategy.