It is becoming more commonplace these days for the team doing the Salesforce implementation to not be physically co-located. In fact, it is very likely that your next Salesforce project will involve a physically distributed team. How can you adapt your project management, design, development and overall project communication style to deliver a project of this nature and be successful at it?
It is crucial to pick tools that facilitate communication among the team members during regular project meetings and at all times during the course of the project. The choices for online communication tools are quite diverse these days but I find that the best criteria for choosing the right one are: audience and price. Survey your team and find out what they like to use. Whether it’s Skype, GoToMeeting, Google Hangout or Join.me, make sure most of the team is familiar with the tool. Use it to run your regular project meetings. I highly recommend selecting a tool that allows you to record the session. This is especially important if your meeting is geared towards requirements gathering or is a meeting where you expect to make important project design decisions. You wouldn’t believe how handy it can be to be able to go back and listen to what has been discussed during the call. And don’t forget to let people know you are recording. I always make sure to ask if everyone is comfortable with the call being recorded.
When working in a distributed team you will find that you can’t just walk over to your teammate’s desk and confirm project decisions or bounce ideas. You’ll have to rely on the notes taken during the regular project check in meetings. Use tools that help you keep good notes during all meetings, but also integrate with your email. Don’t let decisions and ideas languish in your inbox, make sure they get recorded somewhere other than just your email inbox. Basecamp and Central Desktop will do that for you. If you respond to a thread started with one of these tools, the message will be emailed as well as recorded into the Basecamp or Central Desktop repository. This will allow for easy search and retrieval even in cases of team member turn-over when you no longer have access to their email inboxes.
3. Embrace Agile
As you discuss the project requirements write them up into user stories instead of collecting them into a requirements document. This way the requirements will become actionable items right away. User stories should be detailed enough that they can be further broken down into tasks. They can be easily prioritized, assigned and tracked. Stories that don’t need to be completed right away should go into the backlog. Have 1-2 week long sprints, with daily virtual “stand-ups”.
4. Demo, demo!
Salesforce makes it easy to have a working, demo-able system at any point in time because you are always starting with a working CRM right out of the box. At the end of every sprint set some time aside to demo the user stories you implemented during the sprint to your stakeholders. This will give you and your client confidence in the progress of the project and will provide material for additional user stories to be added to the backlog for future system features.
5. Train the trainer
With a Salesforce project, especially a distributed one, it’s very important to designate a CRM champion. This is typically a Salesforce administrator or coordinator, designated by the client or stakeholder, who is in charge of ensuring the adoption of the Salesforce system in the client’s organization. Make sure the person in this role receives the appropriate level of training to be able to: understand the database system features that were implemented, answer end-user questions and be able to coach end users as they come on board. I recommend that the user documentation and training materials be created jointly with the CRM champion, because in their role they have the most insight into how the organization will respond to the training materials and how the users prefer to be trained on the new database.
by Nineta Martinov