Outsourcing the Enterprise Development Project

PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The
reader is available for free
download.

Outsourcing the
Enterprise Development Project

by James G. Barr

Docid: 00018392

Publication Date: 2201

Report Type: TUTORIAL

Preview

In these days of tight deadlines and over-pruned IT departments, large
enterprise development projects can suffer. Under-resourced development
organizations may not be able to cope in a timely manner with everything asked of them. That is where outsourcing comes in.
It can allow a company
to achieve its development goals without over-extending existing
development staff or having to significantly upsize the department for the
duration of a project. There are, however, risks involved in outsourcing.
This report examines those risks and offers best practices to mitigate
them.

Executive Summary

[return to top of this
report]

The purpose of outsourcing is to delegate specific functional
responsibilities, such as application development, to a trusted
third-party, ostensibly an organization experienced in conducting the
assigned functions. This allows the client company to concentrate on its
core competencies. A publishing firm, for example, could focus on its
primary expertise, publishing, while transferring the responsibilities
(and, in theory, the headaches) associated with application development to
a company that specializes in application development.

While there are often clear benefits to outsourcing, a company
considering such an arrangement should be careful to exercise due
diligence in selecting an outsourcing partner, and in monitoring and
managing the outsourcing relationship.

The promise of cost savings is very realistic with the emergence of
world-class service providers both at home and offshore, but only if the
outsourcer is properly chosen and managed.

As outsourcing becomes the norm it will be increasingly common for
companies to rely on multiple external service providers. This brings
greater complexity and a need for proper investment in capable in-house
management. It is more important than ever that management plan, organize
and control all aspects of the enterprise in the new virtual organization.
The viability and success of outsourcing as a business strategy ultimately
depends on the management of the entire process.

For their part, outsourcing firms must cooperate with their enterprise
clients to help the chief information officer (CIO) and other enterprise
officials align development efforts with enterprise business goals and
objectives. This will require that outsourcing vendors in general – and
application outsourcing vendors in particular – retool their processes and
methods in order to measure and substantiate an outsourcing solution’s
business value – a level of partner investment that extends beyond simply
lowering development costs.¹

Description

[return to top of this
report]

Before we discuss the how and why of outsourcing an enterprise
development project, it is important to make the distinction between
outsourcing and a related service, “resourcing.” Within the application
development context, resourcing is hiring a programmer/consultant to work
within the organization’s IT department. Outsourcing is transferring the
day-to-day responsibility for managing application development (or for
managing the development of a specific application) to an outside
provider, for example, a large-scale provider such as IBM, as well as
small-scale providers, such as local application development shops.

In many respects, all outsourcing contracts are similar, regardless of
the business functions being outsourced. The same basic process used to
outsource an enterprise development project may be used to outsource call
center operations or to outsource network management functions. The
process entails the following five steps:

Defining the project requirements
Identifying potential outsourcing candidates
Selecting an outsourcing firm
Establishing a service level agreement
Managing the outsourcer (through the lifecycle of the project)

Defining the Project Requirements

Many firms with a history of internal application development use a
process of “rolling requirements,” allowing projects to be initiated with
incomplete specifications or specifications that are subject to change.
Although no one officially endorses this form of project management, the
practice is common and the associated overhead cost is absorbed as
internal costs. When using an outsourced application development firm,
each of these changes will incur changes in project cost and schedule,
with the majority leading to increased cost and project delays. To reduce
the probability and impact of these changes, it is important to produce
complete and comprehensive requirements documents before development
begins.

Many projects simply cannot be fully specified prior to starting
development. In these situations, it is important to choose an outsourced
application development partner that can work effectively and efficiently
using an interactive development model. Projects that are developed in
this manner offer the advantage of developing necessary features as they
become known, with the disadvantage that the overall cost and time to
develop will not be accurately predicted at the outset of the project.
This outsourcing model is not very different from standard models other
than the fact that it accepts and incorporates the realities of enterprise
application development.

Mobile and web-based projects are commonly outsourced enterprise
application development projects today. The nature of this type of
outsourced application development is subtly different than other kinds of
outsourced enterprise application development. Outsourced these projects
require that a client be more involved with the outsourcing firm to
provide necessary input, such as content, in a timely fashion. The overall
success or failure of the project is often determined by a client’s level
of involvement with its outsourcing firm.

Identifying Potential Outsourcing Candidates

