Hcfyk

Please don't mislead yourself, you are nothing more than an external contractor to the company. You are NOT part of the company, so there is no legal or moral reason to grant you anything more than you already have. You don't belong to the company, you are not their human resources, you work as a provider-client relationship.

You have been paid, right? There should not be any reason for you to go above the boundary, it's not your company. Please don't be emotional. If you're not given resources, simply ask. If not granted, it's not yours.

Someone that pass through a similar situation has some advice on how to solve this problem?

Simple. Send your invoice to your client for your time.

This is normal. The client doesn't have a good development team, so they contract some of the work to you. Their development team realise that you are a threat to their jobs so they have no incentive to help you.

Their manager should have been aware that this was going to happen, and there are various things he can do to solve it, but that's not your problem.

Your problem is how to ensure that these delays don't make you look bad to the person paying the bill. Make sure he's aware that there are problems and ask how you can help him.

Maybe he'd like to know about email queries that are unanswered after a week, or maybe he'd like to be CC'd at the start. Maybe he'd like you to fix the other team's bugs and just bill him, but maybe he wants to approve each one.

Email the requests to the client team, and follow up with an email after the amount of time it would have taken you to comply with that request. CC this (nicely worded) reminder to the boss of the client company. They will either ignore it or help you out. If they ignore it, you have the paper trail to prove you are not the ones slowing the project, if they help you, all the better. After some iterations the boss of the client company will think of a way to reduce his spam-load, and give you a quick pass through (Some person just passing along the messages, as your own personal VPN).

In parallel, try to establish a personal relationship with one or more members of the other team. The petty communication outages that they produce are a sign that they harbor personal resentment. This can often be remedied by face-to-face meet ups. I stress personal relationships. Not the 'let's implement X'-kind of conversation, but the 'public transport sure sucks, huh?'-common ground kind of conversation. Let them see the humans in your bunch of know-it-alls , and try yourself to see the humans in their bunch of nitwits.

Client is well aware of the situation but he seems he wants to do
nothing to solve.

So, you've brought this to the attention of the "powers that be" and they're not interested in fixing the problem. I assume that they pay you for all of this "extra" work that you perform? If so, then either continue performing the work and continue getting paid for it or fire the client. There are no other options.

