Justin James lists 10 ways that IT departments waste money on development efforts. Examples include using developers as support staff and failing to calculate a project’s ROI before green lighting it.
———————————————————————————————-
Many IT departments walk a fine line between being a needed cost center, a necessary evil, and an absolute money pit. In a few rare occasions, IT departments are able to deliver enough value to become profit centers.
One of the key factors in determining whether an IT department is delivering ROI has to do with the development efforts occurring within that department. In my experience, here are the 10 most common ways that IT departments waste money on development.
#1: Communication problems
Communication issues are one of the biggest causes of project failure; these issues are magnified with internal projects. Just because the “customer” works in the same building and has their paycheck signed by the same person as you doesn’t mean there won’t be communication problems. In fact, internally facing projects are often worse than projects for paying customers because internal customers don’t have to adhere to a contract, and no tangible value is placed upon the work.
In these situations, there is little incentive for the customers to work well with you, and if communication breaks down, they complain about how “IT is stonewalling us.” The result is wasted time and money due to things being delivered late, delivered wrong, or not delivered at all.
#2: Process issues
To the rest of the company, internal IT is like the nephew you can order to come mow the lawn when needed. This is no way to run development projects. All too often, the IT department eventually tires of it, tries to establish some sort of process to put on the brakes, and gets initial buy-in from leadership. And when the other departments think “IT is stonewalling us,” leadership changes course and rescinds their buy-in without telling IT. The next thing you know, every minor meeting becomes a shouting match about who is adhering to what process or how the process is not working — even though the meeting might be about the feature list. Broken, ineffective, and unenforced processes are a major waste of time and money.
#3: Refusal to go live and iterate (aka: insistence upon perfection)
How many times have you seen a project that is 99% done not get deployed because one of the customers isn’t 100% happy with it? And then from there, it seems like you spend almost as much time tweaking a few minor issues as you did building the application in the first place.
This is where I am in 100% agreement with the Agile folks. If the project is even 90% complete, go ahead and deploy it. You know there are a few bugs and that some things are not “just so” but that is okay. Get actual users to work with it. Who knows? Maybe they’ll like it as is, or maybe they’ll have ideas that are even better than the features that were not delivered. But no matter what, having an application mostly done and not deployed means that it is going to take even longer to see ROI on it.
#4: Penny wise, pound foolish
All too often, leadership doesn’t think that it’s worth investing money in internal IT development projects. Their thinking goes something like this, “We won’t see revenue from it, so how can we see ROI?” Well, if the project won’t deliver value, why do it at all? Or, as many mothers have tried to explain to their children over the ages, “If something is worth doing, it’s worth doing right.”
This doesn’t mean that every developer needs a dual CPU desktop machine with a pair of 30″ displays, cable TV with all of the premium channels, and a chauffeur so they can write code on their morning commute. But it does mean that, if a developer needs a tool and can demonstrate that need, it should be bought. I cannot count the number of times I saw a developer with a $70,000/year salary spend three weeks doing something by hand that could have been done in a few hours with a $1,000 tool. Yeah, that was a great way to “save” money, wasn’t it?
#5: Outsourcing missteps
Everyone loves to knock outsourcing, regardless of whether it is contractors working onsite or offshore workers halfway around the globe. But the leadership team likes looking at the spreadsheet numbers on outsourcing, particularly when times are tight like they are now. The problem is, outsourcing often costs much more than it saves, because it is filled with hidden expenses.
For example, when you bring in contractors through a staffing agency, how do you think the agency finds workers of a particular skill level; charges you a fee less than what it would cost you to hire them directly; pay their overhead (such as that well-dressed salesperson and their recruiting department); and make a profit? Easy — they misrepresent the talent. Oftentimes, the staffing agency doesn’t have superstars “on the bench” waiting for the next hot assignment, they run an ad on a job board and fill your seats with the cheapest people they can get on two weeks’ notice. Anyone sitting around in the job pool just waiting to fill that position is probably not a choice employee.
Offshore workers are an entirely different issue; it’s extraordinarily difficult to manage a project that is developed offshore. Chances are, you’ll need at least one employee for every couple of your offshore workers just to manage them and keep track of what is happening. You might assume time zone, cultural, and language difficulties would be small problems, but they aren’t — just try to do your job efficiently when you need to wake people up if you want to talk to them after 1:00 PM.
I’m not saying that outsourcing is always a losing proposition; but a hastily thrown together outsourcing plan is a great way to throw tons of money down the drain and lose a lot of time in the process.
#6: “The Longest Yard” (documentation and user training)
While issue #3 (refusal to go live and iterate) keeps the product from ever reaching the users, what happens if the users never get documentation or training? Unless your application is as easy to use as, say, a phone book, it’s unlikely anyone will ever use it. Unused applications are the biggest waste of time and money possible because you went through the whole development cycle for nothing; you could have paid your team to sit at home playing video games and have gotten the same results.
If your project plan doesn’t provide the chance to put together documentation, or if no one has put together a training program, you might as well take your development budget and use the cash to light the BBQ grill.
#7: Developers used as support staff
If you ever worked support, do you remember what you earned? Now, are you earning a multiple of that income as a developer? Same here.
Developers are extremely expensive compared to support staff. Not only are the salaries higher, but the tools, training, etc. are too. The support team will need to work closely with development, especially for a new product; but developers should not be used as support staff, unless the project is very small and/or bug free and self explanatory — it’s just too expensive.
#8: Poor foundation for development
Many companies aren’t set up well for development, especially if there are only a few developers on staff. There is a lot more to working on code than having a standard desktop PC with an IDE installed and a few books on the desk.
There should be version control systems and bug tracking applications for all but the smallest of shops, for example. Developers will probably need additional support from IT, such as test machines (physical or virtual), database servers isolated from the production servers, and maybe a section of the network set aside to contain disasters if needed.
When developers don’t have the necessary resources to work safely and effectively, their work is slowed down, or it impacts the rest of the company in negative ways. Think about it… if a developer’s faulty test code blows up a database server, wouldn’t you rather they didn’t blow up the one that the accounting system is also running on?
#9: Fail to know the business
Internal developers should know enough about the business so they can follow along without needing every little thing explained to them; and the customers should know enough about their own work so that they can actually explain it. All too often, someone realizes halfway through the requirements gathering process that the customer doesn’t know their own process. It’s even worse when the project is given to the customer for review, and they say, “We don’t work this way; why does this application work this way?” And then you show them the specification they signed off on, and they say, “Well, we thought we did things that way, but we really don’t.” What a colossal waste of time and money!
As soon as it’s clear that the customer doesn’t really know their own process, you should stop development and tell them to figure out what they do before you can continue. Also, remind the customer that you’re a developer not a process engineer, so you’re not going to help them figure out their process, either.
#10: Neglect to calculate project ROI
There is a fundamental flaw with many IT development projects: No one tried to calculate ROI before giving the go-ahead. Yes, ROI calculations tend to be overly optimistic and difficult to get right (or even close to right), even after the project is in production. And yet, some projects are clearly a waste of money.
Think of how much time you need to save a department of $10/hour administrative personnel before it pays to have a $60,000/year developer devote three months to writing code. Sure, if it saves those personnel 10 minutes a day, and you have 50 of them on staff, the project makes sense. But if it merely replaces a well-organized and well-understood filing cabinet and saves three workers two minutes a day, the project shouldn’t even be considered without a strong external reason behind it (such as a legal or a customer requirement).
There is nothing just plain dumber than throwing away good money on a project that is guaranteed to not have any payoff.
J.Ja
Disclosure of Justin’s industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.
Justin James is an employee of Levit & James, Inc. in a multi-disciplinary role that combines programming, network management, and systems administration. He has been blogging at TechRepublic since 2005. Read his full bio and profile.