Picking your own Path!

I’ve been around the block for a while now.  Later this month I’ll turn 51 – which means I’ve seen all sorts of things during my career.  I’m lucky – I love what I do and I knew I wanted to be in software development very early in my life.  I touched my first keyboard when I was 12 and began programming in Basic on a DEC PDP 11/70.  And if that alone doesn’t date me, my first programs were created on punch cards and teletype terminals – yep a keyboard with green bar paper running through it that would physically type out the commands entered and responses would come back and print on the green bar paper.  The smartphone I have in my pocket has significantly more power than that first computer I used.  My Nana always used to joke that I was going to fry my brain working on those ‘computers’!

I also knew at a young age that I eventually wanted to be in management.  I had grown up watching my dad run various companies – some failed, others were successful.  While I was in high school, my dad started the final company that he would run – it became very successful and provided him with years of enjoyment until he retired several years back.  Exposure to these companies and the environment in which my brothers, sisters and I grew up in made me realize that at some point in my life I wanted to be in a leadership position – I wanted to run the world!  If I had only known then the growth I would need to be in the position that I hold today!

So why am I rambling on about my early career?  Well, at one point, I had several people attempt to convince me not to move from development into a management role.  I was reminded of this recently because someone that I’m acting as mentor to, is having the same experience.

Moving into management is tough for someone who is in a technical role.  I’m not saying it isn’t tough for other professions – it probably is.  That said, I’m speaking from the personal transition I went through.  I was used to being the one in control – at the end of the day, I could look back at the success I’d had that day pounding out the code.  I was good at what I did – I liked the tough technical problems and my managers relied on me to solve problems.  I absolutely enjoyed being a developer – it was fun, I got to solve problems, I got to play with new stuff that nobody had ever seen, I was recognized for being a person that could just get stuff done.

Eventually, I got to the point where I decided I wanted to transition into a management role.  As I began to tell people that management was something that I wanted to try.  I got feedback from all over the place that I should just stay where I was at, to eventually become a lead or an architect.  Many folks had an opinion to share and staying technical seemed to be the theme behind most of the comments.

Well, for me, it came down to what I wanted not what other people wanted for me!  This is important; you can’t let someone else determine your path forward.  If you know what you want to do with your career, then you have to make it happen.  You can blindly sit there and wait for someone to notice you and maybe give you the opportunity, or you can take proactive steps that will get you into the position you want to be in.

I recently sat down with someone who is contemplating making a similar move in their career.  We had previously discussed this “change” in their career and I know that the individual has communicated with their boss about finding a path between their current role and into a management role.  This individual than began to tell me of all the feedback they were getting from all over the place on why they should stay in the role that they are in.

I let this individual pour it all out on the table.  Then I asked them, "who cares what everyone else wants, when you look at yourself, what is it that you ultimately want to do with yourself?"  Now, I fully recognize that this individual is really good in their current role – and I mean really good.  That said, how happy are they going to be in the future if they at least didn't try?  This individual didn't hesitate, looked across the table and said, “I know I’m meant to be a manager!”  My reply, “Then why are you letting other people create doubts about what you can become?”

I have no doubt that this individual will experience some challenges moving out of the role they currently play and into a management role.  I also have no doubt that this individual will be successful in either role.  I also know the people this individual works for will provide the support needed to transition into the new role – they've done it with other folks on the team!

Sometimes you can’t listen to those around you and you need to chart your own course.  Don't be afraid to make a change and when you make the decision - proactively take steps to make it happen!

See more about my life in technology via: http://anidea4today.blogspot.com/

Plan for Success ... Be Aware of Reality!

I run hard! My teams run hard!  We’ve got a lot on our plates and the pipeline is overflowing.  As soon as something is done, there are 5 more things waiting in the wings that need attention.  That’s a good thing – it tells me that the business values the services that my teams deliver on and that we can continue to be a difference maker within the organization.

As we go about our business – we plan for success.  Delivering product and services that our Financial Institutions can use to succeed in the market and make a difference with their customers.  Over the last several years, we have built a process around activity that ensures that we know why we are building something, we know the success factors around what it is we are building and that we then can design, build and QA the stuff we are moving into our production environments.

