Remember the 'Team' in IT/Business Teamwork

Ann All

I don't need Harvard researchers to tell me brain function can begin to decline in our 40s. I live it every day. I find it more difficult all the time to remember what I read, a pretty big problem considering I'm paid to read and disseminate lots of wide-ranging content on issues related to executive IT management.


Earlier today, to help illustrate the point that it's important to be as accurate as possible when determining the total cost of ownership of an IT project, I linked to an IT Jungle article on 10 practices to please your CFO in 2010. Thank goodness I had just read an excellent post on risk management by IT Business Edge VP Ken-Hardin earlier this morning, or I never would have connected it to one of the other nine suggested practices in the article, including both business and IT in continuity planning..


Ken's lesson on business continuity hinges on the experiences of a mid-sized online payment processor whose frugality concerning redundancy and power allocation led it to experience two one-hour-plus service outages in a month, costing the company at least $1 million in lost transactions plus "significant" service-level agreement credits. You can fault IT, sure, and many probably will. But Ken wonders why a CFO or other business executive wasn't paying more attention to these issues, which relate more to contract management than to the execution of a given technology. He wrote:

At mid-sized companies, execution of these deals still falls under IT, of course, but my experience has been that Finance maintains a more intimate role in reviewing contracts. And smaller companies are more flat, in general-some LOB should have been wailing about this before things went south.

Ken spoke to IT Business Edge program manager Andrea Receveur, who found fault with both project management and technical teams. She also suggested stress testing might have helped, noting that "scalability should be one of the first things a project team discusses when they begin the requirements/design phase of any new or upgraded system."


Ken adds that most of the cross-functional project teams he's been on spent a lot of time discussing functionality and payoff metrics, while leaving contract management to IT. So getting folks together to sing "Kumbaya" won't help, unless they are also willing to address the niggly isuses along with the big-picture ones.


Irwin Teodoro, director of engineering for systems integrator Laurus Technologies and author of the IT Jungle article, suggests IT shouldn't be expected to "determine which business units are most important, what priorities should exist after a disaster, and how to ensure business continuity is removed" with no input from the business. True that. Decisions made in a vacuum rarely turn out well.


Because of the possible financial ramifications, business continuity is an issue that truly demands input from both the business and IT. Few projects won't benefit from it. Companies should require it when considering new collaboration technologies -- at least if there's an expectation that folks across the company will use them. In a post from all the way back in March, Sarah Denman discusses the four groups that should participate in collaboration technology projects.

Add Comment      Leave a comment on this blog post

Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.