Iyfjky

Question

Context

I'm an intern in the IT department of an engineering company working on a specific project. My boss is the lead on this project. The project involves taking requirements and ideas from the engineering side and working them into a new application. We have team in a big offshore consulting company which supports us on many other things.

Expectations

For the past month or so, every meeting with the offshore team has started with my boss's expectations not being met by them.

He has some reasonable expectations (at least in my mind):

Get a development server up and running

Provide some sort of examples for him to show to the engineering side

Provide feedback on X and Y requirement provided from things we've learned from the engineers.

But just today he was getting angry saying that he doesn't understand why they don't do specific things:

Capture information and requirements from the engineering meetings

"Pushing [another third party company] to get support in setting up their software"

Providing checklists (vague, but I assume it's for the work to be done)

Creating project plan

Lead more in the meetings, he "doesn't want to be dictating things"

"Drive the project more"

My assumption was that, even though we are a team, because they're offshore and not part of our company it is our job to provide a project plan to them. I thought that it was supposed to work like we give them tasks and they do them but we coordinate everything else with the engineering side and define what needs to be done.

Are these expectations unreasonable?

Are my assumptions incorrect?

This is pretty unanswerable there are way too many situation specific variables based on how clear and consistant requirements are and the specifics of the contract between your company and the consultants. — Mar 11 '15 at 15:22
It doesn't matter what we think, it matters what the contract says. Check your expectations against the contract of work that they've agreed to. If it doesn't match, then you may need to discuss revising the contract. — Mar 11 '15 at 15:45
When you have a meeting with the boss and there are tasks assigned to you, does the boss write them down or do you? — user8365, Mar 11 '15 at 18:50
Nothing unreasonable there. Either the team is very unskilled or your boss is having trouble managing a out of premisse team. — May 23 '16 at 14:51

Joe Strazzere 223k106656922 · Accepted Answer · 2015-03-11 15:19:21Z

My assumption was that, even though we are a team, because they're
offshore and not part of our company it is our job to provide a
project plan to them. I thought that it was supposed to work like we
give them tasks and they do them but we coordinate everything else
with the engineering side and define what needs to be done.

Are these expectations unreasonable? Are my assumptions incorrect?

There is no way for anyone outside your company to judge your boss's expectations or your assumptions.

I will say that, if your boss is the decision maker here, then clearly your assumptions are incorrect, since they don't seem to match his expectations.

An offshore team can be tasked with doing anything. It may not be simple, it may not be cheap, it may not be quick, it may not be the most effective or efficient way to accomplish an objective - but you can hire an offshore team to do anything.

Gaining a common understanding among all parties would be a primary task, if I were running the project. It sounds as if that hasn't (yet) happened.

The difference between hiring a contractor versus a carpenter. — user8365, May 23 '16 at 14:54

jcm 543410 · Answer 2 · 2015-03-14 04:13:11Z

I work as a member of an offshore software-dev team. The expectations you stated don't particularly sound out-of-scope (for our particular case, at least). Let's look at them one by one:

Capture information and requirements from the engineering meetings

We meet with the clients everyday via video chat. "Capturing information", of course, is a given. Our team is also expected to flesh out and clarify requirements from a technical perspective. In some cases we provide significant input to the overall software design.

"Pushing [another third party company] to get support in setting up their software"

We use a lot of third-party services that

A. interact directly with the deployed software: hosting, logging, performance monitoring, pub-sub, etc.

B. are more for dev use: source control, continuous integration, etc.

In both cases we need the client company to authorize our accounts. However, things like hooking into the logging service's APIs are our responsibility. We are expected to be able to get things working, possibly by contacting the third-party provider. If they're being unhelpful (this hasn't actually happened) we can escalate to the client company.

There are a few cases where it is the client company's responsibility to communicate with the outside providers. These are clearly defined.

Providing checklists (vague, but I assume it's for the work to be done)

This is vague, but here are examples of checklists we are expected to provide:

Steps to reproduce an issue (if we reported it).

Steps to test a fix or feature (needed when testing requires fiddling beyond the software product's front-end)

Creating project plan

This is also vague. Sometimes we are tasked to provide a plan for a large but specific task. For example "Migrate all [third-party] API calls to the new API".

Lead more in the meetings, he "doesn't want to be dictating things"
"Drive the project more"

We are expected to provide input across a wide range of subjects: from process improvements, software design, possible business impact of technical decisions, technical issues, etc.

Of course, whether something is in scope or not depends on what the team was hired to do. More experienced (and thus more expensive) teams are of course hired to do more than just watch logs and write code.

HLGEM 133k25226489 · Answer 3 · 2015-03-11 15:27:22Z

I can only talk to our offshore team, but some of your boss's expectations seem reasonable to me and are in line with what we expect our offshore folks to do. It doesn't mean that you might not have to do them at some level as well. For instance, do they really have access to the stakeholders to get the business requirements? Maybe a more reasonable request is that they review requirements and ask questions about them. Asking them to create documents from meetings they attend is good though. More importantly, it helps you see if they understood what was said. Of course they could be resisting doing it because they actually didn't understand well enough to make the notes. You should have a project plan at a high level, they shoud be creating amore detailed one that they wil be using.

Now I say this because our offshore team has technical project managers as well as devs and so they can do this sort of thing (as well as time estimates for upcoming projects and other management tasks). If all you hired were straight devs (especially if they are all freshers), then some of these expectations could be unreasonable. These are the tasks of senior people not devs at the entry level or intermediate level even if you are onshore.

It is also level of performance that it took more than a year to get to. Remeber when you start an offshore project, you have new people who don't understand your geographuic culture, your business culture and your business and are new to the project. Not just a couple of new people but every single person is new to working on this project. It would take a long tiem for onshore people to get up to speed too if everyone was new and they have fewer things to overcome. Offshore is often perceived to be incompetent becasue of other issues that are not their fault.

So if the expectation is reasonable may well depend on the type of people you hired offshore. If you hired a team of trainees onshore, would you expect the same level of work as if you hired a team of experienced devs?

You also likely have a cultural propblem and they are as frustrated with you as your boss is with them. Devs in other countries are often managed in a far different manner than they are in the US and are allowed far less freedom of action. There is a a much stronger hierarchial approach to tasks. So they are expecting to be told exactly what to do. They often expect requirements in far more detail than you might be used to. They might expect far more documentation fo teh existing system. They might be culturally primed to use indirect methods to tell you that they disagree with something.

You and your boss need to read a book called Speaking of India. (http://www.amazon.com/Speaking-India-Bridging-Communication-Working-ebook/dp/B004AE3R3O/ref=sr_1_1?s=books&ie=UTF8&qid=1426085379&sr=1-1&keywords=speaking+of+india) I am making an assumption your offshore team is Indian, but if it is not, seach for something about the business culture of the country where they are located. And if you can't find anything ask them to recommend something and if you still can't find anything, then read this book anyway as at least it will make you understand how different cultures do busineess differently. The book is not perfect, but it will help alot.

Another thing that helps tremendously is bring one or more offshore people to the US for a few weeks. It helps them see how you work, it helps make personal connections that ease your work relationship and it helps you learn to understand them better. More imporatntly, it shows your company is committed to making teh project work and is committed to the people on the project.

You need to stop thinking of your offshore team as being in another company (even though they are) and start treating them as team members. Get to know them personally, chat with them as well as give them work. Give them the information they need that might not get distributed because they are not on the email chain. Make sure that other company people like your IT department include tehm on teh emails telling when outages will be occuring, etc. Be onteh lookout for ways to make them feel part of the team.

Managing offshore projects is much more difficult than it appears. There are so many obstacles to get past. First, do you know the actual experience level of thepeople on your team? Are you expecting work that you would not expect a local dev at that level to do? If you hired new devs onshore, would you expect them to be up-to speed immediately even if they were more senior?

You also will need to cope with cultural issues, timezone issues (you have to allow for more time for every oproject due to this, if they get stuck at 2 am your time, you can't answer their problem until the next day.). You have to allow for communication problems and you find that you need to check for understanding as sometimes they don't hear wahat you say correctly due to the differnt accents you have, sometimes the phone reception is not good (and they wil be reluctant to tell you that until they know you really well). Sometimes the issues are more of inexperience in development period not in the fact that they are overseas. It is a whole lot harder to get a trainee up-to-speed when you are not inteh same geograhic location. Then there are the problems of being remote in that they are stuck when the remote connection is broken (hard to program against a database you can't actually reach).

Anotehr issues is that sometimes we have a certain level of prejudice and that comes through in dealing with them. This is espcially hard to overcome when friends of yours were replaced by the offshore team. So you and your boss need to be aware of what assumtions you are making about them and if you are letting your irritation with having to deal with offshore show through.

They're senior resources is what I was told (and he calls everyone a resource on his team as far as I'm aware, including me). But my boss himself is Indian as well so knows much more about the cultural gap than I do. We also have one person from their company that is working with us in our location as well. — Mar 11 '15 at 23:28

Joe Strazzere 223k106656922 · Accepted Answer · 2015-03-11 15:19:21Z