Related Corporate Summary: Being able to manage relationships with out-source companies and handling the retaking of technology, known as back-sourcing are critical to your long-term success and bottom line. How you handle change in these environments determines whether you succeed or fail as a business. Please leave a comment and let us show you how to manage service level agreements with your out-source partners, and how to take back control of your technological assets.

This article has been published in the December 1999 issue of CIO Magazine (Canada) and has been put on this web site with the permission of the copyright holder. The original article, Taking Back What Is Ours, can be obtained found at www.itworldcanada.com
The article is copyright Laurentian Technomedia Inc. (LTI), © 1999. All rights are reserved.
No material from this article may be reproduced electronically or in print without written permission from LTI.
For permission for commercial or educational use of the content of this or any LTI publication, write to:

Editor-in-chief,
LTI,
55 Town Centre Court, Suite #302, Scarborough, Ontario, M1P 4X4.

January 2014 Update: The term back-source used when the article was published has been replaced by Insourcing.

You are the CIO of your company. Your careful planning enables you to successfully manage the ongoing costs of the physical technological infrastructure (telephones, computers, and networks). For months, or years, however, you have watched software development budgets mount while user satisfaction drops and you’re having trouble reconciling the two. Outsourcing worked for a while, during the financial and Enterprise Resource Planning (ERP) system implementations, but it’s not working now that development has branched into custom solutions to deliver on your wisdom on how your business functions. You’ve just told your team that your company is now going to change one or more key subsystems to be developed in-house. This is known as back-sourcing, and it is a growing trend within companies whose primary business is not the development of software. This article lays out some of the key success-related issues you must address to take advantage of this trend.

Why Companies Back-Source

There are three key reasons why companies back-source:

1. To regain architectural control. Architecture defines the framework that structures your software. It provides the context in which future enhancements, growth, and defect corrections are made. Architectural control of your products and services, gives your organization leverage to support change in the long-term.
2. To tighten the ratio of real cost to perceived value. If the service level agreement (SLA) you have with your users and the SLA with your supplier (the outsource company) are in conflict, then chances are someone has a problem – and its usually you. If your service level agreements with your users are already being satisfied, and customer satisfaction is high on an ongoing basis, then your original decision to outsource was a good one – back-sourcing may not substantially contribute to improvements.
3. To remove the conflict between your company’s goals and those of the outsource company. Both companies are in business to make money. Outsource companies, in general, increase their revenue when specifications change. This results in increased costs and delays to you and your users.

What You Need to Do

In order to succeed in back-sourcing development, you are going to need to:

1. Clearly communicate defined corporate goals.
2. Build and maintain corporate structures for personnel and their competencies.
3. Create the technological infrastructure to receive the assets (hardware, software, policies, practices, and procedures) from the outsource company.
4. Restructure those assets to reflect your corporate goals, moving forward.

These are not one of one-time activities or projects. Processes must be developed to continually review, measure, report, and improve in these areas because your corporate goals, underlying support structures, and technology continually evolve.

The Choices to Make

In the IT arena, there is little choice when it comes to clearly communicating corporate goals. If IT does not understand what is expected of it, long term, even with clear specifications and SLAs, success is likely unattainable on anything longer than a 3-month project.

Maintaining corporate structures and competencies is also a requirement and fairly clear-cut. Current organizational management theories abound. Most will work in a software development organization.

Creating the physical infrastructure to receive the assets from the outsource company is a simple matter of money. Receiving the intellectual components, software, procedures, and business knowledge and experience is a matter of imagination and creativity.

Restructuring Assets

In all probability, assets you receive will be structured around a project model. The outsource company will likely have structured their processes and procedures around a traditional software development life cycle (SDLC) model. You are ultimately responsible for ensuring that the processes, procedures, and methodologies reflect your business requirements. Hearing your employees make statements like, “We do it because the outsource company did it that way”, without understanding why, often runs against your priorities and counter to the business plans and expectations. Without that understanding, you can’t make decisions or effect change.

