Posted
by
ScuttleMonkey
on Tuesday August 29, 2006 @03:33AM
from the worse-than-crack dept.

eastbayted writes "It starts off simply enough: Your company signs on an outside firm to help you finish an important app dev project on deadline. But then they convince you they can be of service in getting other work done at your company, and you agree. Before you know it, your organization has become far too dependent on this team of outsiders on whom you're wasting a ton of money and perhaps not getting much in the way of a return. InfoWorld has devised a 12-step program 'that can help wean you off unhealthy dependencies on service providers, consultants, and outsourcers — without having to check into the Betty Ford Clinic or make a tearful confession on Oprah.'"

The key problem is (apart from the fact that inviting a large consultancy firm into your organisation is like inviting Tom Cruise into your marriage) that closed applications depend on a small skill pool that can be easily turned against you.For many larger organisations, a straight-forward way to create a competitive market for services is to either open-source major systems, use existing open source applications (which is still difficult), or mandate that any new custom software must be open sourced.

For government departments, especially, this policy would improve quality and cut costs significantly, simply because anyone wishing to offer their skills would have access to the information they need.

Absoluteley true. I managed the implementation of something like this (customized OpenSource solution). But in the first year we had to spend real money: part of the contract was an usable documentation of the customized code.

This is spot on correct. There have been far too many occasions where companies get so rushed to deliver they bring in outside help but do not bother getting full documentation sorted out as they did not have enough manpower to begin with, and they then move the outside help on to other projects without getting the sufficient docmentation written, potentially leaving the system in a state which is unknown to the actual employees and will require more input from the outside help if modification is required i

This is not necessary. In fact it is not enough. Both open source and close source applications can be a quagmire where developers simply go and get lost for ages. In fact making the application open source does nothing and proves nothing as far as long term maintainability. Similarly, an open source application can store its data in an absolutely nightmarish format understandable only to itself.

What matters is splitting projects and applications into small understandable modules which well defined and well documented API and make them operate on well defined data flows which are as open and easy to understand as possible.

From there on a module can be thrown out, replaced and modified at will at any particular moment with minimal fuss. Similarly, any vendor which has become too pushy can be shown the door and replaced with an alternative one.

Further onto this the first person to manage "easy" object persistence (like the Open Source Prevayler) should be quartered, skinned, boiled and the remains hanged at down. It is essential for the long term health of a module for it to store the data in a format that is understandable and accessible by third parties and not just itself. Prevayler (and the similar commercial frameworks) break this to bits. In fact it is possibly the best example for an Open Source lock-in tool I can think of.

Just because open source and closed source projects can share the same problems (bad design, obscure data formats, lack of documentation) does not mean that open source is not a better strategy.What would you prefer? That your organisation ran on a closed-source product with all these problems, or an open source one with the same problems? There is a huge difference, because:

1. The simple act of publishing software as open source (especially if it starts like that) involves a wider audience which raises q

Most software written (and especially that which ends up in the consultant nightmare) describes a business process. Whether it's an excel spreadsheet that determines your pricing margins to different suppliers, or an CRM app that lets the business know what customers like, it's hard to let that go, even if you don't publish the actual data, since your competitors would love to know what algorithms influence your strategies. Besides, data is never *really* divorced from code, and certainly it always ends u

Open source wouldn't help any in those situations. You can just as easily stipulate in the contract that they hand over all code to you and it be closed source, you would have to stipulate that the project is open source to get them to release it as well so the problem is bad contracts and employer expectations.I could have consultants make code that is open sourced but I STILL have to train up my own staff (who is busy maintaining servers, help desk, other applications, etc) to be familiar. You get locke

Suppose that a business or government organization, say my city's port authority, is using a software application, say an ERP system, and that I'm an out of work developer (or even an underprivileged minority who somehow managed to cross the digital divide.) Instead of faking a back injury to go on disability when my unemployment insurance runs out (or even resorting to a life of crime) to pay the bills, if the application was open sourced, I could study the inner workings of the application and possibly g

This comes through incompetence - it is too easy to hire outside help, and not setup an exit strategy (you listening, bush and blair?), when you don't understand the problem and won't ask for help. It is easier to get outside help than realise what you will need in the long term, and start hiring people. Oh, but when you need a new secretary, that gets done within the week.

