As the CIO of your company, your careful planning enables you to successfully manage the ongoing costs of the physical technological infrastructure (e.g. computers, networks). For months or even 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 system implementations, but it’s not working now that development has branched into custom solutions to capitalize on your wisdom of how your business functions.
Now your company is going to change one or more key subsystems, and this time the development work is going to be done 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 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 it’s usually you. If your SLAs 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, and 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-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.
With regard to the first requirement listed above, 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 in the long term, even with clear specifications and SLAs, success is likely unattainable on anything longer than a three-month project.
As to the second point, maintaining corporate structures and competencies is also a requirement, and fortunately, a fairly clear-cut one. Current organizational management theories abound. Most will work in a software development organization.
In regard to creating the physical infrastructure to receive the assets from the outsource company, that is for the most part a simple matter of money. Receiving the intellectual components, software, procedures, and business knowledge is a matter of imagination and creativity.
Finally, with regard to restructuring assets, in all probability the 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 they did it that way, can lead to processes and practices that run 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 its clients and partners. You must also clearly understand and communicate customer-service expectations to and from each group.
CORPORATE CULTURE MUST REFLECT YOUR GOALS
The most aggressive choice you will make is whether the culture you are building will include a project-oriented or product-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.
Sequencing of feature delivery is, however, 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 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 favour: the Software Development Life Cycle (SDLC) and the Hand-Made Life Cycle.
The Software Development Life Cycle is the most common methodology for developing software and for running projects. It is akin to an assembly-line approach to building cars, wherein each person is responsible for one specific part or function. This methodology generally requires lower technical skill levels and higher managerial and communication skills. It has a tendency to result 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 akin to the type of car manufacturing wherein 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 overly bound to their systems to the exclusion of new ideas, methodologies, and opportunities.
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 rigidly tied to any one methodology.
SUMMING IT ALL UP
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 this 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.
Randall Becker is CEO of Nexbridge Inc., a company specializing in product management consulting and change mentoring to the high-tech community. His e-mail address is rsbecker@nexbridge.com.