Ask for a regular status meeting with the client (hopefully you have that already but I get the sense that you don't). (NOTE: By regular I mean at least weekly, if not 2-3 times a week. If you can swing it, a stand up every day would be ideal.) During this status meeting, talk about the roadblocks you currently have... list them one by one, what you need, what you are waiting for and from whom, and what the dangers are if the request isn't filled in a timely manner... the project quality will suffer, you will ship late, etc.

We sent an email last week that we need X from the suppliers and that we would need it within a week in order to not put the project deadline in danger. We are rapidly approaching a week since our request. Do you have any updates on when we might get X? If we don't get it by this Friday, we will have to push back the delivery date by a week.

We sent an email last week to Jim asking for clarification on the Widget code. We can't proceed until we get that clarification. When can we set up that meeting?

and so on. Don't be accusatory or emotional, be factual, be clear about what problems this issue is causing or will cause to the project. When you don't get X for 3 weeks and you needed it the next day, no one should be surprised when you state that the delivery date will slip by 3 weeks.

Once things start looking like you won't ship on the initially agreed upon time, start communicating regularly with the client management. Inform them that the X, Y, and Z delays that you have notified them of are of their teams' doing and will put you past the scheduled timeframe. Any additional work past X date will incur additional at the rate of $Z. (Maybe it's too late to do some of this but you can at least start dropping hints of contract renegotiation due to delays beyond your control and of the client company's making).

Here is what I read:

• We are great


• Client not so much


• They don't like us

Pro-tip, sometimes it better to be liked than right. Who do you want to be friends with more, the boss man, or the workers? Boss man pays the bills so always be his friend. But sometimes it helps to be friends with the workers also.

So instead of "Us" versus "Them", try to make it "We".

Rule #1: BE NICE

I'm sure you are always very professional, but from what you said in your post, I'm doubting you are always nice.

Sometimes a friendly visit to the client, box of donuts/candy/meat-veg tray/ice cream/movie tickets/etc... can go along way. Basically say, "we want to get along, we want to help you, we are on your side."

This isn't so much a reward, since it doesn't sound like you are in a position to reward or punish. Its more about trying to change the perception of the other team about you from "they are our enemies" to "they are our friends".

Rule #2: Be in control

If I was manager in this situation, I would say, "how can we manage the code better".

If possible, I'd maintain a separate Git repo, where you can add their contributions as separate pull requests. If they are stuck on SVN, so be it. You can give them your contributions as big single commits. Even if you have to move the code manually, its better than the client team screwing up the repo your team depends on.

Don't let their bad commits and bad SVN practices control your productivity.

Also, like the other posts said, document communications in case you need to CYA.

Good luck!

Document each request, each complaint, and the hours wasted trying to work through the internal team to get the resources you need.

Right now, the internal team is fighting you because, so far, you have proven more capable of handling the application and are upstaging them - they are retaliating by making things more difficult for you.

Continue to provide the support you have thus far, and keep your client in the loop about all of these hang-ups. CC them, if you can, so that they are well aware of your attempts to keep things moving.

Eventually, they will have to confront this issue - but this is not your problem to solve. Your only concern should be getting your own work done, and showing that you are doing everything you can to get the resources for that work.

So long as you are doing your work to the degree you've described thus far, with the only complications being the internal team, they should have no reason to break off ties with you (though, they may want to consider restructuring that team - but again, this is not your problem to solve).

Where is the client internal team located? Is there a possibility that somebody from your team can go to the site where the internal team is located? I have had experiences in the past with teams that were difficult to work with, and I find that the best solution is to just go down and talk with people directly. I have had to spend entire days tracking down information myself from internal teams, just because the communication and initiative was simply not there. There is no need to be abrasive, or confrontational, just show up and get the communication lines established. Find out if they have a weekly meeting and have someone attend it. The bottom line is that the other team is struggling and your work is showing that to everyone. They are defensive for a good reason, so just show up with the attitude of "how can we help each other?". Maybe you can start doing some mentoring, or help them improve their process. You are hired as consultants not just to deliver the project, but to enhance the company/team.

So I've read the existing answers and there's more to deal with.

Send your invoice to your client for your time.

Correct; however we also now have an employee morale problem on your side; or if we don't we will soon. Whatever cheapish things you can do to keep morale up, it's time to start doing them.

You may have to approach your customer with something along the lines of "Due to certain problems on your side causing an employee morale problem for us, we have to increase our future rates for you by about 10% so that we can buy perks for the employees." But please, find somebody more diplomatic than I.

Other answers covered how to cover the financial side of the things. Now, if their damage also causes you unnecessary anxiety and setbacks that extra money alone can't fix, you can eliminate that damage alone. For example, with these measures:

• Don't work on the same codebase. Only merge their changes occasionally (to drastically limit the time spent on pointing out their flaws again and again) and only after they pass your scrunity.
  
  
  
  
  • You can rationalize this to the client as smth like: "Their code is not up to our standards so we have to bring it up to them each time before incorporating it -- otherwise, it costs much more of our time and your money down the line".
  
  
  • Incentivise them to merge your changes back opportunistically by smth like: "Otherwise, it will cost us disproportionally more time on the next merge."
  
  
  • You mentioned that they are using SVN. You can use Git internally 'cuz it features much more advanced branching and merging logic, making complex merges much easier. (Git comes with a two-way SVN bridge out of the box.)
  
  
  
  


• Don't fix their bugs for them as an integral part of your work but rather as a separate activity (e.g. as a part of the above-mentioned scrunity) so that it's easy to separate it from your regular work and easy to bill for it separately (plus the client will see exactly how much their staff's incompetence is costing them).


• If your part of the work depends on some modules provided by them, warn the client that you will not complete that part of functionality if their module doesn't arrive in time. Only work on that module once the client explicitly asks you to and in the same manner as above.


• Offer to coach their staff as an extra activity but only if they themselves are willing -- from code reviews (e.g. during the above scrunity, let them themselves address the flaws) to teaching them the best practices.

The customer (here: the client) is always right. As long as the customer pays. So as long as the customer pays for every hour you work, it doesn’t matter if their team is lazy and incompetent. If your job takes three times longer, you get paid three times as much.

Of course, as long as the customer pays. So you should have a log about anything you asked the client team to do, and when it was delivered, and with ho many bugs. So if the customer doesn’t want to pay, you can show them why things take so long.