The teams have done a great job of reducing the number of iterations built before code can move into production.  Translation, they’ve reduce the number of critical errors found during testing that requires additional iterations prior to implementation!  They’ve also significantly reduced the number of issues that require after hours support.  Our teams have worked together to reduce the overall amount of time needed to regression test our products.  We are doing automated nightly builds on our code and are well on our way to having a full suite of regression tests run along with the automated builds.

So why am I talking about all of this?  Well, to put it all in perspective, it doesn’t seem to matter how well we refine the processes and manage the activity, we still have things go wrong!

1. Requirements identified after development is under way. 
2. Designs between teams that sometimes conflict. 
3. Estimates of project activity that end up being woefully incorrect. 
4. Resource constraints across teams just based on the sheer volume of activity. 
5. Data issues within our test environments. 
6. Validation exercises that end up taking longer than planned.

You know the drill.  You’ve all seen similar stuff happen to your projects.  So what’s a team to do?  Well as much as we want to keep our rose colored glasses in place and see sunshine and rainbows, it’s our job as leaders and technical experts to measure and apply a dose of reality within our projects.  The organization is looking to us to deliver new features/functions into the production environment.  They don’t really care to hear about how we make the sausage or why it might be taking longer.  What they do want is a semi-reasonable date as to when the features/functions will be available and what it means to our Financial Institutions and our Acquirers.

So, translating back to our internal teams, that means we need to make reasonable estimates along the way and refine as we move through the process.  As technicians, looking at and identifying the tasks needed to complete the activity – you can’t assume everything will go the way you want and your estimates need to include the breathing room you’ll need when something unexpected pops its head up.  As project managers, you can’t believe everything you’re being told – you need to validate what is being said and ensure people are on track.  Depending on the complexity of the project, you may need to put in some buffer time between the various activities to ensure that the teams have time to stay on track and recover from unknown issues.  This may not be needed on smaller less complex projects, but as the complexity gets bigger, you’d better start thinking seriously about buffer space.

I am not advocating that you needlessly pad time into your projects to make a 6 week effort end up taking 10 weeks.  What I am advocating for is that project resources accurately evaluate their tasks in a realistic fashion and feed those numbers back up to the project manager – that includes identifying the riskiest tasks and ensuring that you’re not being overly optimistic on the estimates.  Additionally, the project manager needs to review those estimates coming in and ensure that the numbers are ‘good’ and make judgements on where additional time may be needed to address parts of the process that look to be difficult.

I’ll give you a perfect example within my own organization.  With our large enterprise wide projects, we perform an integration test within development prior to moving the code into our formal QA and Parallel environments.  We began this formal ‘integration’ test effort probably a year and a half ago.  This testing required us to ensure mock data was setup across various platforms and application silos that would allow us to take transactions across the entire ecosystem.  This was initiated to ensure that by the time the code hit QA that we had successfully tested input/outputs and application handoffs between the various silos.

When we initiated this new step in our overall lifecycle – we were extremely aggressive in how long we thought it would take us to build the environment, populate the environment with the correct data and then execute the integration test plan.  I kept pushing the team to get all this activity done within a short time window so that we could then get into the ‘real’ testing and move the project forward.  Whether planned or not – the time associated with this integration testing took longer than planned and we eventually had to account for that within our planning.  Now that we’ve been through several iterations, we are beginning to automate various pieces of the environment and data setup/configuration – this should help us draw the time back down

Our goals were right, this helped us implement code into production that had a higher level of quality, however, I created a set of false expectations within the teams on the durations associated with this activity and they needed to give me feedback to reset my expectations and identify the correct timeline within the overall project activity. 

If you'd like more information on my background: LinkedIn Profile

Practicing What We Preach …

This week, I got a small dose of humble pie from our CIO.  I was in his office discussing the difficult time that one of my teams was having filling a key position.  Finding someone is critical to the success of this team and it has been difficult finding candidates that would be able to come in, hit the ground running and make a difference.  We have key criteria for this position, and I’m not willing to budge – this is one of those times where I don’t have the luxury of training someone, I need someone with a specific skillset and experience.

Before everyone goes all crazy on me for speaking out both sides of my mouth, I normally utilize a very aggressive internship program to fill open positions within my team.  It is rare that I hire experienced candidates.  When I do, I am very specific about what I am looking for and I stick to my guns.  I won’t hire someone just for the convenience of filling the role, I will wait until I find a candidate who fits the needs that I have and that be a net positive for the team.  I’ve bent in the past when I felt I just needed to get a body in the door, and it’s a painful experience.

