Global Software Development — Modeling Your Transition

Another chapter in the thread I started a while back….
transition modelling

As you start to enter into the process of moving work to new locations, there’s plenty to consider. I’ve found that its helpful to build out a model of the transition that provides a general sense of direction to set expectations and hopefully allow you to align resources with the desired path. But, as this post indicates, sometimes you can overthink things. Be prepared for reality to be different from your plan. Some of the advice in the referenced article is particularly sound: “All creative people arrive at greatness by the same system: trial and error. Prototype and test. Just like the kindergartners.” You will probably skin your knees from time to time. Plan on getting up and persevering. This is not a simple process, you probably have a lot of people involved, so the opportunities for mis-steps abound.

So, while I’d recommend that you pull together a plan, don’t kill yourself, things will almost always change. As much as you’d like, the chances of your transition resembling a great symphony are probably somewhere between slim and none. That said, you will want to get a good idea of how much the transitions will cost, how quickly you can get the teams up to the desired speed and the amount of disruption that the changes could introduce into your process. On top of all of these warnings, its vitally important to set and monitor interim goals. (I’m a big advocate of agile/lean processes — this is another opportunity to stay nimble). As you work your way through the transitions, set and track goals. These help the team focus on actionable, real objectives.

There are several major aspects to your model. My preference is to build out an initial set of assumptions, and then develop metrics that can be used to describe how you expect your progress to look at. My favorites were cost and relative productivity. These helped us describe the project in material, return on investment language. When assessing the project from a broad perspective (as executives do and should do), these abstractions are very helpful.

Some things to contemplate when building your model include

  • Expertise already on hand and available. You’ll need to tap these folks both to keep the current work moving forward, and very likely to help recruit, mentor, and counsel the new teams as they come up to speed.
  • The skill sets and corresponding levels of seniority of the people you’re adding. This will drive two factors: cost, and acquisition time.
  • The amount of time and energy required to find the people you want to add to the team. You can characterize this in terms of reduced capacity among your current team members.
  • The speed at which you can locate, sell, recruit, and get the new people to join your team. When coming up with this, its best to find actuals that offer a reasonable comparison to your recruitment activities. While recruiting, you need to understand the full pipeline, much like any other sales and marketing activity. You’ll need to build a pipeline, select good candidates, negotiate with them, and for those selected, wait for them to be on-board. Its also a good idea to think a little bit about fall out that can occur when recruiting any significant number of people. Some may accept and not show up. And some may show up and one or both of you learn that its a bad fit.
  • The rate at which the new team members become productive. It almost all cases, they are going to have to learn some new concepts, and if you are asking them to pick up a complex product or industry, that time can grow. Be realistic, this data will help you understand what the new team may be capable of going forward.

Once you’ve collected this information and built it out in some time sequence (I liked to capture that info on a month over month basis), you can build curves that show your spend and delivery rates. With that, you can have a meaningful conversation with your stakeholders, look at alternatives (in some cases, additional funding can help, in others, you may just be wasting money). I’ve seen too many cases of cost side accounting killing the goose (your revenue stream). Unhappy customers are expensive. Former customers even moreso.


About Mike Rodbell

I'm a technology leader, engaged in developing software for the telecom, online commerce, and business process/analysis markets. All of the teams I've worked with have had a great deal in common. They need to be good at what they do, listen, share, and collaborate towards a shared set of goals. This blog is dedicated to those activities. I hope you enjoy reading it.
This entry was posted in Distributed Teams, management and tagged , , , , . Bookmark the permalink.

2 Responses to Global Software Development — Modeling Your Transition

  1. Pingback: Global Software Development Processes/Approaches | Mike Rodbell's Blog

  2. Pingback: Global Software Development – Identifying New Team Structure and Onboarding Strategy | Mike Rodbell's Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s