The best method for identifying potential outsourcing firms is word of
mouth. For a firm involved in manufacturing, for example, it might be
prudent to seek the advice of other manufacturers. This does not mean that
an auto manufacturer should approach other car makers (in fact, it is
probably unwise to accept a competitor’s recommendation). It means looking
for manufacturers of similar size, and with similar IT infrastructures,
and soliciting their suggestions. Other word-of-mouth sources include IT
user groups and trade and professional organizations.

At some point a decision will have to be taken as to whether or not to
consider outsourcing to offshore service providers. While potential cost
savings of up to 80 percent on labor (though this figure has diminished as
offshore labor costs increase) are attractive, management needs to
consider the political implications of sending work offshore as well as
the new complexities brought on by cultural differences, language
challenges, foreign laws and a different time zone.

Selecting an Outsourcing Firm

After identifying three or four potential outsourcing partners, the next
step is to narrow the field to one. As a barometer for making the
selection, develop a request for proposal (RFP), asking each candidate
company to respond. The RFP should focus heavily on experience-related
factors, such as:

Application development experience
Industry experience
Similar customer experience
Years of experience
Client references

No matter how impressive their other credentials, allowing a new – and
relatively immature – IT services firm to “cut its outsourcing teeth” on a
major enterprise project is dangerous. In addition, the larger the
project, the more critical it is to carefully check the outsourcer’s
references.

Governance

One increasingly important consideration in selecting an outsourcing firm
is its commitment to IT and security governance, which is also a good
predictor of the firm’s commitment to best practices.

From an IT governance perspective, an outsourcing firm should embrace a
standard such as:

ITIL, the IT Infrastructure Library
COBIT, Control OBjectives for Information and related
Technology

From a security viewpoint, the firm should endorse, at minimum:

ISO/IEC 27001:2013: Information technology – Security
techniques – Information security management systems – Requirements
ISO/IEC 27002:2013: Information technology –
Security techniques – Code of practice for information security
management

Apart from helping to ensure that third-party development efforts are
conducted to the highest standards, the attention to governance,
especially IT governance, will improve the prospects for application
integration and “disintegration” – in the latter case, helping to ensure
that new applications can be successfully “reverted”, or backed out,
without compromising the integrity of existing enterprise information
systems or enterprise information.

Establishing a Service Level Agreement

Once the outsourcer is selected and a project plan developed, a service
level agreement (SLA) must be negotiated. The SLA spells out the
relationship between the client and the outsourcing firm. The key
components of an SLA include:

A List of Deliverables – To ensure that a project is
on schedule, each of the project milestones should be marked by a
specific deliverable, a discrete result that can be observed and
measured by the client. For example, if the project involves developing
a Web interface that permits business partners to access the client’s
legacy data, one deliverable might be the Web interface itself. In any
event, deliverables are the primary measures of project progress and
must be administered through the SLA.
Application Performance Requirements –
Customer-facing enterprise applications need to be available 24/7, and
remain responsive at all times. An application that needs frequent
offline maintenance or is subject to periodic processing delays cannot
adequately meet the requirements of its end users. Therefore, it is
important to specify what the desired performance requirements are for
each deliverable in the project. These requirements can be expressed in
terms of availability, responsiveness, and acceptable latency
thresholds.
A Problem Management Protocol – Whether an enterprise
project is developed internally or via an outsourcer, problems will
occur. While most minor problems can be handled informally (usually
between the outsourcing team and the client’s IT staff), there must be
provisions within the SLA for first reporting, and then escalating,
major problems – problems with the potential to impact the project
budget or the project schedule.
A Change Management Protocol – While the outsourcing
process places a premium on firm and unchanging requirements, in the
real world, changes often become necessary, particularly if those
changes are related to changing business conditions, as reflected by
mergers, acquisitions, divestitures, new business partner alignments,
the modification of existing product lines, or the development of new
products. The SLA should provide a procedure for evaluating such
changes, and for incorporating them within the “evolving” enterprise
project.
A “Malpractice” Provision – As a matter of insurance,
the SLA should provide for specific remedies in the event of poor
outsourcer performance, including a waiver of outsourcing fees,
reimbursement of any financial losses suffered by the client, and the
assumption of additional outsourcing (or other responsibilities) as a
means of compensation, i.e., “freebies.” The contract should also
have a clearly delineated process for termination of the relationship,
should it become necessary.

Managing the Outsourcer

Once a project has been outsourced, the client’s involvement with the
project does not end. Negotiating an SLA does not remove the client’s need
to participate in the project. The outsourced project must be managed by
the client on a regular basis, and with particular attention to
intermediate project deliverables. The outsourced application developer
will be responsible for day-to-day management functions, while the client
needs to ensure that medium-term and long-term goals are being achieved,
and that scope creep is not introduced, increasing costs and interfering
with timing.

