Subscribe to this blog

Follow by Email

Search This Blog

Considering Outsourcing Software Development - a model

What are the considerations when the business wants to reduce the cost of the IT department and they want to outsource some or all of the costly software development group? Here is a model to help you think through this decision and some additional resources.

Introduction

What decisions must be made to implement an IT Outsourcing program? Are these decisions similar to the decisions that leaders must make for an Agile program? How do they differ, how are they similar? What are the expected outcomes, and the possible outcomes? Which decisions have high stakes with no-return points along the transition map? Which decisions are safe-to-fail and possible to repeat and iterate toward success?

Comparing and contrasting basic road maps for the implementation of major process change is fraught with generalizations that may easily be questioned. The intent of this paper is to objectively represent the set of high level decisions and expected outcomes that lead to a success regardless of which path is chosen. Choosing the path is your decision.

A general model

If we model the decision path as a journey with an expected destination, but unknown terrain this metaphor may serve us well. Journeys are made of many decision, some made before the terrain is known, some made with little information, many decision must be adjusted as the journey progresses.

…. to do…

Decisions to be made along the path:

Can innovation be separated from execution without extreme risk?

Does outsourcing add value -or- just decrease cost?

How does the outsourcing approach transition to a value-add mind-set?

What need are we addressing with an outsource model: from innovation maintenance?->

Is it to reduce the cost of IT to the organizations - or - might it be a more aspirational goal? More in alignment with the corporate mission.

Why do organization outsource?

Software development is not a simple endeavor. Standish Group has studied the problem space for years and release yearly reports that in general show an marginal improvement in recent years from a low point of roughly 80% failure rates a decade ago. However; “[o]utsourcing has not proven to be a magic wand; it has failed to deliver the expected results over fifty percent of the time.” (1, 3) Gartner predicts that spending on outsourcing will increase from $268 billion in 2009 to $325 billion in 2013. Research suggests the reason for this increase is the perception of economic, technological and strategic benefits. These benefits come with additional challenges, and externalities.

Organization outsource to:

Focus on core activities

Reduce cost of development executation

Add staffing flexibility for special projects

Augment skills not presently available

Reduce development time associated with project ramp up

Improve quality (by working with more experienced developers)

Improve management (by levering vendor’s experience/knowledge)

Define our reason to outsource - be absolutely clear about why. A clear purpose will enable decisions with reasonable chance of success.

What challenges does outsourcing resolve?

The cost model is typically the first response to the reasoning behind the decision to outsource. Engineers in offshore locations are on relatively low compensation plans compared to the US, this relative cost advantage is apt to shrink fast however (5).

The scheduling of project manpower and resources is another key reason to outsource. When project ramp up and termination are time sensitive offshoring may have tactical advantages to staffing internal projects with varying resourcing needs.

Specialized skill sets are another key reason to outsource. Assuming that the skill set is not a core capability to the problem domain.

Mid-term budgeting and cost accounting become easier. Small projects cost accounting becomes cost prohibitive so effort must be done to aggregate small project, or define a class of service that allows for ad-hoc scope management.

What challenges does outsourcing compound?

While software product development is a known challenge, outsourcing is a known challenge compounded by more players on the field. The software development process will be distributed across multiple organizations with multiple cultures and value systems.

Outsourcing firms must effectively manage:

the scope of projects

the process that implements the deliverables, and

the people involved (customers, their clients, their staff, as well as vendors).

The pitfalls of an outsourcing model:

Requires constant highly skilled management and logistics

Increases departmental frustration

timezone differences lessen communication windows

need for higher quality architecture

lower quality of solution (not what we wanted syndrome)

need for better testing

scapegoating the vendor

testing is more difficult & results in longer test/fix cycles

company morale may suffer

There is no one right model to handle all of these management tasks. In the grand scheme of things, success in outsourcing depends on how well you plan, organize, execute and control these very areas that are required for in-house development also. Failing to understand these factors and relationships puts the outsourcing program in high risk of failure.

Successful Project Scoping for Outsourcing

Projects that are well defined in terms of scope/features (well known technology and well know requirements) are simple and prime candidates for outsourcing [the simple domain of the Stacey Diagram].

Project types require various amounts of effort in scoping - not all projects are the same - don’t treat them similar. The most difficult is the innovative new application platform with a high degree of market risk. These are typically high and to the right on the Stacey diagram. Requirements are not well known, and the technology used is far from certain.

Scope management is the ultimate driver of value delivery. In the traditional PMI Iron triangle managing budget is a well known problem domain, managing schedule is difficult but practical when using a Project Process Management model, however scope management is the most difficult. It is also the leg of the iron triangle that is most often ignored as a lever to be used by the customer to make scope decisions with economic trade-off in mind. Having a value-based model of project success has proven more satisfying to customers than a cost model (implied all scope & implied on schedule) model.

