Posted by: Derek Kuhr
The topic of mitigating risk in application implementations has sparked my interest lately. And at Oracle OpenWorld 2007 a couple of weeks ago, I was really looking forward to one session which featured a DirectTV honcho addressing how the well-known satellite TV provider mitigated risk during Siebel implementations and upgrades.
Unfortunately, the session turned out to be pretty disappointing. I went in there expecting to hear some straightforward tips about specific things a company can do to keep bad things from happening. But what I essentially got was an hour-long commercial for Oracle’s Advanced Customer Services (ACS) division with DirectTV serving as a reference customer. ACS is made up of a few groups of Oracle consultants who help Oracle customers mitigate risk.
There were, however, a few nuggets of good advice in there peppered between praise over how great Oracle’s ACS consultants are and why everyone should be happy to pay for their services.
And so, without further ado, here are some risk mitigation tidbits to keep in mind when conducting a new software implementation or upgrade:
Remember that it’s not always the technology
People tend to think that when implementations go wrong, it must have something to do with the technology. But surprisingly, said Michele Corvino, an Oracle ACS product manager, that usually is not the case.
According to Corvino, Oracle conducted a study of its customer base and found that when application implementations fail, technology is to blame only about 20% of the time.
More often than not, she said, implementation failures are caused by problem with people, problems with processes, or both.
On the people front there are several things to keep in mind related to poor strategy, lack of governance, lack of executive sponsorship, incorrect training of personnel, having the wrong people involved, and not communicating properly about changes that are coming down the line.
Processes need to be inventoried before any new implementation or upgrade as well, because if you have a bad process someplace, you don’t want it carried over when the new technology goes live.
“If you don’t fix the process before your implementation,” Corvino said, “what you’re going to end to end up with is a bad implementation.”
Keep track of customizations
When planning to upgrade a highly customized application, you’ve got to figure out which of those customizations will be kosher in the new version of the software and which ones won’t.
Also, while some customizations may technically work following the upgrade, you still have to ask yourself whether they’ll still have the ability to scale and perform over time, said Steve Jines, DirectTV’s director of development for Siebel applications.
It’s important to conduct a major code review prior to any upgrade and then come up with “valid performance tests that truly represent what happens in the production environment,” he said.
Set up protocols to deal with unplanned downtime
DirectTV runs Siebel’s field service and call center software and with so many users online and so much transaction volume going on, any downtime is considered to be a huge expense, according to Jines.
That’s why Jines thinks it’s a good idea to make sure you have proper protocols in place to identify problems that cause outages.
One piece of advice to remember along these lines: In the event of an outage, make sure at least one person is assigned to examine all of the log files in order to identify the problem.
“Our first priority is to get the system back online,” Jines said.
Well, that’s about all but there’s no reason for the conversation to end here Let us know how your firm mitigates risk in new software implementations by posting your comments. Let’s get a real laundry list of risk mitigation tips going.
Have a nice weekend, all. I’m off to Flordia for vacation. Gonna go see the Mouse.