You must also ensure that, in restructuring your assets, you clearly define and communicate the service level agreements in effect between groups in your organization and those between the organization and outside. You must also clearly understand and communicate customer service expectations to and from each group.

Your Own Corporate Culture Must Reflects Your Goals

The most aggressive choice you will make is whether the culture you are building will include a project- orproduct-oriented philosophy. The project-oriented philosophy focuses on the concept of successful delivery by satisfying specifications. Does this sound familiar? It should. It’s exactly the same relationship you had with your outsource company. In order to handle a change in your business, you had to work with the outsource company to make contract changes, roll back the project, rework the delivery dates, and worst of all, possibly invalidate all or part of the set of fundamental assumptions on which the software had been built to that point in the project. This will not change after you take your software back, unless you move to a different philosophy. Until then, you will probably not significantly improve user satisfaction.

The product-oriented philosophy is driven by change. The assumption for virtually all products is that the product life span is not really known. Most often, product life spans are open-ended. The product philosophy assumes that you are building on what previously existed: in this context, the assets taken back from the outsource company. It assumes that you are building towards goals that are defined, not by rigid specification, but by your business plan and service level agreements with your users. The IT organization takes those goals and begins formulating architectures that can adapt to a number of different possible outcomes as defined by those goals. Functionality is specifically delivered within the context of the architectures. Specifications clearly identify what has to be done on a feature-by-feature basis within the architecture, as with a traditional project philosophy. However, sequencing of feature delivery is, as much as practical, kept independent of the specification. All participants, including developers and users, must be accepting of the probability that anything can change based on changing business priorities, including when features are delivered. The objective must always be seen to be Customer Satisfaction. Meeting or exceeding formal SLAs is a major component in achieving that objective. It is not The Objective.

Development Methodologies

When building your IT groups to accommodate the ongoing development and maintenance requirements of your software, you will naturally choose methodologies that reflect your corporate processes and culture. This is another reason why establishing a strong corporate culture is essential. Indecisive management styles and a lack of process will result in either a lack of development methodology, or, a very commonly allowing the development methodology to drive the corporation. The danger of being driven by methodology is that your users and developers could become slaves to the software, instead of the software adapting to meet the corporation’s needs.

The following two methodologies are currently in favor: the Software Development Life Cycle (SDLC) and the Hand-Made Life Cycle.

The Software Development Life Cycle (SDLC) is the most common methodology for developing software and for running projects. It is akin to an assembly line approach to building cars, where each person is responsible for one specific part or function. This methodology generally requires lower technical skill levels and higher managerial and communication skills, results in increased specialization, and often leads to bureaucracy and competency `ghettos’ and resistance to change. Evidence of this includes statements like, “I only do COBOL,” and “I don’t do Windows.”

The Hand-Made Life Cycle, while not generally called such, is used by smaller companies with limited resources. It is also akin to car manufacturing where a small team builds the entire car together. This methodology requires higher skill levels and increased generalization. Productivity is often much higher than with the SDLC methodology, but it is difficult to sustain as people become too bound to their systems to the exclusion of new ideas, methodologies, and opportunities.

The key to choosing a successful development methodology is to set up your organization to allow flexibility based on changing business needs. Your business processes and practices should direct the ongoing choice of methodologies. Avoid being tied to any one methodology with rigidity.

SUMMARY

You are taking back your software in order to achieve architectural control, maximize value for money, and to resolve conflicting objectives. Using a project model, you will not necessarily alleviate the pain your users are experiencing. The users will not see any improvements until your IT department changes the way it works. Users may not identify the architectural control issues as important, but they will complain about value for money and conflicting objectives. In the product model, there is an expected cost per year associated with IT products and services. The value for money is tied directly to the ongoing timeliness of delivery.

In the project model, changing requirements cause most failures. In the product model, change is the reason for the existence of IT. The introduction of new features, capabilities, and requirements is a reflection of the changing business environment. You can either view this as a problem to be contained, or an opportunity to be embraced.