When project scoping is easy and well done the project is ripe for outsourcing.

If scope change management is a likely difficult internal process - then adding a few more contractually obligated layers (vendors) is exasperating the issue. Scope changes must be controlled, they increase workload, and management overhead, they raise costs and lengthen schedules, as well as hamper quality and integration capabilities.

A latent problem with outsourcing is the division of total project delivery scope. Few new application development project scope out the actual delivery of the product and all it’s ancillary systems and work streams. Scope division is the process of understanding the responsibility and ownership of work to be done in-house and by vendors. Not all of the work may be outsourced. Retaining the knowledge of systems and integrations is key to continuity of the business. Counter these risk via well designed architecture components that are independent of each other. Foster accountability and ownership of components by a single entity. Deploy frequently and test all interfaces.

Outsourcing may provide many economic benefits, yet it still follows basic economic rules. It saves on wages and real estate costs, but cannot always significantly reduce the amount of time that a project takes.

Successful Project Process Management for Outsourcing

The business process of outsourcing is very important and must complement the software development methodology. This management process includes: defining the vendor team structure and interfaces, the development methodology to be executed across the client/vendor system for the project, software development management tools (source control, build systems, test systems, project progress reporting, collaboration & communication tools), proper quality assurance expectations both at the vendor and the client, as well as customer QA.

Team Structure - beyond the typical player on a software development team, outsourcing project typical require the overhead of two key roles. An in-house product manager responsible for daily interactions with the development team insuring timely resolution of problems that arise in the development requirements. A vendor-located technical leader, responsible for the vendor team and highly collaborative with the product manager.

Tools and metrics for monitoring the project should be selected to match the type of project (new development or maintenance), the development methodology (waterfall / agile / lean), and the companies cultures. When selecting a vendor a fluent demonstration of their management tools is a great indicator.

Vendors with a mature outsourcing program will have a well known and easily demonstrated quality assurance process. If the QA work is to be done in-house rather than by the vendor this scope division should be well understood and the cost/benefits weight and measured throughout the life of the project. Establish typical engineering standards such as: coding style guides, documentation standards, controlling procedures, bug tracking and reporting, defect prioritization and triage responsibilities, testing phases in the release plan as durations, release criteria with regard to defect count, severity, types of testing to be performed (usability, regression, performance, load, etc.). One perspective of outsourcing vendors is to gauge their maturity in QA; vendors with a long history and successful future will have developed mature QA capabilities.

A core capability of outsourcing vendors is their communication techniques. When the team is physically separated (as in most outsourcing situations) communication becomes a multifaceted issue with compounding issues such as: language and culture, approval chain of command, time zone, domain knowledge, travel, and industry experience.

Successful Project Stakeholder Collaboration for Outsourcing

Make specific plans to involve the customer, end users, and key stakeholders in the development project. Active participation in the process leads to greater product satisfaction. Clearly define their role and responsibility, setting expectation and constraints on their involvement. The proper balance will change with project type and methodology.

Prior to outsourcing software development the organization must be prepared. This decision has long term effects and will effect the attitudes and motivation of many existing employees. While pursing an in-house development organization hiring decision are biased toward development skills; in an outsourcing organization the managerial skills will ultimately lead to success.

Beyond the typical software development project related management issues, the outsourcing program has higher level concerns to deal with. These are typically handled via contracting and source selection processes, and then via executive level negotiation of problems and breeches.

Typical Outsourcing Issues (non-software development related): (6)

Liability Insurance

Software Licenses for third party access to systems

Ownership of information (sample data and testing data)

Inter-organizatioal system performance and access requirements

Service Level Agreements

Reporting and review of SLA

System access and security

Intellectual property indemnity

Distaster recovery

Many organizations spend countless time and energy selecting and reselecting an outsourcing vendor. This trial and error process may result in a well integrated vendor that is an indispensable partner.

Comments

Most Popular on Agile Complexification Inverter

Assuming you are on a Scrum/Agile software development team, then one of the first 'working agreements' you have created with your team is a 'Definition of Done' - right?

Oh - you don't have a definition of what aspects a user story that is done will exhibit. Well then, you need to create a list of attributes of a done story. One way to do this would be to Google 'definition of done' ... here let me do that for you: http://tinyurl.com/3br9o6n. Then you could just use someone else's definition - there DONE!

But that would be cheating -- right? It is not the artifact - the list of done criteria, that is important for your team - it is the act of doing it for themselves, it is that shared understanding of having a debate over some of the gray areas that create a true working agreement. If some of the team believes that a story being done means that there can be no bugs found in the code - but some believe that there can be some minor issues - well, then yo…

I’ve noticed a new trend—people have been gaining titles. When I was younger, only doctors had initials (like MD) after their names. I always figured that was because society held doctors, and sometime priests (OFM) in such high regard that we wanted to point out their higher learning. I hope it was to encourage others to apply themselves in school and become doctors also. Could it have been boastful?