It also makes sense to involve internal and external stakeholders who
will use or derive benefits from the project. Vesting the entire oversight
function within the client’s IT department (or other similar
administrative unit) is both unfair and unproductive. Although the
client’s IT staff may have a role in the outsourced project, the IT staff
usually does not have the specialized domain expertise needed to ensure
that the overall goals of the project are being met. While it may not be
possible in all cases, exposing an application under development to one or
more of its prospective users might help reveal some problems, which would
otherwise remain hidden until production.

Clients need to be involved with more than just negotiating an
outsourcing agreement and regular management of the outsourcer. Many
outsourced enterprise development projects require regular input from the
client, from supplying content to clarifying aspects of the client’s
business to the outsourcer. Failure to provide this information to the
outsourcer can lead to unnecessary delays and cost overruns in the
project. In extreme cases, a client’s failure to be involved with an
outsourced project will doom the project, leading to wasted time, money,
and effort for all parties.

Current View

[return to top of this
report]

In an outsourced application development project, the role of the client
is to specify what needs to be developed; the role of the outsourcer,
however, is to determine how to develop the solution for the client. Once
the project is complete, the application will then be deployed by the
client to solve a pressing need in the organization.

Consequently, the success of the outsourcing relationship depends on the
ability of the in-house IT department to communicate effectively with the
outsourcer both during the lifetime of the project and after the delivery
of the newly developed application. Furthermore, the in-house team needs
to be able to quickly come to grips with the new application. For these
reasons the choice of software tools used to develop the application is an
important consideration.

The outsourced development team may choose to use standard software
development tools, internally developed proprietary tools, or boutique
tools that are used by a small population of developers. Each choice has
benefits and drawbacks, both in terms of the ability to deliver a
solution, and in the nature of the solution that is delivered.

An outsourced team may dedicate itself to a specific type of project,
such as content management systems, e-commerce applications, database
publishing, or human resources management. By focusing on a single problem
domain, it can amplify its effectiveness by developing customized tools
for developing one type of application, thus speeding the development of
each project. The benefit to this approach for the client is easy to
understand: quicker time to market at a lower project cost. The drawbacks
are a little more difficult to see. Once the application has been
developed, it will need to be supported and maintained on the client’s
network. If the client’s IT staff is unskilled in the use and maintenance
of these specialized tools, the benefits achieved through quick
development will be significantly offset by the cost to deploy the final
application. These costs can be expressed through additional hardware
purchases, software licensing, training, and extended periods of downtime
when something goes wrong because of lack of familiarity with the
development tools.

A similar situation may occur when the outsourced development team
chooses to use a boutique set of tools to develop the application. Because
these tools are used by a larger number of people than just the outsourced
team, the risks are reduced, while many of the benefits remain. The risk,
however, remains that a system developed with a niche tool will not be
able to be supported by the IT staff once the application is deployed, and
a very small number of people will be available to maintain and extend the
system.

The third alternative is to specify that the outsourced development team
use a standard set of tools to develop the enterprise application under
consideration. The client can be liberal and accept a wide variety of
tools that the outsourced team may use, or it can be rigid and specify
which particular tools are acceptable. Here, the requirements are designed
to reduce the risks that may occur when using less standard application
development tools, but they inadvertently increase the risks in the
process of system development. For example, the client may choose one
specific tool or a set of acceptable tools that are supported by the
internal IT staff, yet are wholly unsuitable for developing the
application being specified. Demands like this have proven to be
disastrous. On the other hand, allowing the outsourced development team to
choose the best possible set of tools that can be supported by the
internal IT staff reduces overall project risk, even if the time to market
may be slightly greater.

Whichever tools are selected should conform to general application
development standards. Neither the outsourcer nor the client IT department
should be empowered to experiment at enterprise expense.

Because outsourced applications are built without internal IT resources,
it is critical that these applications be subjected to a security audit to
ensure that they will not compromise corporate services or sensitive data.
Otherwise, outsourced applications could be deployed with unknown security
bugs, with unknown severities, and internal IT resources who lack
familiarity with the application code would be unable to perform a
suitable fix in a quick and responsive manner.

Outlook

[return to top of this
report]

There are a number of issues that must be considered in order to make
sure that an outsourcing project is successful both during and after the
completion of the project.

Back Doors