Too many non-IT (and I am sure this happens in other departments) people are put in to manage IT infrastructure, and because they have in the past, feel the need to be making the important decisions. This is what happens.

As for step 12: Give yourself over to a higher power -- your employees.

So, who's going to do their jobs while they "work side by side with the
consultants"? Oh, I know. let's get more consultants in.

This article looks like it was written by the very people you're trying to
get rid of. They can give you pretty prsentations and high-level bullet
points. However, when you look under the covers at the substance. it all
disappears.

Use consultants when you have an extraordinary need, if you really have to.

Better to have them do the mundane stuff, and train you own people to do the
cutting edge, interesting, high-value work....... Assuming they're good enough.

As a consultant, I see it all the time - companies have a really poor opinion of their employees and a slick consulting firm can easily appear to be attractive (regardless of their competence). So organisations really need to understand what consultants can do for them and why they cannot do it in house. A good consulting firm and service provider is worth their expertise and experience.

In general organisations that have trouble getting rid of consultants are really really bad.I have been working on a six month project for two years now and we (as the consultants) are trying to find an acceptable exit strategy for ourselves. But due to staff turnover and limitations of our scope to design (XP/Win2003 infrastructure implementation) work only , we cannot get them over the edge in terms of operations procedures so that they can run with the deployment to 1000 sites.

It is frustrating because we know we don't need to be there and we are losing good personnel because they are not being challenged as they continually need to hand hold the existing and new company staff.

(I work for one of the largest global outsourcing services companies.)One thing I don't see mentioned in the comments so far is mention of a very popular reason that companies decide to outsource. It's related to Step 5: seek expertise. Companies outsource because they do not want to be in the IT business! It may make a lot of sense to outsource some or all of IT so that you can focus on the bottom-line: your product or service. You can treat IT like a utility. How many companies run their own power pl

Better to have them do the mundane stuff, and train you own people to do the cutting edge, interesting, high-value work....... Assuming they're good enough.
But that's (theoretically) why the consultants are so high priced. If, as an employee, I realize my value, I'm going to demand a big raise, refuse to do overtime without pay, and insist I can leave whenever I want. With employees like that, who needs consultants?

Interestingly the article doesn't point out to the reader that they also need to pay attention to the reasons why the service provider got called in in the first place, any why they needed to stay so long. There's an underlying issue there (be it manpower, organisational ability, wrong executive sponsorship of projects, skills, poor control of scope creep, etc.) The underlying issue needs to be addressed or you will be back in the same situation before you know it.

The reason they stay so long is often simply down to inertia. The "We've started so we'll finish." coupled nicely to the "Why did we pay them so much if we are not going to listen to them?".

I used to work for a company that was taken over by an asset stripping industrial conglomerate, to make sure they got the best return for their money they sent in consultants for every department. Sadly, in the engineering department we used lots of fancy computers running non-industry standard programs. So, when the consultant came to look he had no idea what the system actually was doing or what it was capable of. His recommendation was to shift to industry standards, including AutoCad, which the company did despite my best efforts. The company lost its competitive edge as soon as the standard software was put in. I had 2 of the existing suppliers (one the main application provider, the other the hardware/os support company) they both submitted very similar suggestions for the way forward. The application provider, obviously, had a vested interest. The support company had no vested interest as they expected to continue to provide support regardless of the direction chosen.

I presented my own findings and pointed out several flaws in the consultants report, I also presented the reports from the 2 other companies. The only thing I was asked about the reports was who had authorised the spend on the additional reports and when I said they had been provided for no charge, I was told the company had spent thousands on the consultant and for that reason would be going ahead with his suggestions. I resigned at that point.

In case you are interested, the consultants suggestions were implimented in full at great cost and since the old systems were decommissioned the productivity of the company has dropped, which has had the obvious outcome of reducing it in size to about 10% the size it was when I left.

On a plus note, the consultant made me move into a much more enjoyable and profitable job.

I was told the company had spent thousands on the consultant and for that reason would be going ahead with his suggestions.

