29.2.08

B R I C

B R I C, in case you don't know, is the acronym used by economists, and generally anyone who speaks in acronyms, to describe the cluster of economic similarity in Brazil, Russia, India and China.

The acronym is also used in the outsourcing community to describe the same four major sourcing locales.

I've been digging up some really basic economic data this week, as part of a side project, and something struck me.

Brazil and Russia must have great PR firms.

Here's the breakdown:
  • China is the second largest economy on the planet.
  • India is the third largest economy on the planet.
  • Brazil is eighth.
  • Russia is ninth.
If you look at population, which is a good rough way to correlate how much potential value can be added to an economy through human effort, it breaks down thus:
  • China is first with 20% of the people on the planet.
  • India is second with 17% of all humans.
  • Brazil comes in fifth, an order of magnitude removed, at 3%.
  • Russia brings it home in ninth with 2% of our species.
My point with this is that there is a huge disparity between these economies. To lump them together makes a nice acronym, but aside from being able to say "BRIC" as if it were written "brick", I don't see a lot of correlation. I guess there's an assertion that Russia and Brazil have "also" globalized their economies, but wow, they have a long way to go to catch up with the juggernauts that are India and China.

This graph says it all. One data set is the relative contribution of these countries to worldwide GDP (using IMF PPP analysis from 2007). The other is population contribution to the worldwide total. When you look at it this way, the difference between the "BR" and the "IC" is striking. You could argue even that "BRI" pales in comparison to "C."



Either way you look at it though, Brazil and Russia got a great deal out of this grouping. There may be other attributes to these economies that make them highly correlative, but to the average lay person, this is really a vast misrepresentation. It makes one suspect that a cabal of Brazilian and Russian business interests had a hand in the original grouping.

For anyone interested, the United States ranks first in GDP (behind only the cumulative total of the EU member states), and third in population.

26.2.08

Yoga

I have taken exactly one yoga class in my life. Usually, I would attempt to parlay this modest experience and present myself as an authority on the subject. However, I know a couple of yoginis who would totally bust me if I even claimed I could touch my toes. So, this post must start with the caveat that I know nothing, or next to nothing, about yoga.

That said, I found this link on one of the blogs I read (click on the picture of the pretzel reading the paper):




The article is a brief discussion of the Pondicherry Yoga Festival. Sadly, for anyone planning a Q2 trip to India, this has come and gone for 2008, but the ad campaign for this festival was just amazing (which is why it's gotten attention on so many blogs).

I posted this for three reasons:
  1. It shows some of the creativity coming out of India right now. This is important to note, because many software professionals I speak with still view India as "cheap labor" rather than as a global talent hot spot. I know making TV ads and posters is not the same as making software, but this illustrates a point about the infectious backdrop of creative energy in India.

  2. The posters themselves, while fantastic in nature, do show some of the vibrant color of India. As I look out my window on a cold, lifeless New Hampshire snow-scape, I really do wish I was in India, where it's warm and colorful and vibrant and loud.

  3. If you like yoga, and you happen to work with or manage a team of engineers in India, then there are loads of cool yoga-related things like this you can work into your travels. I know several people who have tacked vacation time on to the ends of their business trips, and have done week-long stays at an ashram like this one, or this one. Not my thing personally, but a great opportunity if you're into finding inner peace.

25.2.08

Politics and Religion

Every "Management 101" course I've ever seen cautions the neomanager against certain topics of discourse. I'm going to go out on a limb and offer, as food for thought, an idea that will make your HR team and your company's lawyer's blow their gaskets.

I think you should talk about politics and religion with your coworkers, especially if you are part of a global team.

The only times I've seen groups of people, remote from each other or collocated, work well together is when they function as a team. I've been thinking of this as the One Team Rule. (unoriginal, I know, but descriptive...)

It's easy to test for adherence to the One Team Rule. If you ask a manager how their offshore engineers do something, and they start the answer with the word "We", then that group of people is a team, and in my experience they are likely to be successful in what ever endeavor they undertake. If the answer starts with the word "They", there is no team, and it is likely that their efforts are in trouble, and are quite possibly doomed to failure.

I've given some thought over the last week or so to how I've achieved that One Team feeling. I'll start by saying that I haven't always achieved it. In some cases, I've come very far from achieving it. But when I have, it's been because somehow, the people on the team stopped perceiving one another as "them", and started perceiving one another as "us."

But how do you make that happen?

For me personally, talking about politics and religion is a great way to get down to that human to human level of discourse that leads to understanding, rapport, and ultimately "teaminess."

When I was in Sri Lanka for the first time, I was a bit overwhelmed by the amount of military presence around the airport and government buildings. I asked some of the people who worked for me why this was necessary, and they sheepishly told me that there had been "some trouble" with the LTTE - the Tamil Tiger rebels. I dug into this further, and got a detailed (though somewhat uncomfortable) telling of the last 20 years Sri Lanka's on-going civil war (or rebellion, or insurrection, depending on who's talking). The team seemed at first awkward, then amazed that I was interested in talking with them about this.