Occasionally, some programmers will create “back doors,” or secret access
points into an application that are expressly designed to circumvent
normal security and allow the developer unfettered access to an
application, even after the application has reached production status.
Although these entry points can be designed to be used for benign
processes, such as debugging, they can also be used or abused for sabotage
or corporate espionage, or exploited by hackers to compromise an
organization. Reducing this kind of exposure requires cooperation between
the client and the outsourcer, beginning with a frank discussion of client
risk and outsourcer liability. For sensitive applications, it would be
prudent to have a third party conduct an audit of the code to ensure there
are no unknown access points to the program, as well as ensuring that the
contract is clear on this point.

Security

In large applications, the potential for bugs is great, including severe
bugs that can compromise the security of a system. Security bugs are
errors that can be used by an attacker to gain unauthorized access to a
system. Security bugs tend to occur in all large systems, unless measures
are taken to prevent them from occurring in the first place.

Some security bugs are inherent in a system design, and are both
difficult and costly to fix. Others are more mundane, often the result of
sloppy coding practices or inadequate testing, yet can lead to costly
system compromises when exploited. Still others are inherent in the
development tools and/or deployment environment, and must be addressed by
regular attention to vendor patches. Regardless of the cause, an attacker
who exploits a security bug can gain access to sensitive corporate data,
corrupt the application, or compromise the computers and the network
hosting the application.

Because security bugs are likely to occur in every large application, it
is important to take an active role in finding and eradicating these bugs.
The best approach to finding and removing security bugs (as well as back
doors) before the application is compromised is to first prioritize
security and privacy in the application design, and to undertake a
security audit of the application’s source code once it is written. This
will involve an agreement with the outsourcing firm to provide the source
code for the application, so that it may be audited; indeed, the customer
should always have the current source code in any case, and the contract
should assert its ownership of it. Large and important enterprise
applications should not be deployed until they have been subjected to a
security audit, either by the internal IT department or an outsourced
security auditing firm. Security audits should always be performed by an
external group, and never by the team responsible for implementing an
application.

For even greater protection, outsourced applications should be subjected
to “penetration” testing, simulated attack scenarios in which “ethical
hackers” attempt to breach application – and overall system – security.

Privacy

Privacy legislation such as the European Union’s (EU’s) General Data
Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA)
demand that personally identifiable information (PII) be well
protected and only used within certain parameters, with significant
penalties for breaches. Any application that collects or uses information
in this category (which is broadly defined – it can even include an IP
address in some cases) must be carefully designed and audited, as should
any back-end processes using the information collected. Note that an
application can be secure and still not adequately protect personal
information, thus the two issues of privacy and security should be
considered separately.

Transition

Once an enterprise development project is complete, the resultant
application (or applications) must be turned over to enterprise personnel
for deployment. This post-development phase involves issues related to
training, program maintenance and testing, and program integration, items
that together may rival the actual development in terms of time and money.
Before entering into any development arrangement, it is critical that the
enterprise client evaluate the whole project, including the
post-outsourcer component.

Long Term Support

Most enterprise application development projects are never truly
completed. Rather, they are continuously developed, extended, and
enhanced. The team that developed an application is often the best
candidate to produce subsequent releases. When a large enterprise
application has been developed by an outsourced team, it is not always
appropriate or practical to expect an internal team to make subsequent
changes. In these cases, it may be necessary and desirable to retain an
outsourced development team to provide long-term application development
after the scope of the original project is complete. In any case, the
contract should specify that the application code be extensively
documented, so new members of the development staff can get up to speed.
Customer ownership of the code must also be clearly defined in the
contract, and current source code must be available to the customer at all
times, to avoid risk in the event of a falling-out with the outsourcer, or
in case the outsourcer ceases to exist.

COVID-19 Considerations

Now entering its third year. the COVID-19 pandemic has changed the nature
of enterprise operations:

Producing a more distributed workforce whose members collaborate
electronically rather than in person; and
Affecting the availability of key personnel due to illness or
quarantine.

While the window of observation is small, the process of selecting an
outsourcer should include contacting their recent clients (from 2020 and
2021) to ascertain how the firm adapted to frequently-shifting pandemic
conditions, and, going forward, whether the firm has developed a COVID-19
“game plan.”

Recommendations

[return to top of this
report]

Exercise Caution When Outsourcing

Henry Martinez of Tiempo Development emphasizes the importance of
outsourcing the right projects to the right firms.

For
strategic
projects (or projects designed to create a
sustainable competitive advantage), partner with companies in countries
with strong intellectual property (IP) laws, and take extra precautions to
safeguard sensitive information.