This is one of the most common reasons I have heard for going ahead with
a consultants recommendations. "if we don't, the money's been wasted".

Never mind that the consultant cost (maybe) 5 grand, and the recommendations cost five hundred to implement. One of the perverse outcomes is that the more your consultant charges, the more likely their
recommendations are to be accepted.

This reminds me of another thing I have observed over the years...Major projects are often started by one person who got this job by leaving the last one just before his identical project came to fruition and as this project is about to come to fruition he has found another higher paid job to do exactly thing on.

These people often say what (they think) is needed, it usually includes lots of buzz words, and charge a fortune to handle it all only to run away before completion when it becomes apparent it wont

For what I've observed, high management just doesn't see any underlying issue. I once have prooved to my old manager that it would be much cheaper and less riksy for the company to hire permanent employees and pay them fairly than keep spending tons of money on consulting and outsourcing for long periods of times. He replied that new employees would be seen as an increase in headcount (and consequently in expenses) as opposed to hiring a consulting firm, which is considered an investment. In other words, it

Thanks to laws (FICA tax, unemployment insurance, etc.) and expectations (perqs such as medical insurance and stock options) an employee typically costs 50 to 100% more than the base salary. Add in risks such as lawsuits, and a $100,000 consultant to replace a $60,000 employee looks like a bargain. Consultants is a capitalist solution to a socialist problem.

Why do companies hire consultants? Most of the time, it's because they don't have the skills in house to develop a project. Getting a consultancy firm in is often easier and quicker than trying to hire all the developers you need. Also, it's easier to adapt the number of consultants than to manage your own IT staff when the team size varies.

On the other hand, as long as the consultants are there, the company does not acquire the skills needed to take over the project. Shuffling around consultants is stil

Hey, careful there! I'm one of those external helpers that a company depends! But I'm neither costly nor incompetent! In any such discussion, it's always helpful to remember that there are often more than one kind of apples: the rotten ones, and the tasty ones!

Or ones that start off tasty, but slowly become rotten over time. And when you try to stop you realize you can't, because you've been eating crack-laced apples the whole time. That should sum up the experiences many have had with outsourcing: great at first, horrible later, but too hard to get away from because you're now too dependent on it.

Certainly there are many good ways to outsource immediate projects but as an earlier poster pointed out, the companies that will benefit most are the companies which are set up the best (sufficient management resources, not taking on too much at a time, etc.) in which there is a single out-of-the-ordinary demand which requires additional support. We had one such project one time for which we brought in 2 outside consultants and had great results, getting the project delivered on time and on budget. The cons

Yes, careful there. I also am an external helper. Currently helping IBM. And its true, a train stops in a train station - but it also starts there. In a similar way, I've stopped working at my work station to write this answer. The whistle just blew. I'm starting work again.

I currently work for a company that does statement processing (the bills you receive). One of our suppliers does the programming that converts the raw data that our customer sends to what is needed to print the bill (or statement).

In one example, the statement remains the same each month, except for an 8 line message that will say that "It's summer - snakes are out...". Our customer pays us (who pay our supplier) for a programming change. I recommended that the message be recorded in a text file, so tha

I work for one of these service providers. Reliance on IT outsourcing is pretty common these days for major companies. Even technology based companies. I feel in many cases that paradoxically, it is a way for the companies to get back in control of their IT which may otherwise have become a self-serving money-eating monster.

Incidentally I would think a large percentage of slashdot readers are in outsourcing.

There is sometimes reasons to outsource; the logic is, thats not a key focus of our business, so why do we have a department that costs us x amout nper year, where as with an oursourced company, the costs go up and down, depending on how much we use them (based on volume).For example, Progressive Enterprises (which is now owned by Woolworths Australia) outsource their employee payment processing to a company, rather than having a dedicated staff for the job, they have a fixed cost with the company who provi

South Australia seems to have an addiction to its EDS contract,but there are more students studying IT, hopefully to take jobsin SA Gov't, to help position itself in an EDS-free place, "anyday now"...;-)A EDS-story has been cirulating in recent years:

The Adelaide Crows (Aussie Footy Team) needed a web site, &
EDS (reportedly) won the contract, after submitting a bid
which estimated it would take 4+ weeks and cost Au$ 32,000.