Here's why I defied my training and the advice of lots of allegedly smart people, and had this conversation about the politics of Sri Lanka with my team there: The people in Colombo, who worked for me, lived this rebellion every day, as a backdrop to their lives. When there was an attack in the North, or a suicide bomb in the capital, it impacted them. If something impacts my team, I need to know about it and understand it, for obvious reasons. That conversation went a long way toward helping me understand my team's day-to-day life, and it went a long way toward helping them understand that I was a "normal person" who was interested in their plight and the plight of their country.

We achieved an important first step toward becoming a team by talking about the sticky mess of Tamil separatism in Sri Lanka.

On that same trip, I did the culturally insensitive act of offering to take the team (which consisted of mostly Buddhists, a religion the devout practitioners of which don't drink booze) out for drinks and snacks after a long day of meetings. The team all came out, and a few of the engineers had cocktails while I had a beer or three. While we were standing around in the bar of the Trans Asia Hotel, I asked them about Buddhism in Sri Lanka. These engineers and managers had just spent the whole day telling me how hard the team works, and how eager and hungry the work force is in Colombo. I asked them how that work ethic they had described squares with a philosophy and world view that holds material attachment to be the root of all suffering.

They were more than a little shocked that a software manager from the USA knew something about Buddhism (which doesn't speak well for software managers from the USA, as a class). But after they got over their surprise and reticence, they seemed delighted that I was interested in their lives, their religion, and how they melded the two. We proceeded to have a great, long discussion about Buddhism, the Middle Way, the Eight-Fold Path, and how to live a spiritually enlightened life in a capitalistic, materialistic world. It was a great talk.

When the Sri Lankan engineers figured out that I was interested in Buddhism, and in understanding their culture, they really opened up, and talked with me about stuff I suspect I never would have heard or learned otherwise. We left knowing a bit about each other that would have never come up if I had steered clear of Religion as a topic.

In my own experience, religion and politics are acceptable if not excellent topics of discussion. I'll offer the caveat that you shouldn't be a jerk. But if you can manage that trick, these two topics, like no others, cut through the workaday banalities and really let people expose who they are. And that is crucial if a group of people is ever to become a team.


As a very cool aside, the engineers in Sri Lanka, upon learning my interest in and openness to Buddhism, told me about a place I really want to visit on my next trip to Sri Lanka. It's called "the Temple of the Tooth", and it houses a holy relic believed to be a tooth salvaged from the funeral pyre of Buddha, brought to Sri Lanka in the 4th century. The relic is celebrated annually in the Esala Perahera, or the procession of the tooth. If you like elephants, particularly elephants dressed up like Christmas trees, this is apparently a must-see event!

22.2.08

Useless statistics, and the Pareto principle

I'm sure there's an easier way to get at the number I was after, but this past weekend, I needed some hard data to support my assertion that there is a very large market for a book about working in a global workplace, written for technologists. I was writing a book proposal, and wanted to back up my assertion with a little bit more than "really really lots, I'm certain of it!"

To get at a meaningful number, I worked backwards from the number of people employed on the vendor side of the global IT services business.

I took the Global Services Top-100 list, and did some very tedious pick and ax work to figure out how many employees are represented in this top 20% or so of the global IT service business. I went to each of 100 web sites, and poked around until I found a company "fact sheet" or some similar reference that reported how many employees the company has.

The good news is that 60% of the companies in my survey openly discussed their size, in what would seem to be the most relevant measurement of service delivery capacity -- the number of people who work in the company.

That means 40% of the companies attempted to obscure the size of their company. They either didn't talk about it, or blatantly obfuscated the facts about themselves. That's understandable. If you're the little guy, competing against TCS or Wipro, you may not want people to know that you only have 40 engineers. I'd argue that hiding the information is useless, but what ever... It's their company...

But some of the companies did something that's just bizarre, that I think is a great follow up to the post about Moneyball, and the way pro-baseball measures the wrong stuff.

Lots of those 40 companies that didn't like to talk about how many employees they had did like to talk about how big their company is, they just did it in very literal terms.

That is, over and over on these company's web sites, I saw references to how big the company was. In square feet. Of surface area.

Now, I really can't imagine a less useful fact to know about a company.

Square feet per employee might tell you something about how well the company treats its employees. But square feet of floor space just says, well, nothing. It's just useless information.

And I saw it over and over again.

I guess the cautionary tale is to be careful when sales people and marketeers give you impressive sounding stats like "we have over 200,000 Osminas of capacity in our Moscow facility". Think about what you want to know, ask for that data, and be very suspicious if you don't get a quick, direct answer... In units that make sense to you.

By the way, the results of my research were interesting. 60 of the top 100 companies in the Global Services top-100 list have, all in, 1,247,010 employees.

The top-12 companies (in terms of headcount) on that list of 60 employ 937,700 people.

The Pareto principle would predict that that the top 20% of companies in my list of 60 would employ 997,608 employees. That's a remarkably close proof of the principle.

Book reviews for people who hate business books

Really, what could possibly be more boring than a book about statistics?

Oh, wait, I know... a book about baseball!

So how is it that a book about both statistics and baseball -- Moneyball, by Michael Lewis -- is so damn good?

Part of it is that Michael Lewis is a great writer. Part of it is that he isn't writing about either statistics or baseball in any way that you'd expect. What he is writing about is the intersection between the game of baseball and the science of statistical analysis.

I've written a bunch of stuff through the years about statistical analysis in the software industry. I've invented models that I thought got at relevant, predictive correlations you could derive from data about software projects. And I've cautioned against metric programs that might create unintended behavior in your software teams.

But most of what I've written was as boring as you could possibly imagine. And because it was boring, no one read it, and it didn't make any impact on the problem I was trying to fix.

From now on, when I want to get a point across about statistical analysis and the power it can bring to any human endeavor, I'm going to point people at Moneyball.

Without ruining the book for anyone, I'll summarize: Baseball is a game of numbers, but historically, people have looked at the wrong numbers. They look at and track errors and batting average, but there are other stats that are much more highly correlated with actually scoring a run. The book analyzes how this science of sabermetrics became a powerful tool in the management style of one particular baseball team. It then goes on to discuss how that team was able to equalize a five to one deficit in the amount of money they were able to spend on player salary, and compete against the richest teams in pro baseball.

It's a great book, and it's highly relevant to business and engineering, without being about business or engineering. I like that. Pick it up and read a copy!

One interesting tie-in to global teams -- Obviously, people in India (and most of the rest of the world) didn't grow up with the omnipresent backdrop of baseball. They may not get baseball references in speech, so when you tell them they "hit a home run", they may or may not know what you mean.

This might be a good book to share with people on the "global" part of your team, both to catalyze thought about statistics, and to help your people grok baseball a little more, if they care to.

12.2.08

Free, and worth every penny!

In a recent correspondence with one of the three or so people who regularly read my blog, I received a long and well ordered list of even more free / open-source software tools.

Since starting my own business a few short weeks ago, one of the the things I've been thinking about (well, really obsessing about) is how to acquire world-class tools while expending as little as possible of my precious capital. I think that's a worthy goal for anyone, so I'll post this list, with the editorial caveat that while I use a lot of these tools myself, I haven't done anything here but copy-paste the text of a message from my good friend Doug.

As always, YMMV.



In your search for free and/or open source alternatives to commercial software here are some recommendations I use on my system(s). I've included the name, category (what they do), and URL. Some may be for personal use only and not for distribution to entire organizations, but worth checking out if you were equipping a new team and trying to minimize cost (or just supporting independent development and/or the open source movement).

Name: Mozilla Firefox
Category: Browser
http://www.mozilla.com

Name:7-Zip
Category: Zip/Rar/Etc. Utility
http://www.7-zip.org/

Name: FileZilla Client
Category: FTP Client
http://filezilla-project.org/

Name: FileZilla Server
Category: FTP Server
http://filezilla-project.org/

Name: Notepad++
Category: Editor (html, C#, PHP, etc.)
http://notepad-plus.sourceforge.net/uk/site.htm

Name: KeePass Password Safe
Category: Secure password program
http://keepass.info/

Name: Jalbum Web
Category: Photo Album Software
http://jalbum.net/

Name: Flash Renamer
Category: Batch File Rename Utility (Exif, MP3)
http://www.rlvision.com/flashren/about.asp

Name: VLC Media Player
Category: DVD, video/audio player
http://www.videolan.org/vlc/

Name: dd-wrt
Category: Open source linux OS for Linksys routers
http://www.dd-wrt.com/dd-wrtv3/index.php

Name: Daemon Tools
Category: Virtual drive software (ISO, IMG, etc.)
http://www.daemon-tools.cc/dtcc/announcements.php

Name: AVG Anti-Virus
Category: Anti virus software
http://free.grisoft.com/

Name: Comodo Personal Firewall
Category: Personal firewall
http://www.comodo.com/

Name: Google Picasa Photo Editor
Category: Photo editing and organization
http://picasa.google.com/

Name: Belarc
Category: System Inventory/Auditor
http://www.belarc.com/free_download.html

Name: CDBurnerXP
Category: CD/DVD Burning Software
http://cdburnerxp.se/

Name: InfraRecorder
Category: CD/DVD Burning Software
http://infrarecorder.sourceforge.net/

Name: eXpert PDF Reader/Editor
Category: PDC reader and editor
http://www.visagesoft.com/products/pdfreader/

Here's a dollar. Go buy yourself a clue.

I've frequently talked and often thought about how I like to work with people who, to use my own vernacular, "intellectualize their jobs." What I have meant by this is summed up nicely in this fairly old essay by Eric Sink.

Here's an excerpt:

"We want learning to be a process, not an event. Making your first derivative constantly positive is not just about formal training. It is a posture which you bring to your job each day. It is a posture of teachability, a constant willingness to learn."


Check it out. The whole site is actually worth a read...

(via Eric Sink's Weblog)

11.2.08

Ooh... Shiny!

In my experience, one of the great and largely invisible forces of the business world is Shiny Object Syndrome. I don't think you'll find it in the DSM-IV but it's still a debilitating mental disorder, or at least a frailty.

In Shiny Object Syndrome, you get distracted from your work by something bright and shiny that you see out of the corner of your e --- hey, what's that driving by outside? Is that the new Prius? They look pretty cool now. Much less clunky. I wonder what kind of mileage those get now. I'll just go on-line to the Toyota site and see... (Many hours pass while I configure my dream-Prius, and weigh the pros and cons against the Mini Clubman that I really want...)

That, in a nutshell, is Shiny Object Syndrome.

As applied to software development, most engineers will say that Shiny Object Syndrome describes the scenario wherein Marketing demands new but useless features that look good in a trade-show booth. But there's a more insidious and dangerous side to Shiny Object Syndrome, and it applies directly to managing remote or offshore teams.

Shiny Object Syndrome, as applied to outsourcing:

I'll sum it up thus:

"We used to like our outsourcing partner, but lately they suck. Let's go get a new partner."

I've personally seen this play out enough times, and I've heard it described by others enough times, to suspect that this flavor of SOS is a crippling business problem.

You might have a lot of reasons to believe that your existing partner sucks. For example, from my own experience:
  • Maybe your partner "pitches" new work to you too frequently.
  • Maybe your partner hires junior engineers who don't have enough experience to work on your complex projects.
  • Maybe your partner has high attrition.
  • Maybe your partner's rates are too high.
  • Maybe the deliverables from your partner team are of low quality.
Each of these are real problems. But let's talk briefly about these problems, and the various ways you could fix them:
  • Too much sales pitch
    • Shiny Object solution: Let's get a new partner, and a new sales team, and maybe they won't give us the hard sell. Likelihood of success: Mixed. Basically luck of the draw. Maybe you'll get an aggressive partner and sales team next time around, maybe you won't.
    • Boring hard-work solution: Let's have the hard conversation, confront the person or people in question, and articulate the fact that this behavior is unacceptable and is jeopardizing the partnership. Likelihood of success: Pretty high. This plays to human nature and financial incentive. Tell people what needs to be fixed for them to continue enjoying your business, and they'll try really hard to fix it.
  • Engineers too junior
    • Shiny Object solution: Let's get a new partner, some place where engineers are more senior. I've heard engineers in Russia are more senior. Let's go there! Likelihood of success: Mixed. Basically luck of the draw. There is variance in average experience level across teams, companies and locales. Maybe you'll get lucky and end up with a senior team. Maybe you won't.
    • Boring hard-work solution: Let's have the hard conversation, confront the partner, and articulate our requirements for seniority, in clear, concise language, devoid of vernacular. Or better yet, let's interview everyone the partner hires to make sure that they meet our expectations and that we want them on our team. Likelihood of success: Pretty high. If we're picking who gets to be on our team, chances are we can get it right and help our partner hire to our expectations.
  • High attrition
    • Shiny Object solution: Let's get a new partner, some place where the market isn't so hot, and maybe people will stick around a bit longer. Likelihood of success: Low. In my experience, this is likely to backfire. Even in India, where the market for software development talent is white-hot, good people don't leave for more money. They leave because they're poorly managed, treated like dirt, and asked to do boring repetitive work that doesn't challenge them or improve their skills. The Shiny Object solution here may get you a team of engineers that stays with you longer, but do you really want people to stay on your team because they can't get a job anywhere else?
    • Boring hard-work solution: Let's treat our contract teams like part of OUR team. Let's have all-hands meetings and tell them what we're working on next month, and why. Let's recognize their work and achievements. Let's give them some pats on the back. Let's tell them what we expect, and hold them accountable to that. Let's make the offshore center a nice place to work, and let's invest in the team, just as if it were a team of our own employees... Likelihood of success: Pretty high. In teams that I had a direct hand in managing, in India, during the height of the recent tech bubble, I've had very low attrition - lower in fact than my US-based team. If you treat people well, give them relevant, visible work, and let them know what's expected of them, they'll generally like working for you, and they'll stick around.
  • Too expensive
    • Shiny Object solution: Let's get a new partner, some place on the planet that's cheaper, and let's do a better job on the contract. Likelihood of success: Pretty high. For a little while. One of the rules of supply-and-demand is that cheap labor will almost always draw global interest, and salary will almost always go up. So what ever competitive advantage you get in a new locale will be short-lived. But when you sit down to negotiate a contract, you get to decide what you'll pay. So you can make this one come out to your advantage when you set up a new partnership.
    • Boring hard-work solution: Let's have the hard conversation, decide what "good rates" are, confront the partner, and get the rates we want, even if it means getting the lawyers involved and voiding the existing contract. Likelihood of success: Pretty high. If you're on the buy-side of a partnership, you always have all the power. You always get to decide if the services you're paying for meet your expectations. And you always get to decide if it's time to re-do a contract. Your partner will tell you otherwise, because it's in their financial best interest to do so, but remember, you write the checks every month. It's tough to make yourself use this power, particularly if you're a software manager and not a business person, but you can do it. Or you can get one of your salespeople to come in and help...
  • Low quality
    • Shiny Object solution: Let's get a new partner, with a better process, smarter engineers, and more commitment to quality. Likelihood of success: Mixed. Generally, people try to do good work. If your last team produced low quality, and you don't change anything but the people, you're back to luck of the draw. Maybe you get exceptional people who can overcome what ever obstacles tripped the last team, maybe not.
    • Boring hard-work solution: Let's figure out why the quality is low. Do the engineers on our team not care about their work product? Then let's put them on notice about our expectations, and let them know their jobs hang in the balance. What? We haven't written down our quality expectations, or made them analytic and objective in any way? Well... let's try that first. Likelihood of success: Mixed. If there were a universally applicable quick fix for high quality, for starters I wouldn't have had a job for the last 8 years. This is tough to get right, but those who have gotten it right have sharpened their pencils, figured out what levels of quality they wanted, how they would measure that quality, and how they would test for it. Then they held their teams accountable to that standard. Without that hard work, quality is just a matter of luck. Which is a poor plan.
In all of these very real scenarios, the problem you're facing might initially drive you to look for a new partner, with the hope or promise that the new partner will fix all your problems for you.

In my experience, it just doesn't work that way. What does help is a little institutional Ritalin - take your meds and focus...

In each of the scenarios above, the focussed, hard-work answer is at least as effective as the shiny object answer. In most cases, the focussed hard-work approach is better.

Human nature wants a quick fix. But a much more solid approach to troublesome business issues is to focus in great detail, with analytic rigor, on the problems at hand, and not to be seduced by something that promises to solve them all your problems in one fell swoop.

If you go for the shiny object solution with respect to your sourcing partnership, what will likely happen is that you'll replicate your old problems, in a new locale, with a new partner.

It's better to do the difficult thing, and to look for root causes -- Why does our partner hire people too junior to meet our expectations? Why do we produce low quality with our partner team? Be analytic about the root cause of your problems, and solve those problems. Don't be naive about the prospect of simply chasing shiny objects until your problems go away.

Now that we've laid out this simple advice, we can move on to... Hey! It's stopped raining. Let's go ride bikes...

7.2.08

More free software...

While I'm thinking about free software (see yesterday's post), I've recently started using a piece of software called "Sandy". It's good enough that I'd like to give it a plug.

Sandy is an on-line personal assistant robot. Inspired by the LifeHacks movement, "Sandy" is a program that keeps track of your calendar, your post-it notes, your to do list and what ever other information you care to load it with. I've been using Sandy for a couple of months now, and I'm totally sold. You feed Sandy information via e-mail, with some simple, intuitive encoding. You tell Sandy about your day, your lunch meeting next week, that guy's phone number, your mom's birthday... Sandy captures it, remembers it, and sends you daily digests and reminders, to your e-mail or to your mobile.

Sandy is made by a company called Values of n, inc. Rather than butchering their description, I'll just point you to the I Want Sandy web page and you can read for yourself.

6.2.08

Captain Spreadsheet

For years now, ever since I took Edward Tufte's very excellent one-day course on the graphic presentation of quantitative information, I've been a bit obsessed with presenting data in a way that tells a story. This has meant that everyone who has worked with me has had to endure reams of reports, dashboards, and burn-down charts replete with both shapes and colors.

Amongst my closest friends, this obsession has earned me the nick-name "Captain Spreadsheet".

I'm sure they mean it in the nicest way.

To them I say: Today, Captain Spreadsheet tried on a new cape. He quite likes it.

That new cape is StarOffice Calc.

I recently set up a new computer, and opted not to give Microsoft the $300 to $400 it costs to purchase a legally licensed instance of their nearly omni-present MS Office productivity suite.

Instead, I downloaded and installed some free software from Google. Their "pack" essential software suite includes an awesome array of tools, including:
  • Google Earth
  • Google Desktop Search
  • Firefox (the best browser currently on the planet, now that Netscape is no more...)
  • Adobe Reader
  • Real Player
  • Picasa2
  • and most notably, StarOffice 8
It is Star Office 8 that I tried on for size this week. It includes a text editor (StarOffice Writer), a database (StarOffice Base), a drawing program (StarOffice Draw), a presentation tool (StarOffice Impress), and a spreadsheet (StarOffice Calc).

The installation couldn't have been easier. The tools work as expected. And the cost couldn't have been, well, couldn't have been anything -- because there was no cost.

Thus far, Captain Spreadsheet approves.

But does it work? Can it replace the time-honored slot that Excel has earned in Captain Spreadsheet's utility belt?

As you can see, I'm able to create both shapes and colors, so I am fundamentally satisfied.

My initial impression was that Calc is so like Excel as to be virtually indistinguishable. After using it for a couple of days to create a month-end budget report, I've found a few weird things that are different enough to make me suspect that Microsoft has blocking patents on certain combinations of key-strokes. But I got around each of those weird differences with only cursory inspection of the Calc help system. I've been able to figure out how to do everything I wanted to do with Calc. The only negative I've found is that in some cases, Calc falls into the same trap as Excel, with its million-little-features cruftiness that makes me yearn for CricketGraph. But it's good solid software. And it can open .xls files created by Excel. And it's free.

If I were outfitting a team of engineers right now, no matter where they were on the planet, I believe I'd take a pass on the Microsoft productivity suite, and ask my team to use StarOffice. Let's say, hypothetically, you have a team of 100 engineers. Even with corporate discounts from Microsoft, using StarOffice could save you $15,000 in software license costs.

4.2.08

Doomsday, the board game

At various points in my career, I've done this exercise - sometimes alone sometimes with peers or with my staff.

I've come to refer to as the Doomsday Game.

You can play along at home... It works like this:

You get together at a white board, and you list out all the things that are important to you. You can do this at any level of granularity, so it might be about a feature or a module, a product release or a project, a contract you're setting up, or an entire branch of your business. Just write down the things you care about. It's a brainstorming exercise, so there are no wrong answers.

When you get a list, stack-rank it. Line up the most important all the way down to the most trivial.

For each of those things you care about, brainstorm about what could impact, damage, impugn, destroy, or otherwise muck up that thing.

That is to say, think of Doomsday Scenarios.

This is really just a chance to let your paranoid nature come to the forefront, and to get creative about what might make a mess of your world.

Put differently -- what keeps you up at night? If the phone rings (or your pager goes off, or the little red light on the blackberry lites up) at midnight, what would it be about...

Articulate that fear or anxiety, and put it on the list.

When you've exhausted your paranoid creativity, go to the next item on list. Lather, rinse, repeat.

If done well, after a couple of hours you've got a solid list of risks or potential risks that represents the previously unarticulated fears of you and your organization.

The last step in this exercise is to "test" your organization's resilience by seeing if there are already abatement measures, mitigation strategies or controls in place that in some way obviate the risks you listed out. If there aren't already measures in place, get them in place.

This might become more clear with a few examples...

Let's say you care about this list, in stack rank:
  1. Schedule Adherence
  2. Code Quality
  3. Data Privacy
For any project, there are likely to be many more things on the list, but for the sake of example, I'll develop these three.

Schedule Adherence could be impacted by:
  • Feature creep and poorly understood requirements - we'll build the wrong thing and have a lot of re-work
  • Connectivity loss - the half of the team in India lost the link to the repository and can't do check-ins
  • Vacation - The Diwali festival comes right in the middle of the first integration sprint
  • Attrition - The team in India loses people every other week
  • Slow computers - compile and link takes forever - we lose days on test builds alone
Code quality could be impacted by:
  • Bad code - those engineers in India don't follow our coding standards
  • Poorly understood internal requirements - the new engineers on the team don't know what they don't know about the product's modules and sub-systems
  • No trusted code -- nobody writes unit tests
Data privacy could be impacted by:
  • Inadvertent disclosure - test data might have social security numbers in it, and it might be seen by the wrong person
  • Theft - some bad guys might get into production data and just steal it
  • Trap doors - some bad guys might code in a trap door that steals data later
Now that you have a list of what could happen (hopefully your list will be longer and more creative), you can test your organization. Hypothetically, here's how you might stack up:
  • Schedule Risk due to Feature Creep: We have no way to isolate against this. It's the "nature of the beast".
    • Okay, so you just figured out something -- you think that this risk is going to impact your schedule and you have no way to control it. You have to do something here.
    • The only thing we can do is to validate our planned features with our customers, and document and socialize exactly what we're building.
    • Well, it sounds like you've started to develop a mitigation strategy. Assign it to a few people and have them come back in a couple of days with a full mitigation plan for this one.
  • Schedule slip due to connectivity loss: If the link between here and India goes down for more than an hour, we're hosed. We have to post the builds every night, they have to do check-ins. Without 4 MBpS, we're dead in the water.
    • Sounds like you've identified a pretty significant risk. What could you do about it?
    • We could implement a build farm in the lab in Bangalore, and let the team there do check-ins against a local repository. It would be tough, but it would mitigate the connectivity risk.
    • Or we could pay for redundant links, so if one provider drops a circuit we'd have a fall back.
    • Starting to see how this works? In this case, you have some work to do here to get a plan in place in advance of a network outage. Who ever draws the straw to develop this one should consider the cost of the solution compared to the likelihood of the event... Maybe it's enough to have a redundant link at a very low bandwidth, but which can be "turned up" on demand...
  • Schedule slip due to vacation:
    • We're covered here. Everyone knows their vacation plans for the next two quarters. We keep that information in a data file that Microsoft Project uses to track resource allocation. The only way we could get hosed here is if someone took an unexpected leave. That "death in the family" risk is the same across all our projects, so we're not really going to do anything about it yet.
    • It sounds like you're covered here, and while this is a real risk, you don't judge it to be significant enough to warrant action.
  • Schedule slip due to attrition
    • This one's tough. We keep losing our good people in India. We lost 2 last month, and some people are making noise about leaving this month. The only thing we can do is get better at on-boarding people. We've developed a training program that will bring someone up to speed on the basics in 2 weeks.
    • Also, if we lose too many people on the team in India, we can bring in short term "hired guns" here in the 'States, for the final few months of the project.
    • What about trying to make people want to stay?
    • Yeah, we don't do anything about that now. Maybe we should have all-hands, and buy the team in India dinner every night, like we do for ourselves...
    • Very quickly you've identified three actions -- training programs for easy on-boarding, contingency program for on-shore contractors, and a "hearts and minds" campaign to make people want to stay on your team. I think you're getting the hang of the game. Put this stuff into action and this risk gets less risky.
  • Schedule slip due to slow computers
    • It just takes too long to compile on our old P-3s, and the team in India has even crappier hardware.
    • Let's write a business case and take it to the CFO, to justify getting some big iron for all the developers. We should be able to make this problem go away by throwing some capital at it.
    • You're definitely getting the hang of it.
In the interest of brevity, I won't develop the hypothetical arguments and mitigations any further. But if you have an active imagination, and you're willing to spend some time letting yourself get paranoid, you can easily spot holes in your plans, see risks before they hit you, and put measures in place that will help insulate you.

It's a fun game, and can be a great team-building and perspective expanding exercise. And it ends up being an interesting way to approach work, and life in general. If you make this part of your approach to business, you'll find yourself doing it several times a year, maybe even more frequently, as your business or project evolves and your perception of risk changes...

If you got really creative, you could run a book and handicap the risks. I would never advocate gambling, but it would be an interesting and fun way to fund the release party...