Common ways IT wastes money on development

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.


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.


Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!


Justin James is the Lead Architect for Conigent.


Looking at the responses so far, the discussion is limited to putting 'the blame' on 'management' for not facilitating a sufficient working development department (or company for that matter). I have always found this a bit strange. Why limit your (our!) skills as a software developer ONLY on the business of producing code ? Why waste energy on the finger pointing to management and why not direct it to help improve process. Is this a lack of communicational skills among the 'IT development specialist' ? Or do developers see themselves only as blue collar workers on the treadmill of producing code? It seems that developers love to be (and love to stay) victims of this situation. I think history shows that if this situation stays the same, this status quo will not be in favor of the blue collar workers, that's for sure ! I suggest developers spending as much time improving process than producing code. In this way, they will be much more/are perceived to be more valuable for the company and quality of work will be a real topic among management! And don't tell me you do not have the time for it ! If so, it is time to switch employment or, to follow the 19th century workers, start a union :)


I am not a developer nor a manager, but I do work in I/T. It seems to me that companies want it all. There's a saying in construction you can have it fast, cheap, or good. You only get two, not three, of the choices. Fast and good is not cheap, cheap and good is not fast, and cheap and fast is not good. It seems like the current offshoring trend is a desire to have all three things. I would guess you would usually end-up with cheap and fast; a poor quality shoddy product. But the others are just as likely.


example is something I had to live with quite often. We know what we need right ? No need for complicated requirements analysis. I listen to this wondering: why do we make things so much harder. Those projects developed for internal clients have always been a real pain. #3 is another good one. They just don't get incremental development. I had to explain several time that assigning priorities to requirements was a tool and that the point was not to have an excuse and plan for failure. They just don't get it... Now number #5. On my current project I work with Indians. Management sounds like they just discovered that there is a 10 hours time lag between India and Quebec. Its hopeless... JS

Justin James
Justin James

We all know that IT departments' development projects can become money pits. Give us some more examples, and what can be done to alleviate the problems! J.Ja

Tony Hopkinson
Tony Hopkinson

100% correct, Pick six numbers we'll go halfies on the next lottery. :D

Tony Hopkinson
Tony Hopkinson

There is a much bigger one. How do we save money in IT? We skimp on quality. So how does a third party IT anything make a profit, especially when you contracted them based on lowest quote.. Business 101, business people.......

Second and Goal
Second and Goal

#3 has been one of my biggest pet peeves for years. If you have 30 bugs fixed, why delay a release for a month just because a few others haven't been fixed yet? Get the fixes you've already got, which are an incremental improvement for the product, in the customer's hands ASAP. No large software project is ever going to be perfect. It's the classic see-saw effect: at some point the weight of new features and fixes outweighs the remaining features and fixes to be added, and you start to tip toward release. Once the balance tips far enough that the board is down on one end, what's the point in waiting for perfection?


My current project requires integration between 2 systems. The producer places an encrypted file containing XML data in a shared folder. Then, the consumer parses the data and stores it in a database. To me, this smells like a job for an B2B or messaging tool. Since my current client favors the Microsoft technology stack, I suggested BizTalk. Their reply was no because it's too expensive. What they fail to understand is the amount of development hours they could save as the scope and length of the project grows. It took a month to do and could take longer as data increases in volume and complexity. Right now, it's one-way, one-shot deal. But what about tomorrow? It's either pay now or pay later.


..don't want to pay for it. Business 101...unfortunately. They just don't realize that quality will actually save money over the long term (a lot of money). Just take unit tests for example. For us, this is our biggest success story. New projects developed with unit tests in mind (from the start) are so much more superior to other projects. Less iteration through the costly system tests, easier bug correction, easier to add new features or to modify existing ones. Of course the problem is legacy modules. I'm at a point where I believe that those should be rewritten using our new more mature unit tests oriented approach. I believe we would get our money back in the medium to long term and deliver more quality to our users. The problem with this of course is that this would require a large initial investment with no hope of returns in the next quarter. The next quarter...Business 101 again unfortunately. JS


"You build something for now and not for tomorrow or to 'win the nobel prize' ". That is how management usually see these discussions. If you want to convince, try to give borders and limitations to this solution and TRY to explain that architectural change is necessary for future use. This sounds more expensive (and it usually is) :)


I have managed a few success on some legacy modules where I was able to add unit tests without making to many modifications but this has been the exception. We have had more success with new modules in this existing application. However, this leaves us this huge chunk of code that has very little unit tests. I will keep banging at it though. JS

Tony Hopkinson
Tony Hopkinson

coding standards. Refactoring 'legacy' code so we can unit test is something I've been banging on about for three years at our place, not having a lot of success. Bugs and issues, lots of them though. Mind you the code is so tightly coupled, it's more like reengineering than refactoring, the chnaces of not changing the functionality in some way are somewhere between slim and none.

Editor's Picks