How do such contracts get written or won? There are very few palms to be greased & a company likeEDS has a lot of "grease" to offer, or so we suppose...

It may not even be like that. Consider your average consumer, who is boldly manipulated by any marketing agency who can buy air time. Now consider what happens when you take the top people from that agency and put them in the room with an executive. It's like a pack of dogs on fresh meat.

Many companies get outsourcing wrong, particularly in IT, because they have have managers who don't know how things work, they've never written a line of code or put in a server in their lives and don't seem to have a learning gene inside them. I work in a company who has a contract with a financial company for a major system, and honestly, I think we're the only ones who care sometimes. Of course we're the only ones who knows how the app works. We're certainly the only ones who seems to know what's going on, and if something happens even remotely related in the general area of our system we have all sorts of people in the company instantly hanging on to our apron strings and phoning us up. I suppose it's because many boring companies, like financial ones, just can't attract the right people who can think for themselves - hence they become even more dependant on outsourcers and consultants than they otherwise would be. When you see how many of these companies operate, you can see why.

This part of the article I always worry about:

You must roll out a major enterprise app on a tight deadline and you don't have the bodies to pull it off. So you borrow some money from next year's budget and hire a global services firm to help.

This never works - ever. Managers of IT projects who don't know much about IT seem to have this incredibly bizarre idea that IT people, programmers and analysts are all interchangeable. You can drop someone from a project two months away from the deadline, bring someone else in who knows nothing about what's going on and the new person will instantly hit the ground running. They also do it again, and again, and again and again. They also equate getting bodies on the project directly with getting it done faster. If something is late and obviously a complete mess it instantly becomes a resource problem. Not that I like calling 'people' 'resources'.

I've seen it time and again. Company gets an outsourcing company and consultants in to develop a system because they don't have the people or the expertise. Said company has no real idea what the requirements are in terms that they can get over to the consultants, they have no real idea exactly what they want these consultants to do and the whole thing becomes a mess with the outsourcing company, quite rightly, creaming off whatever money they can because of the ignorance and lack of clarity from the main company. The company then starts to bitch and whine about the 'leech' outsourcer and the relationship deteriorates. Rinse and repeat the process for the next outsourcing company.

The article can be summed up thus. Fire the useless people in your company and employ good people who can define requirements well, and consequently, can lay it on the line to outside consultants exactly what they want. The consultants will then actually be much happier, because they will know what it is they've got to do - something they probably haven't had much of;-).

I disagree. I've seen it work. The reason it hardly ever works is because (a) managers wait too long before adding staff or (b) they don't add enough staff.

If you have a project that's running behind schedule and you want to add people to catch up, you first have to realize that the new people will be a huge drain on your existing staff's time. Very high-quality people will be less of a drain, and they'll get up to speed faster, but they'll also cost more, generally. Even th

My current project did this successfully. We had a very good, aggressive PM and a couple of excellent team leads who realized about three months before the deadline that the current team of six was inadequate, and that all reasonable analysis showed that they were going to miss the deadline by about two weeks. A naive manager would assume that since there was 12 man-weeks more work than time, and 12 weeks remaining, he needed to add one person to make up the difference. Our PM added six more, and all of the

thus proving the ultimate point of Brook's Law: Adding developers to a late software project will only make it later

Depends on your definition of "late". If your definition of late is calendar-based, we succeeded. If it's budget-based, we failed. In our case, the execs cared about the calendar. I mentioned at the beginning of my post that you shouldn't try this if the budget is a concern, because the only way to skirt Brooks' law is by spending lots and lots of money.

***This never works - ever. Managers of IT projects who don't know much about IT seem to have this incredibly bizarre idea that IT people, programmers and analysts are all interchangeable. You can drop someone from a project two months away from the deadline, bring someone else in who knows nothing about what's going on and the new person will instantly hit the ground running. They also do it again, and again, and again and again.***

This is an example of, as a coworker who had just bailed, once told me "M

