QuoteOriginally posted by: kc11415QuoteOriginally posted by: CuchulainnQuote*) what tends to be less problematic is if the geographically remote team can handle a discrete standalone functionally related set of tasks almost like a black box with a VERY well defined interface to the rest of the firm. This is a HUGE assumption and hardly ever works out in practice from what I see.From a s/w perspective, many/most developers are programmers and have not yet understood/learned/used how to define black box specifications and then program them. They tend to work bottom-up. Unless there is an architect/chief designer. Another point: how good is your documentation??? So, who will find and document the interfaces?I agree perhaps 80%. The problems you cite do occur more often than not, but in a few cases I've seen people mostly overcome such problems.Perhaps I should have qualified my comments that if it is going to work then the factors I mentioned are necessary for success, but do not guarantee success. To have more chance of success, a firm must be absolutely paperless. This is an ideal which is often strived for, yet rarely achieved. I have seen it achieved in one firm, but even in that case, it did not always guarantee success of remoted work.It's always very interesting to determine the factors that influence the success of a project. And indeed document-driven (sometimes cupboards of them!) projects would tend to suggest that something is not quite right. First, by the time these docs have been written the requirements have changed anyway and second the developers may not read them.I think continuity is important to build a common culture and vocabulary. Once you get people speaking the same language as it were the chances of success increase. And the odd Kwok does not harm.For me, alarm bells go off when the developers say they will create a 'generic framework in one year'. Then I wonder if they have a precedent for saying this I like these things in projects:1. Spiral project model, risk analysis (beta distribution) of product features2. Get it working; early results and proof-of-concept asap3. Get it right when step 2. is OK4. A critical architectural drawing of the full system5. Top 5 most pressing features (showstoppers if not implemented)...Can't say that I like Scrum and so on...

glad your back beachcomber