What is the one most important reason projects fail when done by external systems integrators?

Question

Our company is engaging an external Systems Integrator to develop its new mission critical system. I was hoping to compile the likely reasons it will fail so that we can anticipate these and safe guard against them.

Answer 1

from my experience i can say that Communication, i have seen many projects fallen due to this reason.

Answer 2

I've been on both ends of these systems integrations. One thing that holds them back is pushback from the company employees. I've seen times where the company employees that are suppose to be helping with the integration want nothing to do with it so they do everything they can to make life harder on the system integrators. Really need buy-in from your own employees.

Of course you need to make sure that the system meets the companies needs. Need clear communication on what is expected. Must have a timeline! I've seen projects like these go on forever because there wasn't a clear timeline.

Answer 3

You must clearly define the expectations your company has for the project and then manage any scope creep that might occur thorughout the project. Without a clear plan and good management of scope a project can derail quickly.

Answer 4

I will quote from an article from Joel On Software, In Defense of Not-Invented-Here Syndrome :

"If it's a core business function -- do it yourself, no matter what."

Ask yourself if this system is really mission critical, and core to your business.
In the end, nobody knows your company as you do.

Answer 5

I have to agree with Aurelio, It's better to build core things yourself.

The trouble with consultants are many and varied, but at the core.. .they're not your people. You don't have full control over their time or the way they work, and frankly... they don't have a stake in your company and are not as motivated as you are.

Odds are that the system will be late, of average quality, be hard to maintain and not be exactly what you want. There are ways of avoiding this, but it's rare and it takes special effort from both your company and your contractors.

Things to do:

• Work closely with the contractor. Make a 50/50 team, and make sure that key people in your organization sit very close (same room, within 10 meters) to the developers and have ample time for questions and discussions. They should really know the business and also have the authority to make decisions regarding design.
• Avoid strict contracts. It's better to be flexible and open to changes, so you get what you need instead of what you think want. You can set a fixed number of hours you want them to work on the system, that's better than setting a fixed scope.
• Insist on using continuous integration. Enforce unit tests, peer reviews, automatic builds, code coverage and automatic deployment. By having a machine do those things for you can make the burden of integrating much easier.

I could list a lot more, but these are at the top of my list

Answer 6

In my experience, consultants have different sets of goals than you do. You have to live with the application that is built. You have to maintain it. If you were building it yourself then you would be extra diligent to make sure the code is tested and maintainable. External consultants, on the other hand, get paid by getting stuff done. They are not as likely to care about quality or maintainability.

Answer 7

Usually in system integration it is "us" versus "them" kind of mentality which almost always guarantees the project will fail. There has to be a person responsible for the integration with representative from each team, this person has to be from your organization and he has to be technical enough to understand both projects and knows both team. So when an issue comes and it is one of these grey areas where it can be on either sides. That person would have a call on that and where would it and it would be respected on both sides

Answer 8

There are many risks: adverse selection, misalignment of interests, poor communication, loose fit criteria, internal politics within your organisation, a more important and lucrative project for the integrator that is going to suck valuable resources working on your project away from it, lack of business knowledge on the integrator side, lack of technical competence, disinformation etc.

Obviously that's why someone on your side has to oversee, co-ordinate and manage the entire effort. But this is pretty much standard stuff and what is that managers are for.

However, one thing that makes external integrators different from in-house team is when things deviate from envisaged plan you have much less negotiating power. An illustration would be that when something is omitted from the spec or implemented not the way it is fit for your business you have to go through a long negotiation process and often make trade-offs, the integrator will often use your cock-ups to renegotiate their own and a result is compromise.

With in-house team this is less of an issue and you just do things that need to get done and there is much less hidden agenda as opposed to when dealing with an external organisation.

Answer 9

Same reasons an internal project will fail:

-changing the project mid-stream -lack of clear project scope -lack of support from management -lack of clear understanding of what the client/customer wants/needs -holding back resources needed to execute the project -lack of a reasonable project time-frame

And others.. Its really going to be the same as an internal failure. Run the project as you would any internal project and you should see success.