Summary

The article outlines ten common IT management practices that can lead to failure, emphasizing the importance of collaboration, clear business outcomes, and realistic project planning over blind adherence to certain methodologies.

Abstract

The "10 Step Path to IT Failure" article delineates counterproductive practices within IT management, such as treating colleagues as customers, enforcing internal SLAs, instituting chargebacks, chartering IT projects without business context, assigning non-committed project sponsors, blindly adopting cloud computing, combining agile practices with offshoring, multitasking, juggling multiple projects with insufficient staffing, and giving unconditional yes or no responses. The author argues that these practices can erode trust, hinder collaboration, and lead to project failures. Instead, IT departments should focus on business outcomes, establish genuine collaboration, and ensure that practices like agile or cloud computing align with the company's needs and services. The article advocates for fully staffing projects, fostering real sponsorship, and maintaining open dialogue about the implications of project decisions.

Opinions

Treating internal departments as customers is misguided and detrimental to collaborative relationships

The 10 Step Path to IT Failure

Not all Best Practices are Best Practices

1 — Tell everyone they are your customer

For whatever reason, IT department heads want to use the word customer for everyone they deal with outside of their team. Employees outside of IT are not your customers. They are colleagues with whom you collaborate to accomplish a task. The idea of “internal customers” puts IT in a subservient position where you are encouraged to make people happy without regard to the business. It ignores the needs of the actual customers of the company and is bad for business.

2 — Make internal SLAs with other departments

If you want to cause friction and shut down communication between departments, establish internal SLAs and treat them like contracts. Relationships require trust. Recognizing your colleagues as people and not some distant customer that needs to be satisfied according to a contractual obligation is the first step in establishing a relationship. If you want to solve a problem, you need to work together and not point to a piece of paper and argue semantics.

3 — Instituting Internal Chargebacks

Keeping track of costs is necessary for a business. People need to know if it is worth doing something or if it is time to pull the plug on a project or service. Sending bills back and forth internally and arguing over which internal account should carry the costs does not encourage collaboration.

4 — Charter IT Projects

Want to fail at a project? Define the project in terms of software delivery. When management complains the software does not do what they need it to do, you are in a position to argue that it meets the specification. If it doesn’t meet requirements, you can argue the requirement are wrong. Lay the blame on the Business Manager that signed off on the specs and requirements. The road to success is defining the project in terms of a business outcome. Instead of “Rolling out Software Package (put a name here)”, use “Increasing sales effectiveness” or “Streamlining Customer Acquisition” as the Project Name.

5 — Assign Project Sponsors

Naming a SINO (Sponsor In Name Only) is a sure-fire way to guarantee failure. Real sponsors want their projects to succeed. They are willing to take risks and put their reputations on the line for their project. Do you think somebody assigned sponsorship according to a rotating list will do the same?

6 — Making Cloud Computing your business strategy

If the strategy is to go to the cloud, you know you have to be in the cloud to succeed. Businesses are defined by services. Services need to be managed and thought out. Just putting it in the cloud is not a strategy. Form follows function. Your services are the function and if the form you need to deliver your service is best provided in the cloud, then good. If not, keep it on-premises.

7 — Go Agile and Go Offshore at the same time

Agile can be a good thing. You do need a high level of informal involvement to make it work. Fail fast, fail often, and make small corrections. Offshore might have a lower cost in dollars, but the hidden costs are enormous. Time zone differences, language barriers, cultural differences, and having everything done in web conferences defeats all the advantages of agile and costs extra time and money. Do you want to go offshore? Do you want to go agile? Then pick one, you can not have both.

8 — Multitasking

If you want to decrease productivity, insist on multitasking. Humans do not multitask. Humans can only concentrate on one task at a time. Every time they are told to switch between tasks, they waste time changing mental gears. The more complicated a task, the more effort and time it takes to get back into the flow. Let your people finish the first task before giving them another if you want success.

9 — Juggling Projects

IT staffs always seem to be short. So, what happens? Stack multiple projects on teams and switch personnel to the project currently on fire. If you want to develop a good reputation in IT, implement this one rule — every launched project will be fully staffed. A project should not have to wait on somebody to become available. If this is the case, the project should not be launched.

10 — Saying yes or no, regardless of the request

Saying yes can be making promises you can not keep. Saying no damages your reputation. The answer should be — We can do that. This is what it will take to succeed. It does not matter if the request is a change of scope, a new feature, or assigning a resource to someone that usually does not have access to the resource. Nothing is free. Explaining what is required to satisfy a request opens up a dialog. Saying yes or no is the prelude to an argument.