Offshoring Discussion at #bpmCamp 2010 @ Stanford

  • April 23, 2010
  • Scott

One of the most anticipated sessions at bpmCamp was a discussion on off-shoring.  It had one of the highest turnouts of day 1. There were some interesting observations from the discussion :

  1. Everyone agreed that daily communication across multiple mediums was a must: phone, email, instant messaging, screen sharing.
  2. Structure helps: Daily SCRUM sessions, for example.
  3. Bringing offshore folks onshore for a while helps – consensus is that this is more important than the reverse, though both are good.
  4. Despite having productive off-site working relationships within the US, several participants reported a drop-off in productivity when going off-shore – despite no obvious logistical/infrastructure difference besides timezone.
  5. Integration and collaboration among the teams is vastly more important than documentation and specifications.  The trend toward increasingly exact specifications to manage off-shore resources mirrors what happened with software development methodology in the US many years ago – with increasing gateways and overhead, and slowing velocity and innovation. (This led to a waterfall backlash, and the popularity of Agile software methods)
  6. There’s a lot of potential in the follow-the-sun model, and in cost-savings.  But the challenges to productivity are real.

My own advice: when off-shoring, work with firms that do BPM deployments locally, for local market customers.  The adjustments they have to make to do a remote-BPM project are less-severe than the adjustments technical staff have to make from traditional IT projects to BPM projects.

Related Posts
  • June 15, 2017
  • Krista

We are excited to announce our first customer speaker for Driven 2017. Quang Ton, leader of Schlumberger's pro...

  • June 12, 2017
  • Scott

We had the pleasure of presenting Brazos CX Insights to the bpmNEXT 2017 conference in April.  As we've previ...

  • June 11, 2017
  • Scott

Anatoly does a great job of explaining the event types and why you really only need 5 or 6 of them to fully ex...