Culture-Driven Complexity

Peter Thomas’s recent comment (here) and his post on developing an international BI strategy (here), reminded me that I had forgotten to post on some interesting dimensions of project and project complexity.  Or at least they’re interesting to me…

This PDF outlines some of the complexity that culture introduces to managing global projects.   It’s nothing revolutionary, but I’ve always liked two aspects of these slides:

  1. One slide outlines the cultural dilemnas well: “How does an India-based SAP project manager talk to a Manhattan-based marketing analyst?”
  2. Another reminds us that we need to remember that we’re individuals, not stereotypes… and yes, I’m the Paul R. on that slide.

Remote Development — Tips for Managing Projects

Bas has an excellent list of tips for managing projects that include remote development teams (here).  The list itself is useful, but I particularly like how he built it.  Bas leveraged the comments from another post (here) to create this meta-tipsheet.  Below are a few of the ideas that we use quite a bit at SAP:

4. If possible, visit your offshore team during the development phase and make an effort to blend in.
5. Identify a leader you are going to be communicating with regularly and make him responsible for all updates and reports so there is no miscommunication.

SAP has an exchange program with our global delivery and global development groups based in remote locations (especially India). Also, we’ve developed a strong, independent PMO in our global delivery organization in SAP Consulting. They’re mature enough to be regular contributors of remote delivery content for our ASAP methodology (overview page here, NOTE: requires registration to service.sap.com).

7. Whichever way you choose for your communication, always support verbal communication with written correspondence.
10. The bigger the better is the rule when getting projects made offshore.

#7 applies to most projects, but never forget it for remote teams.  Tip #10 is very perceptive, as it notes “small projects are usually going to get you distracted workers who will be looking for their next assignment even while they work for you.”  Also, being “stingy” with work by doling it out piecemeal usually only attracts second-tier resources or desperate firms.

Delivering Global Projects

Craig Borysowich’s post on special considerations for international projects (here) IDs some important factors.   Also, I have to like a guy who went for the Modigliani image (see here).  Here is his list and my comments:

Impact of Distance — The extreme distance between “home base” and the customer site can be extremely costly to the project.  Make sure there is enough money in the budget to cover the level of effort that is required to travel and live in the customer environment (including the costs of whatever trips home are to be provided for the members of the project team).

This point gets glossed over when budgeting, it is critical to have co-location early in the project, but some projects try to economize by cutting out early travel, which compromises team and trust building.  An early investment in co-location will also allow remote collaboration techniques — calls, Webex, videocon, etc. — to be more effective.

Make sure that the number of resources required to do the job has been estimated realistically. With projects that are operating out of home base, it may be possible to conduct a site acceptance test, for example, with two people working for two weeks. If anything unexpected were to occur in this scenario, it would be relatively easy to bring in back up personnel.

Our experience is that many projects try to manage globally-delivered projects with the same amount of project management resources.  This strategy ends up being penny-wise and pound-foolish, often to the extreme.  The cost arbitrage for technical and business resources has trade-offs in efficiency (which Craig notes). Continue reading

%d bloggers like this: