Risk Factors for Offshore-Outsourced Development Projects

The June 2008 CACM contains the article “A Risk Profile of Offshore-Outsourced Development Projects

Since this is a common profile, I thought I’d reproduce the Top 10 Risks. Some of these are universal across all project profiles (“Lack of top management commitment”), but others are definitely more problematic for offshored projects. I’ve highlighted those I think are notably different. All of these should be addressed in your project planning…

  1. Lack of top management commitment
  2. Original set of requirements is miscommunicated
  3. Language barriers in project communication
  4. Inadequate user involvement
  5. Lack of offshore project management know-how by client
  6. Failure to manage end-user expectations
  7. Poor change controls
  8. Lack of business known-how by offshore teams
  9. Lack of required technical know-how by offshore team
  10. Failure to consider all costs

That’s not to say that I think the ones I did not highlight are unimportant, it’s just that I think you can run into those issues onshore (if you replace “language barriers” with “poor communication skills”).

Inadequate user involvement and poor change controls are, I think, more acute risks with offshore-outsourced projects because there’s a certain amount of “out of site, out of mind” to these projects. It’s not like people are hearing programmers talk around the watercooler or at lunch; offshore projects have a greater risk of ‘going dark’ for long periods of time. Similarly, with different working hours, different holiday schedules, etc., I think it’s considerably more common for offshore work to get off the change-control rails. You really need to do daily check-ins with offshore teams, just like you do with local teams. It’s harder and slower than a standup meeting, but I think it’s definitely a necessary part of the daily routine.

Throwing over Flash for Silverlight…Wise?

I have a client who needs a Web-page component that does some photo compositing. Nothing super-fancy, but it needs to be professional, obey some business rules, and do some things dynamically based on static data.

The prototype is in Flash, but is filled with hideous programming — magic numbers, a big monolithic function, etc. Today, the client said that they would be willing to accept the installed-base problem of Silverlight if I recommended it.

Well… It seems to me: Flash’s programming story remains, if not terrible, nothing to write home about. Silverlight’s programming story is pretty stellar — a vast programming base from which I can draw the people to do the business rules and dynamic stuff (i.e., the programming). Flash may be beloved by designers, but for photo-compositing, I don’t see a great advantage over WPF / Silverlight.

Am I wrong?

One way or the other, if you’re a great Flash programmer or have some experience in Silverlight, I’m hiring… Drop me a line direct at lobrien -at- knowing -dot- net.

Update: “Not fair to compare poorly written Flash to green-field Silverlight” was one comment, but I am not comparing the code, I am comparing the code-creation possibilities (and, to some extent, the ecosystem. I think I want people who see the task as programming, not people who see the task as a design issue). “Try Flex,” came a message from Adobe, which is certainly fair — we have a prototype in Flash, Flex has a better programming story than Flash-the-development-environment, Flash is universal. Still looking for developers, but now I’ll throw “Flex developers” into the mix as well…

Some Aspects of the Midori Story from SD Times

The Midori coverage from SD Times has gone mainstream, even making the front page of BBC World News this morning. Since I reviewed the technical portions of the documents for the story, I thought I might clarify some things. First, though:

  • I have no idea who wrote the document
  • I have no idea how SD Times came into possession of the document
  • I have no idea when the document was written

For all I know, what I reviewed might have been the musings of some 14-year-old in Novosobirsk. A very technical 14-year-old, but who knows?

Substantively, what I can say is that the documents were quite technical and were quite provocative — they weren’t a retrospective on Singularity that we conflated into a discussion of a future OS. The technicality of the documents actually gave me some pause: the unguarded tone and technical depth made me think “this is a long way from being a press release.”

Taking the documents at face value, they laid out a very aggressive, very ambitious, scenario for Midori. By “aggressive” and “ambitious,” what I mean is that the author really grabs the bull by the horns and addresses concurrency and legacy head-on. Although there’s a lot of talk in the analysis about “how is this going to work with legacy Windows” what’s interesting to me, personally, is that the technical path being discussed is not a mealy-mouthed “we have to acknowledge the concurrent era” but rather is a full-throated “we have to reinvent what we talk about when we talk about OS.”

What I read was the type of stance that some people don’t think happens at Microsoft. I was impressed. (“It’s all about concurrency”: Larry is impressed. What a surprise.) Was it a deliberately leaked trial balloon? I dunno’.

Cobbler’s Children

I am aware of the irony that I talk a lot about software quality and the infrastructure of this blog is… well, I think it’s up more often than Twitter! …

But, yes, I’m aware. The cobbler’s children go barefoot, and all that…