Managers of IT projects who don't know much about IT seem to have this incredibly bizarre idea that IT people, programmers and analysts are all interchangeable. You can drop someone from a project two months away from the deadline, bring someone else in who knows nothing about what's going on and the new person will instantly hit the ground running. They also do it again, and again, and again and again. They also equate getting bodies on the project directly with getting it done faster. If something is lat

This never works - ever. Managers of IT projects who don't know much about IT seem to have this incredibly bizarre idea that IT people, programmers and analysts are all interchangeable. You can drop someone from a project two months away from the deadline, bring someone else in who knows nothing about what's going on and the new person will instantly hit the ground running. They also do it again, and again, and again and again. They also equate getting bodies on the project directly with getting it done fas

I am one of those hated consultants, and I see things pan out three different ways:

1. Never ending project. This one usually seems pretty straight forward and then management keeps extending. When those extensions are because they see the value of me doing more, that's fine. But more often than not, it's because they can't get their own staff to pick up the new challenge. Typically that's a result of under staffing.

2. Scope creep. Essentially I'm brought in for something small, and groups are constantly adding on more tasks. When this is combined with the "never ending project" above, I basically become entrenched. I don't mind if it's interesting work, but all too often, after the first few months, I'm doing things that won't apply to any other customer and have stop growing. When I'm on a project like this for 3 times the original duration, I tend to get antsy and weight the cost to the relationship of not signing the next contract to extend. If the work stays interesting, I'm happy to be paid consulting rates for full time employment.

3. The right way. Not many people successfully do this. The thing these customers have had in common is that the staff wasn't overworked and were truly interesting in learning what I was doing and taking over. Also, the work I'm doing typically involves drawing from experience at my previous clients and vendor training. Any extensions are usually to do something above and beyond the original contract, and not to maintain what I've developed.

It's not a bad thing to be at a customer forever if you are always doing something new and doing it faster and therefore cheaper than their internal staff could have done. It's bad when they keep you there to maintain their environment, and it's bad for both the customer and for the consultant, the good consultants at least.

It's not a bad thing to be at a customer forever if you are always doing something new and doing it faster and therefore cheaper than their internal staff could have done. It's bad when they keep you there to maintain their environment, and it's bad for both the customer and for the consultant, the good consultants at least.

Yep. I've been doing consulting and contract work for nearly a decade, and it's in everybody's interest for me to move on regularly. Once you get used to it, the nice part is being able

I'm also one such. We've been darned lucky, it seems, as we've not had this sort of problem, or not much. Our longest running customer for whom we developed quite a number of products allowed us to train and affect hiring practice, in effect making us unnecessary, but still desirable == we still get calls for fiddly maintenance jobs to customize this or that for some big customer of his. Having written the code in question, we can just do it cleaner and faster than his guys, even with the training. Othe

Try consulting with the Government.They are under pressure to cut staff and currently most non-DOD (in the US) organizations are feeling a serious crunch. Once they hire someone, it is near to impossible to fire them, hence they acrue a large amount of dead wood. Their hiring process takes months and sometimes years. This is compounded by budget cycles, hiring restrictions, quotas, background checks, and clearances.

For many of these organizations, it is MUCH easier and faster to get a "beltway bandit" to

I like the turn of phrase "far too dependant" coupled with "wasting a ton of...". Perhaps its just me but if you are dependant on something how can you be wasting something else on it? Dependant means you MUST have it, therefore you can't waste anything else to get it. Sort of like wasting time breathing air with oxygen in it.

Companies use consultants for a variety of purposes:

Short term projects requiring skills and/or capacity the company doesn't currently have;

FTFA: So instead of hiring a contract programmer, you could use Primavera for Services to identify in-house developers who haven't got a lot on their plates, Seka says. In that way, you could gradually transfer work from an outside source to an inside one, without abruptly ending the relationship with your outsourcer.

Except that "in-house developers who haven't got a lot on their plates" are also generally the ones who are unmotivated, lazy, and much prefer to hide in the cracks while collecting their pa

Better requirements. Better tracking.Are there really companies out there who bring in consultants and don't write formal requirements (INCLUDING training your staff to take BACK the project at the end) and don't rack that they're getting what the hell they paid for?

Personally I don't think these places need a 12-step plan to save them, they need to die off naturally and let those who know how to manage their resources get the business.