Software Configuration Management

Requirement 2: Business Interests Must be Aligned

There’s an old saying about the game of poker: if you look around the table and can’t figure out who’s the fish, it’s you.

Let’s face it: they’re doing it for the money. Just like you. But you’d better understand how they make money in the business relationship or you’re going to feel like you’re the only one not making out.

There are lots of companies that reward late projects and punish early ones. Not intentionally, of course. Maybe you know can recognize who this is:

When projects were late they would respond by creating special incentives, adding people to the project, and increasing the project visibility. When the project was doing well, they’d pull people off to fight other fires, take the best people away from the project leader to work on other projects, and management would stop attending the project review meetings.

Next project comes along, and the offshore project leader comes in with an optimistic schedule. You do the math.

Hey, if you’re reading this blog, you’re a smart person. You know you’re not going to change their culture, so maybe you should spend some time to learn to deal with it. Sure, people are people, and application developers in Moscow, in my experience, have more in common with application developers in New York than they do with factory workers in Minsk, but when people get in groups their behavior changes. That “group dynamic” differs depending on their cultural background.

In the US and northern Europe, senior application developers can follow a technical career ladder and get increasing career respect and satisfaction from being architects and CTOs. At least that’s the theory. In much of Asia, career status is all based on the number of people that report to you in the hierarchy. It’s an up-or-out philosophy that makes it hard for an Indian engineer to explain to his mother why after five years with the company he’s still not a manager.

When working with an outsourcing company, if you don’t figure out their model and how they get paid, it’s like playing poker blindfolded. Many companies build a model based on rotating junior people through their company on standard projects. If you need junior engineers to implement an e-commerce Web site, it’s probably something they will do many times and can do with the talent on hand. If you need people to figure out how to do something unique, your outsourcer might have all the brains in the world, but it just isn’t going to make business sense for them to put their technical leads on the project, when they could be running other e-commerce Web site apps. It makes as much sense as buying a French car or a German perfume.

One of the hardest problems in assessing professional job productivity is identifying the impact of quality. If the reward system is around requirements trace-ability and meeting schedules, quality is going to suffer. If you try to make quality a hurdle to be overcome, you’re going to spend such a long time in requirements specification you are never going to get a payback from offshoring the application development.

There are two things smart companies do to deal with this alignment dilemma:

1. Short iterations, e.g. a two-week Agile process
2. Remember Requirement #1, and bring the remote team lead back to corporate frequently to maximize alignment with the leader.

In Part 3, Don’t Annoy the Pig.