RE: i5 Youngsters

No extra staff. You already do development, test the new program,
perhaps do user acceptance testing as well (or some other QA process)
and then promote to production. This is no different, it's just making
the process formal and ensuring the steps are documented.

As I've said of SOX and other compliance efforts before, they aren't
about complicating your business. They're about making sure you're
doing things the way you say you are (adhering to your own policies &
procedures). It's also about doing things the way they should be done;
meeting at least minimal customary practice standards (SAS70) or
legal/contractual/regulatory requirements (SOX/PCI/FDA/HIPAA).

I guess I don't understand why you think an infrastructure change
wouldn't be covered by change management. Any change to the environment
can have a potential negative impact on application/data availability &
integrity. That much should be obvious. If you change the tape backup
process, for instance, you may have put the company's ability to restore
data at risk. Sure, a change was made. Was the BCDR plan updated to
reflect the revised restore procedure? Was the new backup process and
subsequent restore process tested? Are you satisfying your company's
policies for data retention? Do you have any client contractual
obligations?

And the documentation isn't nearly as overbearing as you're making it
out to be. As I said before, "applying all IBM group PTFs as of
1/16/08" is an adequate description. Test plan is "Loaded on
development system; no problems observed for 30 days". Backout plan is
"Should problems occur, uninstall PTFs using IBM procedures".

Changing a bad cable is a break/fix and is a trouble ticket/problem
management item. Whether it involves a change management record would
be up to the company's policy. Here, it would not.