- December 23, 2008
- Posted by: admin
- Categories: Agile Applications, Agile Project Management, Blog, Communication, Enterprise Agility, Outsourcing & Agility, Requirement Analysis
My question is based around the importance of an onshore consultant for business analysis, requirements gathering and providing a front face to the client in an outsourcing/offshoring scenario.
IMHO there are several advantages such as solid communication(specially if the onshore consultant is from the same cultural and ethnic background), efficient requirements gathering, project security and higher trust levels.
I would say that a local SI representative is necessary but insufficient to ensure success. Communication is the issue but if you rely solely on a single representative from your vendor, you will most likely still face significant challenges. I have been involved in two out-sourcing engagements and find that the best approach is one where teams cross-polenate; that is there is a representative from the SI at the clients but just as important, there is a client representative at the SI site. As Gerald Weinberg stressed in the “Problem Solving Leadership” course I took years ago, software deveolpment is a social activity and you must commit to developing a solid relationship with the stakeholders.
There are many advantages by having a solid onsite presence during the project execution. Some of them but not limited to are given below.
Customer Relationship Management
– Understand and observe the customer feelings (feedbacks) and communicate to offshore early as a warning mechanism
– Requirements gathering
– Discuss with customer for scope management and convince them in change request if the requirements found are not captured in scope activities
– Fill up the presence say for ex Hi-Bye meetings to ensure that customer’s requirements and necessities are well taken care of
– Provide Technical expertise
– Attend the offshore-customer weekly calls along with them and provide back bone support to offshore
Account Management
– Find out more opportunities and convert them into win-win situation
– If T&M project – find out more opportunities to increase the resource and in turn increase revenue/Gross Margin
Regards
Srividhya Ganesan
As a project manager who has led many offshore efforts, I believe that having real analysts and architects onsite is a true critical success factor.
While most of my work is done via online collaboration technologies, there are way too many opportunities for miscommunications in a completely offshore environment. The one exception to this is where very detailed, high quality specification are available — but very few companies will invest in developing those.
There are technology issues as well as time clock issues to overcome. In my experience, offshore talent is not available for user meetings during North American work hours, so communications tend to be asynchronous. This offline communication style multiplies the risk of misunderstandings.
Rea analysis is a give and take, back and forth, listen and repeat type of effort. It does not successfully lend itself to batch communication separated by 12+ hours.
What we’ve realized is that most North American projects with a significant offshore component requires that most of the team to have highly altered work days, often in the middle of the night. I don’t often have continuous access to business user at 2-4 AM.
The second big issue is that analysts must be available where and while their products (architectures, models, etc.) are being used. We have found that a physical and time-based separate of support for those using the models is a huge risk for misunderstandings and miscommunications for both the architects and the developers. The approach of developing models and throwing them over the wall for the development phase of the project *will not work*.
Having competent, real analysts (not just programmers waiting on the word to the start coding) on site is required during the analysis efforts and having timely and easy access to the analysts during the development efforts is required.
For one thing it helps maintain the trust of the senior management of the company doing the offshoring. It also maintains some control and monitoring of the lifecycle at home.
Do you really want to take a task that will effect your bottom line and give it to a set of people overseas who you don’t know, and just *trust* that it will get done with no safeguards ?
There have been a number of studies done on the subject of outsourcing, with one from the June, 2008 issue of the ACM’s Communications “A Risk Profile of Offshore-Outsourced Development Projects” by Charalambos Iacovou and Robbie Nakatsu. It states that the major areas of concern are vendor/client communications, client internal project management and vendor capabilities. Having someone onsite who is experienced in software development and the problem domain can greatly improve the effectiveness of the outsourcing effort. Gathering requirements formatted toward software engineers, addressing in detail software oriented issues with the client, integrating joint software development processes, onsite troubleshooting, etc. With over 12 years experience involved in offshore embedded development, I know the model does work if you have the right people.
Even with the bulk of the work overseas, it makes sense to have a project coordinator local. Better way to obtain feedback. Plus face to face meetings have a different feel. Nothing against video conferencing, but the local rep is likely to be much more facil dealing in the local language.
As a customer of a lot of outsourced software development, I can say that I get a lot of value from an on-site presence but prefer the on-site person to be from the ethnic background of the out-sourcer. Outsourcing leads to a lot of phone calls, video conferencing, e-mail, and other forms of “non-contact” communication. The culture gap tends to magnify misunderstanding. My expectation of the on-site person is to very accurately determine what the gap in understanding is about and communicate this back to their people in their peoples language. Having an on-site person that is just like all of the people I already have will look more like having redundant project managers on the same project.
As a customer of a lot of outsourced software development, I can say that I get a lot of value from an on-site presence but prefer the on-site person to be from the ethinic background of the out-sourcer. Outsourcing leads to a lot of phone calls, video conferencing, e-mail, and other forms of “non-contact” communication. The culture gap tends to magnify misunderstanding. My expectation of the on-site person is to very accurately determine what the gap in understanding is about and communicate this back to their people in their peoples language. Having an on-site person that is just like all of the people I already have will look more like having redundant project managers on the same project.
I would add some thing from my experience here. As a Account Manager, i have successfully deliver many software projects from offshore. What i could learn is 90% of the projects are failed due to poor communication. What i feel is having a on-shore consultant is helpful when the offshore PM, or the team is weak in communication. But the consultant should be able to understand the ethnic background of the offshore team to fill up the communication gaps with himself and the client. But ideally you should have a PM who is good in communication. Which is good for the project and cost effective too.
I agree with most of the answers, most of the times the onsite person is expected to be a jack of all trades making him/her as a single point of failure. I have seen in bigger projects to have key people in the offshore team to be people who went back from onsite engagements, knowing the pulse of the customer, they tend to take care of a lot of day to day activities. A single point of communication for multi million engagements is a recipe for failure.
In my oppinion the top three reasons that onshore presence is essential in offshore engagements is:
1. To bridge communication gaps due to cultural reasons but more importantly because unless you are talking about COTS product development knowledge of the business landscape that the software or solution needs to provide value for is just too time consuming to convey and maintain fully to the offshore team.
2. To provide faster and better issue/query resolution between customer/intended users and the offshore software team.
3. To continually manage expectations on both sides of the engagement, and make sure that neither is stuck in their own process waiting for input/delivery from the other side.
As you can probably tell from the above points; in my oppinion a skilled onshore ressource as hard to find, as he/she needs to have a solid business understanding, a solid technical understanding, good communication skills as well as project management skills.
Just to clarify after reading Pravin’s very valid point:
In my oppinion the onshore ressource should NOT be the channel that all communication is filtered through, as this will indeed make him/her a bottleneck of epic proportions, however the onshore ressource should the facilitator on the sideline for improving communications.
Agreed with the most arguments across this discussion. On-site presence is essential success factor in geographically distributed project environments (off-shore projects are the most illustrative examples, although the same is the nature of the problems / successes in multi-site projects in large cross-border organizations).
I also support the point of cross-polenation that Richard Martin stated earlier in the thread. In Cogniance, we accomplish it by inviting our customers for frequent off-site visits to our engineering labs. It is typically associated with important project milestones.
I believe that there are 3 key aspects of an IT project that you should never hand over to an off-shore company:
1) The project management needs to be a reflection of the client control at a product level (that is, how the work is done may involve outsourcer PM planning and tracking at a technical level). At a coordinating/controlling level the client PM ensures that the work is integrated with what else has to be delivered. When you consider “smart sourcing” you enable options to get the best talent where it can be found, it is just that the people that do the work are not on the client payroll.
2) The business analysis and change management need to be performed from the client side. The key is that the specifications must be complete enough to allow the procurement of complete modules as deliverables to be integrated. Change management needs to reflect how client needs are subject to change that must be implemented in the enabling software too.
3) UAT test efforts must be performed on the client side as well. While all development testing will be a vendor responsibility, making sure that code meets client expectations is part of the acceptance process linked to the payment for services. Again, this can be modular, so that vendors are not put in a financial squeeze for delivery of complete systems. Integration is potentially a separately contracted deliverable.
The technical work can be outsourced to vendors best capable of that kind of work. There are so many options that to assume it has to be a single source is not necessarily the best strategy. Many of the comments have a focus on communications pitfalls that you can avoid if you structure the work so that it can be delivered in modules by the resources deemed to be most effective for that purpose. This is a far cry from having a couple of outsourcing vendor representatives (that implies dealing with one vendor), as it forces a structured communication in writing between the client and the vendor for a specific module that ensures the developers work from a solid set of requirements. Anything less smacks of throwing the problem over the fence, and hoping for the best, which is not in keeping with the Cobit framework expectations and which could be in violation of the SOX management accountability requirements. Remember, the fact that you outsource does not diminish the client’s liability in the event the resulting system fails to meet the governance expectations.
I agree with you and the individuals answering. Experience is showing that you cannot offshore the client relationship, creativity or judgment, so keep the project management and business analysis onshore. Therefore, you should expect some additional overhead related to communication, documentation, and clarification of expectations. Once requirements are well documented in sufficient detail, you can offshore the labor (i.e. programming etc).
I believe, the tradeoff lies between
-> Increased product cost, and
-> Relative Ease of Acceptance
Situational decision could be taken by utilising these aspects mainly