So, then, let’s get back to the story.  I’m sitting in-front of my boss – our CIO – explaining what steps I’ve taken and where we are at in the process.  He’s letting me vent and as we get close to wrapping up this part of the discussion he asks a simple question, ‘Have you considered hiring someone remote?’

Whack – right to the center of the forehead!  Ok, so you need to understand for the last several years, I’ve been the most vocal proponent inside the organization to allow our team members to work remotely.  We have successfully introduced it into my teams and this has slowly crept into a couple of other areas of the company.  This has been allowed in a very limited fashion, but has proved to be successful enough that a key member of our team moved to another state and organizationally, nobody questioned his ability to continue working for us when he asked if he could do so prior to moving.

Additionally, via an acquisition several years back, one of my teams is split geographically with the manager located at our main facility with half of his team and the other half all working in disparate locations across the southern US.

So there I am the biggest proponent of getting people to work remotely sitting there in front of my boss looking like a fool! Organizationally, we are ready to expand this program.  In fact our COO has recently spoken about the need to show flexibility in where our teams are located.

What could I say, but, ‘You’re right! I guess it’s time for me to step up to the plate and take the next step and push this program forward!’

As leaders within an organization, we have to remember the things that we are fighting for and when given the chance, we need to implement those changes into the organization.  Our bosses expect it of us and we expect it of the people that report up through us – we need to remember, the same rules apply to us.

If you'd like more information on my background: LinkedIn Profile

It's NOT about the Tech or the Process - it's about the Customer!

This week I have the pleasure of participating in the annual SHAZAM Forum!  It is an event that my organization holds each year to keep our Financial Institutions informed on key trends within the industry.  Over the next few days I will have the opportunity to interact with hundreds of our customers.  To listen to their stories, to understand their needs and to enjoy some time together.

Let's be honest, as much as I care about the tools that we use and the processes that we have in place.  Our customers really could care less.  They care about that fact that the systems we provide will function - that they can open a new account when someone walks into one of their branches, that they can process a loan when one of their commercial customers needs a new piece of equipment, that their account holders can login to their internet banking site and transfer money between accounts, that their account holders can use their debit card when purchasing groceries at their local grocery store and that when I detect some fraudster starting to steal their customers money - that it is stopped.

They really don't care that I use Java or C++, they could care less if I used Agile or Waterfall project management paradigms.  They don't think about the various testing methodologies in place to prevent bugs from impacting their ability to perform their work.

Put simply - our customers want and deserve to be delighted when using the systems and services that my organization provides.  They don't want to know the details of why or how we made decisions and built the services/systems, they just want to be able to use them to conduct business with their account holders.

I look forward to our annual Forum because it's my opportunity to get to know the folks that choose to do business with the organization that I work for; I get to hear what is important to them; I get to listen to the frustrations that they have using the systems that my teams build; I get to listen to the concerns that they have about the market that they serve.

Let's be honest, on a daily basis, most individuals within an IT organization have very few opportunities to interact with the customers of the systems that they build.  I'm intentionally not counting the internal customers.  Internal customers are important, but they do not provide a true reflection of what our Financial Institutions, their employees and their account holders are challenged with on a daily basis.

It's important to occasionally step away from the technology and immerse yourself in the world that your customers deal with every day.  To understand their interactions with the systems and services that you build so that you can understand what needs to change in future iterations.

In other words - it's not all about me, it really is all about the customer!

For those of you that will be attending our Forum - I look forward to seeing you again this year or meeting you if it's your first time!

If you'd like more information on my background: LinkedIn Profile

Logic and Project Management!

As a child, I was glued to the television whenever there was an opportunity to watch Star Trek!  I loved the show - campy by the standards of today, I couldn't help myself as I wanted to be on the Starship Enterprise as she traveled to the stars.  And, yes, my favorite character was Spock - followed closely by Scotty.  Spock in may ways spoke to many of us - using logic instead of emotion to solve problems.  And when he did let his emotional side out of the box - showed that emotion could and would frequently lead to painful mistakes.

