Does anyone know any good process for off shore project? My client is in different country and I need to convince them that I have a good process to handle all project issues even though we are geographically dispersed. Pls give your advice and resource link. Thanks a lot.
There are many ways by which an offshore project can be handled... however, there are some issues which in my opinion should be addressed properly for a successful offshore development. 1. Scope management: Many projects are simultaneously done at offshore and at onsite. Therefore scope should be clearly defined and controlled so that the offshore and onsite do not get in the way of each other. 2. Communication management: Offshore team and the onsite team are geographically separated and hence all issues must be quickly addressed to prevent any schedule slippage. 3. Version control : This is very very important specially if there are both offshore and onsite teams doing simultaneous development on the same region of the system... reasons are obvious. 4. Requirements management : If the project is conducted entirely at offshore, the client may often see the final product only after delivey. Thus the development team should understand what exactly is expected. 5. Quality Assurance : All these points (and others ) will be addresses in a strong quality assurance program. You will have to define process models , so as to develop guidelines how every offshore project should work and then tailor individual projects into one of the defined models. Qualit Assurance Programs will have to carried out to ensure adherence to these standards. I may have written a lot of rubbish. Others can also share there opinions.
Would it help if you said you used XP - XP is mainly used for small projects and a majority of the offshore projects are not that large. XP has its own set of universal rules - pair programing, daily builds, tests first etc. Maybe these could help convince your client .. I am assuming the project is not large - around a 10-15 member team..
There are only 10 types of people in this world; those who understand binary and those who dont<p>Varun Narula <br />SCJP, SCWCD, IBM-486 (UML)
subhrajit has summarized it succinctly the key point of the projects. whether off-shore or on -shore. I really feel client / customer won't be interested in which methodology do you use. they will be interested in schedules & the deliverables from you. the first & the most important aspect is Requirement Engineering. sit with cutomer & try to understand what they want ? also see what you are understanding is the same as they are saying & put it in black & white. even , XP wants these things to be documeneted. infact , here the attitude of they & us between developer / analyst & cutomer can be dangerous to the project. so either customer stay with the development team at offshore palce or developers stay with customers place till everything is understood by everybody has become important today. here also , if you want to go for prototype or not shall be finalized with customer. make your deliverables very clear to cutomer ( phase wise / iterative delivery ) & also inform about the things like user acceptance test , unit test , regression testing etc. & involve them in those phases. thus , there should not be any problem while delivery. making customer partner could be best strategy in off-shore development. thus , these points like requirements , schedules , tests , change requests from client & their impact on the project schedule , costs etc. is discussed . at your end , you use whatever methodology you want. ultimate thing for the client is timely delivery of quality , robust product meeting all the cutomer requirement. i may have spoken rubbish. please improve my understanding where I am wrong.
I come from the point of view of using off shore development for some of my company's development projects. The most important things are: 1. communication: This is paramount. You cannot ask enough questions of your client. There is no stupid question. I was thrilled when we got to the point that the guys in India were asking perceptive questions about what the end user would be experiencing. They were really trying to understand the end user experience and not only just the requirements I had specified. That was great. 2. I agree that version control is critical. We used MKS and so did the off shore team. This was helpfu. 3. Detailed specifications. One additional cost is that we had to be sure that our requirements specifications were detailed enough. We could not make too many assumptions. That is why it is critical that you ask all of the questions that you have... don't hesitate, because you will be blamed if you assume incorrectly. Good luck!
straws are for suckers. tiny ads are for attractive people.