The Plan

The initial plan was to train the liaison within my department, as there was an immediate need for assistance. After, he would be cycle through the teams of my peers, to have him learn about each of their departments. The liaison was to learn about the environment, gather documentation, and set up an environment offshore for development. As demand increased, we would slowly grow a team offshore. My focus was to start them off slow, as content managers, support staff, and graphic designers. As experience grew, we would spread the offshore team into other, more complex areas of development, such as new development and project management.

Step One – Training and Environment

My team has always been ahead of the game in terms of documentation. We use a shared platform across all of our sites, so the structure of our projects are all similar. Each of the services and the methods are documented with code samples on their usage. We use a project template to jump-start project development, with documentation on the functionality of each of the DLLs, aspx pages, and ashx handlers. We also have templates for project estimation, requirements documentation, and system testing. We have a checklist to guide the developer through the project process. All of our code is stored in VSS, all of our DDL and DML SQL is stored with the solution, and all the documentation is stored in our Documentum instance. Promotes are handled throught CruiseControl for .Net code, and SQL Navigator for the SQL code. All pur projects are initiated through a centralized PMO, and our Client Facing team are the overall project managers. Providing all of this information about our code and our process was the easiest part of the transition.

Getting the offshore team a working environment was not as easy. All of our servers are in the United States, behind our firewall. Working with our security team, VPN access was ruled out as too risly to provide without a more diligent legal contract. This left few options. The one that was chosen was a web based Citrix solution. Tools such as Visual Studio, VSS, and SQL Navigator, were provided to the development, test, and production environment through the Citrix Business Partner site. Some other tools were provided directly to the offshore team, such as local copies of Visual Studio and a local version of our database.

Step Two – Content

Some of the first tasks assigned to the offshore were to help manage content for new projects. I figured that this was a simple set of tasks that would expose the outsourced developers to our development environment. An offshore developer was added to a new project, paired up with an existing onshore developer, and work was divided. Each new page has to be registered in the database, and assigned to the proper application, with all the right properties and URL rewriting information. Our page content comes from advertising agencies in the form of HTML. We take that HTML, slice it into reusable blocks and unique blocks, and insert them into our custom content management database. Each of the pages then has to be associated to each of the content blocks. All of this data is inserted into the database via Data Manipulation (DML) SQL scripts. Once inserted, the pages need to be tested with the solution. These activities were the responsibility of the offshore team members.

Step Three – Support

A significant part of our development activity is support. Each project allocates a 5 year budget to support that application, and we need to manage those activities just as well as projects, if not better. In fact, support tickets are like mini projects. They contain an analysis, design, implement, test, deploy, and stabilize phase just like projects do. The only real difference is that upport activities last less than 15 days. This is another great way to get new staff familiar with a new environment. We set aside two people offshore to be responsible for support. The tickets were divided across the two people. And they had all the same resources as the project based developers. These two very quickly got a cross section of all projects and sites, tools and technologies, and processes and procedures.

We had also implemented a role onshore that would be responsible for coordinating all support, both across technologies and across the globe. This person was responsible for support assignment, workload, quality, and process, all as it related to support. This was received well. Support functions now had a champion; a clear voice representing their perspective.

Next

In my next post, I will cover the results of our new outsourcing contract, and how some other teams were impacted by the outsourcing contract. I will also cover and how it became the most important decision of the year for the team.