So, why am I using space within a blog focused on project management and applications development to discuss Spock?  Logic - use it to succeed within your role.  Strip aside the emotion that you feel when confronted with issues and follow the facts!  Stay calm, track down the details and use those details to identify the move forward solution.

No project of any realistic size moves from idea to implementation without some sort of issue rising up, ready to take the whole thing off the rails and into the ditch.  Some problems are small and others tend decloak themselves like a Klingon battle cruiser to surprise and fire upon your Starship Enterprise!  These incoming salvos threaten to overwhelm you, the team and the project.  At this point, you can either act emotionally, running around without a plan and make the problem worse.  Or, you can act like Spock - use logic to create a plan, execute the plan and overcome the issue.

Planning:

Sometimes with a small issue, you can 'wing it' and successfully manage the issue.  That said, the larger the issue, the more likely you will need some type of plan and process to deal with the issue.  Leadership in the organization is going to expect you to communicate the issue, progress in finding a solution and then progress against whatever plans are ultimately put in motion to resolve the issue.

There will be wide variety of additional items you will need to manage within the overall effort:

1. You may need to setup a research team to investigate how the issue was missed or what the cause of the issue was so that this information can be communicated to the management team.
2. Additional personnel resources beyond the original scope of effort associated with the project to identify the overall solution as well as assisting in any work needed to implement the solution.
3. Additional budget resources beyond the original scope of the effort to cover any additional internal or external resources needed to provide the overall solution.
4. Communication plans may need to be put in place to update internal resources, communicate with and manage customer expectations and manage any risk to the overall reputation of the organization.

Each of the above items will require management effort from the Project Manager to ensure that future milestones within the overall effort are adjusted and manged properly; and to coordinate activity between various team members, departments, and outside consultants.  All of this will take careful planning, using organizational skills to minimize the impact to the project.

Methodical:

Many times as a Project Manager you are dealing with choices - making decisions about where short-cuts can be taken; making decisions on whether to go with Plan A or Plan B when there is no consensus from the team on which direction to take; sometimes sifting thru agonizing amounts of detail to understand an issue so that it con be communicated to the management team.

As the complexity of a problem increases, the number of details being tracked or managed associated with the issue will grow beyond your minds ability to track them all.  You are going to need processes in place that allow you to align the issue resolution within the overall tracking mechanisms in place to manage the project.

1. You will need to track new data points within and aligned to the overall project - new milestone dates, budget information, new internal and/or external resources, new equipment that may need to be purchased.
2. You will need to realign your current schedule to accommodate any new milestones associated with the new effort.  Especially those new milestones that will require current or future activity within your plan to be delayed or altered.
3. You will need to ensure that communication plans are executed properly not only to manage internal expectations, but just as important to ensure that customers, vendors, the media and other 3rd parties are kept in the loop.

Your role as Project Manager requires that you have a plan, that you execute the plan and that you manage the expectations of your team members.  You need to be the calm within the storm.

Detail Oriented:

Team members are going to be hitting you with lots of information - your job as Project Manager is to sort through the minutiae and ensure that the relevant data is recorded, tracked and used to make decisions throughout the overall project lifecycle.  As Project Manager, you will be expected to identify the important pieces of data, communicate that to the team and ensure that the information is available within meetings as decisions are made on the forward progress of the project effort.  

Additionally, management will expect that you understand the relevant pieces of information within the flood of details and know when to present that information up the ladder.  Many a Project Manager or Manager have failed when they have forgotten to keep the leadership team informed on decision points and the underlying information used to make those decisions.  I'm not saying that you should have the expectation that your being micro managed - but when there is an unforeseen issue that crops up, over communication is necessary to ensure that everyone understands the nature of the issue, the solution being implemented and the overall impacts to the organization.

Logical:

You can be angry and frustrated - that however is not going to help you move the ball forward and find a solution.  At this point, you need to step away from your emotions and use logic to understand where your at, what data points you have available to make a decision and then make short and long term decisions based on that information.  Knowing that you can adjust future activity and decisions based upon additional data points that surface.

Spock would 'follow the facts' to get to the answer - wherever those facts happened to lead him.  That's your role!  You will be tempted as angry and frustrated team members, management, customers or 3rd parties call you or come over to talk with you.  At times, you will want to 'fire back' at the individuals - however, it is better to step back, take a breath and then approach the conversation.  Focus on the fact, just the facts!  Use logic - it is the best tool you have at your disposal to deescalate the situation.

