Is mobilizing the implementation team to the client site to do the full cycle of implementation recommended? In other words, what are the pros and cons of working on client site other than in our own offices?
If it is recommended, what are the proper environment requirements I may ask the client to provide for my team?
I'd be very careful about moving your team. Humans are creature of habits, and your people might not be very happy to trade their nice little office, with its quirks and posters and pictures of their dog, to some anonymous short-term cubicle.
We almost lost a programmer at some point when the project leader insisted on moving him away from the software team to a dreary cubicle just so that his whole team would be in the same room. Proximity has its pros, but not if it means sucking your developers' soul away.
Its very common to work on-site. Sometimes its good to work on-site even if you can do everything remotely - this lets the customer get some face time and may set them at ease that the project is moving forward. Sometimes it depends soley on the client.
Typical things to ask for are workspace and a connection that has internet access.
depends on the project...
if it+s a small one, there is no need, just do the application and send to the client to test, if you need use a Virtual Machine with the client OS and test the application in that environment.
if it's a big application, I would suggest to use a project website where you, your team and your client follow the application process, download updates, add bugs, create milestones, etc...
every time that I need to build sw to more than 1 person (client side) I use this procedure.
There are several project tracking sw on the web for this, but... never go to the client to make the application! you can go there, for patches, bugs that you can't find in your own environment, etc...
Client should only get what they asked :) and if it's a big project, give the client transparency using a web project manager, like Trac.
hope it helps :)
first, ask your team if they want to go! if you can work effectively off-site, do so. if would be a shame to get a hand full of reasons to move the team and then find out they'd rather find another job than crouch in a stranger's cube farm.
an offsite team at the customer's site can also breed resentment among the cube-dwellers, especially if they think the offsite team is a 'threat' or is being 'paid more'.
this is all about politics, not development. Interfacing with the customer is important, and should be ongoing, but be wary of disturbing the status quo both at home and at the customer's site
There are many pros and cons to working at a client's site.
The key pro's:
Communication is hugely improved.
The ability to be able to walk over to someones desk and chat about a particular problem or piece of functionality can save weeks/months of effort.
It's so effective because it's vastly easier to discuss something and focus on it with diagrams or documents at hand, then to discuss it over the telephone, or document it on in various ways.
The team (the client and development groups, can form relationships which often aid in the success of a particular project.
Visibility of the entire team is improved.
This certainly highlights problems quickly, which aids in the success of a project.
The key con's:
Developers may not like the distraction of working closely with users, this might lower productivity for developers.
Visibility is improved.
This can be a double edged sword.
Making working on site may force you to choose some staff over others, or might mean some staff choose to leave the team, due to personal circumstances or preferences.
In my view it does hinge on the way the client and your team work, but in my view having at least some of the team at the clients site is invaluble.
This has literaly saved months of effort in my experience.
What you can ask from the client depends entirely on the contract you have with the client and your relationship with them. Whatever you ask for mustn't deviate far from what the clients staff have access to, as this will possibly cause issues between you and the client's staff.
I would say it's more depend on the type of project, than project size. We are working on customer hardware and integrated with large number of customer software modules. So we are actually insist on 1 or few on-site integration weeks (this depend on the project complexity rather than size).
First week usually hardware/software bring up: getting familiar with customer hardware, debuggers etc. After this depending on the software integration complexity we might go on-site few more times.
Since working on-site is a common practice, we notify all our stuff that working on-site is part of work description during recruitment process.
Now, going on-site for the whole project, we most likely refuse for 2 main reasons:
So you should ask you self why customer want you on-site, if complex integration require it's reasonable request, but usually not for the whole project. If customer want to monitor you there is much better ways to do it: Weekly status calls/meetings, intermediate milestones deliveries etc ...
Another pro is obviously changing the atmosphere. It usually fun going on-site (for a week i mean). You meet new ppl see new places etc...
For managers it's good as well since programmers that, see the customer, see the final product, understand the deadlines usually more committed to the projects.
Aside from the issues already covered by everyone else, there's the question of whether or not you already have software deployed at that client's site.
If you do, then you need to consider that the team may (in my experience: will always) find themselves being used as the first port of call for support issues and side-tracked with general questions about the previous system. That level of disruption can have a significant impact on development times.
One of the main reasons for being onsite is to build a close relationship with the client and that can be tricky to balance that with the need to protect the development team from issues not directly related to the current project.