For
tactical
projects, select a partner capable of assuming
greater responsibilities (including decision-making and project hand-offs)
if local IT staff become consumed with other duties, like maintaining
existing products and services.²

Endeavor to Mitigate Risks

A study of 50 outsourcing deals, conducted by French academic Jerome
Barthelemy and reported in the MIT Sloan Management Review,³ reveals that
many companies are unaware of the potential risks involved with
outsourcing. To help mitigate these risks, Barthelemy recommends the
following:

Spend more time researching vendors
Hire managers with outsourcing experience

Also keep in mind why you are outsourcing a particular development
project. Good candidate projects are ones where the internal development
department has insufficient personnel, insufficient expertise, or
insufficient capacity. Remember that outsourced projects still need
management during the project to ensure success. Projects where the
outsourced application development team is simply handed a list of
features to implement and an expected delivery date are not good
outsourcing candidates.

It is also important to consider how the application will be deployed
once it is developed. There should first be a mandatory security audit,
and the internal IT staff that will deploy the application should be well
trained in maintaining it. Documentation should be complete and clear, and
up-to-date source code must be available to the customer. If the
application will need to be extended after the development phase is
complete, then it is important to find an outsourced development team that
can develop your application using tools that your internal IT staff uses
or can learn to use. Failing that, it may be necessary to consider
retaining an outsourced development team to build subsequent versions of
your application. If that is the case, there will be budgetary
considerations that should be defined up front. Again, documentation is
key.

Remember that the quality of the final product will be influenced by the
entire process. Therefore, if application performance is critical, then it
must be incorporated into the project as early as possible, and ideally
specified in the SLA. Once an application is developed, it will be very
difficult to remedy issues of poor performance caused by factors such as
high latency or frequent periods of mandatory downtime. The same caveats
apply to security and privacy; they must be designed into the application,
not tacked on.

Outsourcing carries certain risks in the form of hidden costs. These
risks are magnified when poorly designed contracts are drawn up, when
inadequately defined requirements dominate the SLA and when a deal puts
pressure on the outsourcer to cut costs, thereby affecting the quality of
the outsourced work. It is all too easy to omit clauses defining ownership
of the source code as resting with the customer, not the outsourcer,
leading to the potential for situations in which the product is
effectively held for ransom by an outsourcer asserting code ownership, or,
worse yet, the customer being abandoned when the outsourcer disappears or
is fired, taking the code with it. The best remedy for these issues is to
ensure there is adequate investment in in-house management. A commitment
to putting in place capable management will lead to far better control of
the service provider, better ongoing management of overheads and,
crucially, control over the IT destiny of the enterprise.

The decision to outsource at home or to use offshore service providers is
an important consideration that requires analysis that goes beyond cost
savings, with political implications at the corporate level and morale
issues within the workforce. It becomes even more critical to properly
address the points already discussed when you factor in the additional
complexities of dealing with an outsourcer operating in a different time
zone and with different cultural norms. The potential for efficiency gains
needs to be offset by the need for capable and ongoing management of the
relationship with the offshore service provider. Solid management will
work diligently to minimize the potential for missed deadlines, quality
issues and hidden costs.

Finally, in a world increasingly dominated by e-commerce, global supply
chains, and other collaborative structures, the success of any enterprise
project – whether outsourced or “insourced” – depends on the participation
of all affected parties, including employees, customers, and business
partners. This involvement starts with planning, and proceeds through
design, development, deployment, and testing – it must be a true
partnership to succeed.

References

¹ Ferenc Szelenyi. “What Does the Future Hold for IT
Application Outsourcing?” Global Services. February 11, 2010.

² “A Strategy for Outsourcing Enterprise Software
Development.” Tiempo Development. March 15, 2021.

³ Jerome Barthelemy. “The Hidden Costs of IT Outsourcing.” MIT Sloan Management Review (Vol. 42, Iss. 3), Spring 2001: 60-69.

Web Links

[return to top of this
report]

International Organization for Standardization (ISO): http://www.iso.org/
US National Institute of Standards and Technology: http://www.nist.gov/

About the Author

[return to top of this
report]

James G. Barr is a leading business continuity analyst
and business writer with more than 40 years’ IT experience. A member of
“Who’s Who in Finance and Industry,” Mr. Barr has designed, developed, and
deployed business continuity plans for a number of Fortune 500 firms. He
is the author of several books, including How to Succeed in Business
BY Really Trying, a member of Faulkner’s Advisory Panel, and a
senior editor for Faulkner’s Security Management Practices.
Mr. Barr can be reached via e-mail at jgbarr@faulkner.com.

[return to top of this
report]