Mr. Nimoy, you are and were an inspiration to many of us ... may you live long and prosper among the stars!

If you'd like more information on my background: LinkedIn Profile

Education and Software Development - It's going to get Rough!

I've been talking to several different groups lately on how we attract more people into technology fields - specifically Applications Development.  If your an employer and you're out looking for development talent - it ain't easy!

Maybe for the larger companies that have offices all over the country and that can pull from multiple pipelines, they might have it easier.  But for many small to mid-sized companies that are attempting to build or maintain their development shop - it's tough to source good talent.

Don't get me wrong - if you take your time, don't panic and hire the 1st candidates that show up (even though they don't match the qualifications or clearly will unsettle the team) and force yourself to hire individuals that truly meet the needs of the position and have the personality to fit in with the team, you can do it.  The flip side is you loose months of productivity within the team because the position sits open.  Now let me state right here - I will take the pain of an open position vs hiring the wrong person into the position.  And, yes, I have the scars to prove hiring the wrong person is a bad idea.  Trust me, it just doesn't work.

I will not speak for every company, or every geographical area across the United States.  We all have our own issues when attempting to find employees.  Overall, I think I have a great story to tell prospective employees - from the organization that I work for to the community that we work in, there are a lot of positive things happening.  Look no further than the following link if you want to know why folks should look to metro Des Moines area as a place to work and live.  This is a beautiful community with easy access to other metro areas and a lot of reasons to live and play right here at home.  We have plenty of colleges and universities in the metro area and our K-12 educational system is as good if not better as any other school district in the country.

However, I compete against a lot of companies in the local area for talent - large financial and insurance companies, to small and mid-tier companies - including tech start-ups.  The baby boomers are beginning to retire - which is leaving holes in all of our teams.  And our companines are demanding that IT shops expand to meet the needs of internal and external users.  In essence, we are competing for the same talent and we all need to be honest about where we are going to find these workers and also be honest about the false criteria we have within our hiring process that rules out good people.

Back in the day, many school districts actually had software development classes taught in the high schools.  I was lucky, when I was 12 I had a friend show me a teletype terminal (just dated myself) hidden in a small room at the middle school I attended.  I was curious and wanted to play around with the thing - not knowing what it could do.  Luckily, I had a math teacher that got me an account on the computer that the terminal was connected to and I began to teach myself BASIC.  By the time I hit high school, I was able to take formal software development classes using Fortran (and, yep, I've dated myself again).  If my memory serves me right, the high school instructor that taught me Fortran also ended up teaching me Assembler outside of class - that was some real fun.

Today, very few K12 school districts have formal technology classes provided to students.  Some of the larger schools in the metro area are able to provide them, but many don't have the money and the smaller school districts from what I can tell don't have the expertise or the money.

Well, in my opinion something is going to have to give:

1. As parents - we need to stop hitting the easy button!  School is to prep our kids for the real world after they graduate.  While I encourage my own kids to be involved in sports - it's not at the expense of their education.  If there is a tough test coming up - I'll pull them out of practice to ensure that they are ready for the test.  We also need to speak honestly with our kids about what careers will allow them to live independently when they leave the house and move out into the real world.  We also need to support the instructors that are teaching our kids - that means when they aren't getting the grades we expect we hold the child accountable as well as the teacher.
2. At the middle school level - kids need to be given formal opportunities to play with technology both from the hardware and development perspective.  We also need to change the way that we communicate these opportunities and ensure that we market these career opportunities equally to young women and young men.  Our field is woefully underrepresented by women - this didn't use to be the case and we need to turn this around.  If that means we have young women only technology competitions, than we have to think along those lines.
3. We need to begin ensuring that every school district has the means to provide technology trade classes to their students.  Much like we have trade classes for auto (used to also have for metal and wood - some high schools still do), we need to have trade classes at the high school level for Technology fields.  If done right, these students should then be eligible for entry level jobs into the work force.
1. Infrastructure courses that allow students to learn how to build and troubleshoot networks.
2. Application courses that introduce students to the concepts of software development using scripting languages and progress to more structured languages used by business.
4. We need to encourage our State Department of Education to ensure that Computer Science courses taught at the high school count towards the overall Math and Science credit.  Some states have even moved to count these courses as foreign language courses replacing Spanish, French or German.
5. We need to look at the possibility of software educational boot camps.  I've been looking at these as tools to find developer talent over the last couple of years.  I have yet to pull the trigger, but based on what I'm reading and hearing, this is going to become a valid tool for many of us.  This is a very compressed educational and hands on environment that gives someone the basic skills they will need to join a firm as an entry level developer.  Usually requiring 10-12 weeks of 40+ hours a week to get the student ready and certified.
6. We need to encourage and work with our Community Colleges to ensure that their course curriculum matches the needs of the business community - unfortunately, technology changes happen frequently and it's tough for the Community Colleges to keep retooling for the latest greatest fad.  We need to encourage the Community Colleges to stick with the bread and butter of what is needed within the local business community - augmented with some of the newer technology.  Slow down the pace at which they retool.
1. While some of the scripting languages are hot, most business have standardized on Java, C++ and C#.  Let's make sure that they are learning the languages that will get them jobs.
7. We need to continue to work with our 4 year colleges and universities.  Ensuring that their course work aligns with the needs of the business community.  These are fine institutions and they provide a much deeper experience for candidates before they come into the workforce providing both deeper theory and the practical how to of applications development.
8. As business leaders and technology leaders - we need to make sure we are seeding our technology teams with entry level candidates when at all practical.  While it is easy to go out and hire only 'experienced' candidates - we are doing a disservice to the organization by not mentoring our next generation of leaders and subject matter experts.

We have become somewhat complacent because we have traditionally held a very strong lead on the rest of the world.  That lead is evaporating and we need to ensure that we are preparing the next generation to continue along the journey. 

Collectively, we need to get off our back end and demand the best from our kids and their schools.  We need to look at multiple ways to source entry level candidates into our organization and we need to be flexible when we look at how these entry level candidates got their education.  The days of sitting back and demanding that every candidate have a four year degree are over.

If you'd like more information on my background: LinkedIn Profile

Off-Shore Development - Plan it right or Fail!

Off-shore development continues to be a discussion point within many organizations.  I've managed teams across the US and had the occasion where I've used off-shore resources.  Let me share some of the experiences in the hopes that it helps others that struggle with the model or are questioning whether to proceed with the use of off-shore resources.  I won't claim this represents the model to run off-shore development, ultimately, you need to make the decisions that will work within your organization.  Hopefully, this will shine a different light on the topic and allow you to gain insight that may help you make the decision to use off-shore development resources or to keep the development on-shore.

First, it is not easy.  If you think this will solve issues within your current development lifecycle - don't bet on it.  If you're going to seriously begin to use off-shore resources, you better plan appropriately, or you'll pay the price with development timelines that get extended and budgets that creep beyond your expectations.  In the worst case scenario, you'll end up rolling product into production that has not been properly tested and vetted.

Some of the breakdowns that my teams encountered in using off-shore resources are as follows:

1. Communication - eliminating the natural lag in communications as teams work shifts that do not align.
2. Design Aberrations - ensuring the product developed fully conforms to the original design/requirements.
3. Coding Standards - putting processes in place to ensure that the off-shore development team followed the development coding standards of our internal teams.
4. Quality of Code - ensuring that the code had been properly tested all the way through integration testing with other application silos/subsystems.
5. Quality of the Team - ensuring the consistency of development resources applied to projects.
6. Product Knowledge - ensuring that knowledge of team was retained from project to project.

The above list covers the major challenges that we encountered.  Let me go in to some level of detail so that you can get the flavor of what was experienced and how we handled the longer term needs of the organizations use of off-shore resources.

Communication: Each and every day, without your knowledge dozens and dozens of project decisions are made as developers lean across the walls and talk to each other or see each other walking around the office.  My teams have been no different, requirements and designs could change based on a hurdle that needed to be solved and a quick conversation in the hall.  Suddenly you have a team separated by multiple time zones - in my case, they had left the office for the day by the time we arrived in the office.  If the remote team had a question, or hit a roadblock and needed direction, there was an automatic lag of at least 1 work day.  If it was a serious issue, the team might loose several days as communication threads worked their way through email.  In extreme instances, we might have some of the remote team stay late or some of the local team come in early to establish conference calls and work out the issues.

Design Aberrations: The standard methodology we used to develop project requirements within the organization wasn't sufficient to support the use of outside resources.  Didn't matter if those resources were on-shore or off-shore, our teams were comfortable dealing with each other and could abbreviate how the requirements were documented.  There were a lot of things assumed within the requirements that didn't need further explanation because the teams had years of experience working together.  This continued to feed through the process as design documents were generated by the team.  Suddenly we introduced a team of developers that did not have that tribal knowledge.  The results were obvious in hindsight, the off-shore resources built the product to match the documented requirements and designs.  The only problem - those requirements and design documents didn't contain the unspoken elements known by the internal teams.

Coding Standards: Some of the products that we chose to develop off-shore ended up needing to be supported by local teams.  We quickly found out that the coding standards we had in place were not documented thoroughly and left many items up for consideration.  Translation, the remote team was producing code that looked like none of the other code that was used internally.

Quality of Code: The internal teams had many years of experience working together, touching each others code and making the necessary revisions to the code base.  Suddenly we had bugs that had been solved being reintroduced into the code base later in the development cycle.  Worse yet, we would find chunks of code that were never being executed, yet were loading up the code base.

Quality of the Team: Just as we were getting used to working with one set of developers, suddenly they would be reassigned to a different project and we would end up having to reacquaint ourselves with a new team.  To say that this slowed down development and introduced inconsistencies into the code base would be an understatement.

Product Knowledge: As we completed development with one project and started up the next project, we were not assured that the team we had gotten used to would continue on and do development on the next project.

None of this is serious and can be resolved, but you need to think through the engagement up front and take the necessary measures to protect your organization.  Here are some of the tactics we began to utilize to minimize the risk in the use of off-shore development resources:

Communication: We required the off-shore company to place one of their resources on-site with our local teams.  They became the primary communication point between our teams and the off-shore resources.  They sat in on the meetings locally and could catch the small things that needed to be communicated to the off-shore team.  They could do the impromptu meetings in the hallway and get that information promptly to the remote teams.  Our project timelines included buffers to accommodate the communication lag between the teams.

Design Aberrations: We ended up beefing up our Business Analyst and Architecture teams to create more thorough documentation.  Our documentation became much more thorough and attempted to accommodate the things that people took for granted.  The architectural diagrams became much  more sophisticated outlining all servers touched, all databases touched and were color coded to identify new, changed or removed elements.  Design documentation began to reference not only the objects that would be touched, but could go down to the individual methods and parameters when needed.

Coding Standards: We ended up going through our coding standards and documenting much more thoroughly how code was to be structured, how variables names were to be created, what security precautions were to be taken when creating the code, etc. 

Quality of the Code: Code created by off-shore resources was required to go through the same code review process that we used for internal teams.  This ensured that our senior developers were reviewing the code - exactly as would be done for internally written code and that they could catch issues and feed them back to the remote team.

Quality of the Team: After some experience with team members shifting, we ended up negotiating with the off-shore company to ensure that we had a core set of developers that would not be reassigned off of the project.  This allowed us to maintain some level of consistency within the off-shore team and addressed quality of code, coding standards and communication issues.

Product Knowledge: Similar to the Quality of the Team issue - by keeping a core team of developers assigned to our projects, the off-shore teams knowledge base of our products began to increase and they could begin to anticipate some of the issues ahead of time.

I want to state again, these were experiences that my team had in working with off-shore resources.  Other organizations may have different experiences.  Hopefully, some of these issues and the ways in which we resolved them will assist you with determining whether you can support the use of off-shore development resources.

I typically do not use off-shore resources unless there is a need to temporarily augment our internal resources to accomplish specific development/project goals.  That's a choice that I feel comfortable with based on the particular business needs within the organization.  In previous roles, I've had the opportunity to work extensively with off-shore resources.  If you're going to use off-shore resources, I highly recommend you pick a couple of small projects and trial a couple of different vendors to establish which one will work better with your current development paradigm.  Don't be afraid to switch  vendors if you don't feel you're being taken care of - ultimately, it's you that will be held accountable for the delivered product.

If you'd like more information on my background: LinkedIn Profile