The Wikipedia describes these “post-nominal initials”:Post-nominal letters, also called post-nominal initials, are letters placed after the name of a person to indicate that the individual holds a position, educational degree, accreditation, office, or honor. An individual may use several different sets of post-nominal letters. The order in which these are listed after a name is based on the order of precedence and category of the order.
That’s good enough for me.
So I ask you: is the use of CSM or CSP an appropriate use of post-nominal initials?
If your not an agilista, you may wonder …

Amazon book order
What I notice first and really like is the subtle implication in the shadow of the "i" in Drive is a person taking one step in a running motion. This brings to mind the old saying - "there is no I in TEAM". There is however a ME in TEAM, and there is an I in DRIVE. And when one talks about motivating a team or an individual - it all starts with - what's in it for me.

Introduction

Pink starts with an early experiment with monkeys on problem solving. Seems the monkeys were much better problem solver's than the scientist thought they should be. This 1949 experiment is explained as the early understanding of motivation. At the time there were two main drivers of motivation: biological & external influences. Harry F. Harlow defines the third drive in a novel theory: "The performance of the task provided intrinsic reward" (p 3). This is Dan Pink's M…

Have you ever been in a situation where you thought the technique needed to move forward was one thing, yet the person leading (your leader) assumed something else was what was needed? Did you feel misaligned, unheard, marginalized? Would you believe that 54% of all leaders only use ONE style of leadership - regardless of the situation? Does that one style of leading work well for the many levels of development we see on a team?

Perhaps your team should investigate one of the most widely used leadership models in the world ("used to train over 5 million managers in the world’s most respected organizations"). And it's not just for the leaders. The training is most effective when everyone receives the training and uses the model. The use of a ubiquitous language on your team is a collaboration accelerator. When everyone is using the same mental model, speaking the same vernacular hours of frustration and discussion may be curtailed, and alignment achieved, outcomes …

Popular Topics

Assuming you are on a Scrum/Agile software development team, then one of the first 'working agreements' you have created with your team is a 'Definition of Done' - right?

Oh - you don't have a definition of what aspects a user story that is done will exhibit. Well then, you need to create a list of attributes of a done story. One way to do this would be to Google 'definition of done' ... here let me do that for you: http://tinyurl.com/3br9o6n. Then you could just use someone else's definition - there DONE!

But that would be cheating -- right? It is not the artifact - the list of done criteria, that is important for your team - it is the act of doing it for themselves, it is that shared understanding of having a debate over some of the gray areas that create a true working agreement. If some of the team believes that a story being done means that there can be no bugs found in the code - but some believe that there can be some minor issues - well, then yo…

I’ve noticed a new trend—people have been gaining titles. When I was younger, only doctors had initials (like MD) after their names. I always figured that was because society held doctors, and sometime priests (OFM) in such high regard that we wanted to point out their higher learning. I hope it was to encourage others to apply themselves in school and become doctors also. Could it have been boastful?

The Wikipedia describes these “post-nominal initials”:Post-nominal letters, also called post-nominal initials, are letters placed after the name of a person to indicate that the individual holds a position, educational degree, accreditation, office, or honor. An individual may use several different sets of post-nominal letters. The order in which these are listed after a name is based on the order of precedence and category of the order.
That’s good enough for me.
So I ask you: is the use of CSM or CSP an appropriate use of post-nominal initials?
If your not an agilista, you may wonder …

Amazon book order
What I notice first and really like is the subtle implication in the shadow of the "i" in Drive is a person taking one step in a running motion. This brings to mind the old saying - "there is no I in TEAM". There is however a ME in TEAM, and there is an I in DRIVE. And when one talks about motivating a team or an individual - it all starts with - what's in it for me.

Introduction

Pink starts with an early experiment with monkeys on problem solving. Seems the monkeys were much better problem solver's than the scientist thought they should be. This 1949 experiment is explained as the early understanding of motivation. At the time there were two main drivers of motivation: biological & external influences. Harry F. Harlow defines the third drive in a novel theory: "The performance of the task provided intrinsic reward" (p 3). This is Dan Pink's M…

Have you ever been in a situation where you thought the technique needed to move forward was one thing, yet the person leading (your leader) assumed something else was what was needed? Did you feel misaligned, unheard, marginalized? Would you believe that 54% of all leaders only use ONE style of leadership - regardless of the situation? Does that one style of leading work well for the many levels of development we see on a team?

Perhaps your team should investigate one of the most widely used leadership models in the world ("used to train over 5 million managers in the world’s most respected organizations"). And it's not just for the leaders. The training is most effective when everyone receives the training and uses the model. The use of a ubiquitous language on your team is a collaboration accelerator. When everyone is using the same mental model, speaking the same vernacular hours of frustration and discussion may be curtailed, and alignment achieved, outcomes …