IT Governance

12 ‘Best Practices’ Not to Implement in Your IT Organization

Some things sound intuitively good, but if you stop and think about them, you realize they are actually pretty lousy. Business is chock-full of practices and principles that fall under this category, and you probably have some firsthand examples. So in an article for, Bob Lewis compiles a whole dozen ideas that sound good in practice, but in reality—not so much:

  1. Tell everyone they’re your customer.
  2. Establish SLAs and treat them like contracts.
  3. Allow people to spread stories about stupid users.
  4. Institute chargebacks with detailed invoices for each cost center, billed in minute increments.
  5. Insist on concrete, financial ROI for projects.
  6. Charter IT projects.
  7. Assign project sponsors.
  8. Establish a cloud computing strategy.
  9. Go agile and go offshore simultaneously.
  10. Multitask.
  11. Juggle lots of projects and shift staff between them.
  12. Only give yes or no answers to IT requests.

You’re (Not) the Best Around

Telling everyone in the business that they are customers of IT is a sure recipe to keep IT in a role of subservience forever. IT does want to do its best job to please colleagues, but IT and the business are on equal footing (because IT is also the business). Along those same lines, IT should not be sharing stories with each other of how stupid users can be, because if any of those stories get back to the users—bad things may result.

As for SLAs, the important thing to remember with them is that they are guidelines that create uniform expectations for IT and the business. They are a tool for communication. Treating them like ironclad contracts and getting aggressive when issues arise is a mistake.

Another way to miss the point is to charter IT projects where the goal is to implement software rather than create a business outcome. The risk here—in chasing software instead of outcomes—is that the software may not end up doing what the business wanted, even though the goal (implement software) has been achieved. Goals must always be set with business benefits in mind. A good sponsor will see to this. Who is a good sponsor? A good sponsor is someone who wants to be the sponsor and is passionate about the outcome.

Anyway, have you gotten agile yet? Or are you about to start? And have you decided to offshore any tasks? If you decide to do one, do it well and gradually. Do not try to get agile and offshore at the same time. It is just too much new complexity to manage all at once, so why give yourself the headache?

About establishing cloud computing strategy, Lewis says this sarcastically:

Whatever you do, don’t think more broadly than [believing the purpose of a cloud strategy is just to have one]. Don’t consider a managed technical architecture, defined in terms of services. After all, doing so might lead you to believe that the services are what you need, and that the cloud might be a way to provision some of them.

It’s an old rule: Form follows function. Services are the functions. The cloud is one form some of your needed services might take. Avoid thinking that way, unless you want IT to succeed. Then it’s mandatory.

Finally, when the business makes requests of IT, remember that “yes” and “no” are not your only options. Lewis suggests you always give an answer of, “We can do that. Here’s what it will take.”

For further discussion on these not-so-best practices, you can view the original article here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.