Little Practical Guide
to
Outsourcing
Software Development Projects
Axel Vanhooren
More and more projects are outsourced. It can be done
onsite or offsite, be it as a onshore, nearshore or offshore project. This tactic can reduce the cost. But outsourced
projects require a much better preparation and more formalism. Since more
people are working on this type of project, more coordination is needed. Outsourced projects are more complex, larger and
riskier than when they would have executed in-house.
Taking the decision for outsourcing a software development
project has more consequences for the client company or client organisation.
The decision is not straightforward at all. In essence, four
aspects play a major role in the decision
·
Financial
aspects
·
Practical
implications for the company/organisation
·
Ability
to set-up and manage offshore projects
·
The
offshore software supplier
·
The
type of project
Why doing
outsourcing?
Cost Reduction
Probably the most cited argument is cost reduction. Achieving a cost reduction may be not as easy.
It doesn’t come down to take the plan of the project as if it was executed
in-house or on-shore and using local salaries, local hiring fees and a supplier
margin to compute the cost benefit. The reason for this is that outsourced
projects have other requirements than in-house executed projects.
We need to consider that software development projects shouldn’t
be managed as a cost, but as an investment. During the lifecycle of a software
system, we need to look continuously on how to maximise its value for the
company. And, the cost of the project that created the software is a fraction
of the total cost of the software system’s life. Yet, during this project a lot
of important decisions are taken concerning the scope, the purpose, the
architecture, the design and the technologies. They have a great impact upon
the future life of the system. They determine whether the system can respond to
opportunities and at what cost. It determines how well it can evolve and thus
influence the duration of its life. This project defines the basis of the
further lifetime of the software system and influences thus the profitability
of the system.
Other
Reasons
Although the cost is the most cited reason, it may be not the
real reason. Or, other reasons may play a role as well: understaffed IT
department, lack of IT competencies, lack of trust in the IT department, a
consumer’s attitude (preference for solution acquisition over doing the effort
of solving problems), and so on.
The strategy to reduce drastic the internal IT department is
highly questionable. Competencies in implementing changes, problem solving
skills, project management skills, IT competencies and the capability to
innovate and to renew itself are vital to organisations or companies. The
importance of these skills depends, among other, of the size of the
organisation.
Such reasons are symptoms of a very deep and serious issue
that will threaten the company or organisation over time.
Good reasons are indeed the cost reduction, keeping the focus
on the company’s core activities and vital systems, freeing most capable
resources to work on essential projects, using faster knowledge the company
doesn’t master yet, temporarily having more IT people working for the company
(hiring external consultants is an alternative) and transfer of some risks.
These are probably not the only reasons.
Implications
of outsourcing
Outsourcing a software project can be interesting, but it has
some implications.
·
During
the outsourcing of the construction of a software system, information is passed
to the software company. Information is spread outside the organisation.
o
Information
about the way the business operates and how it is managed. It gives some
insight in the processes, the logic, the available information, the services, and
so on.
o
Projects
are a way to transform a company. Projects give some clue about the company’s
strategy, its intentions and its focus.
o
It
may give indications to the outside world, or at least to the software company,
how well the organisation is able to manage projects, and thus its capability
to evolve and to transform itself.
·
The
client organisation loses some control over its own systems and processes.
Usually, the knowledge about a system developed through outsourcing is smaller
than about in-house developed systems.
·
Outsourcing
a project provides some power to the software company. The software company that
built the built software system has more knowledge of that system than the client
company does.
·
The
organisation may become dependent of external providers.
Consequently, as a general rule, outsourcing strategic
projects - projects that determine the position of the company/organisation in
the years to come -, systems dealing with core processes or systems containing
critical logic should not be outsourced.
Outsourcing all the systems containing the core processes of
business or outsourcing a major part of the systems is a very risky strategy.
The lesser knowledge the organisation has over its system,
the greater is dependency of the software company(/-ies), the more it is
vulnerable.
Who can do
outsourcing?
The IT department has to decide whether it outsources or not
a project. This department is responsible for the automation of the processing
of information within the company or organisation. They are also responsible
for the implemented systems. If the business community starts to define and
build information systems, whatever the way they choose, they engage in shadow
IT. This undermines the information processing within the company, the ability
of the IT department to take up its responsibilities and to play its role
fully, and, ultimately, it will undermine the company.
Selection
of the offshore software supplier
Selecting the right software supplier is a crucial step.
Establishing the required criteria and doing research may help. The software
supplier should preferably have experience in the technologies expected to be
used, in similar projects, in outsourcing or offshore projects and in similar
methodologies as those used by the client’s organisation. The availability of
sufficient resources is another factor that may be considered. Guides about the
selection of IT suppliers can be found on the web.
What phases
of a project can be outsourced?
Analysis
Analysis activities can be outsourced. This includes the
elaboration of business case or any other type of preliminary analysis. It is
favourable, but not mandatory, that the analyst knows the business area and the
company. Actually, some consider not knowing the business domain or the company
as an advantage. Their arguments are valid as well.
However, it is easier when the analyst can talk with many
different stakeholders, organise interviews and workshops. It is very helpful
that he or she is present on the premises of the company. Analysis is about acquiring
knowledge and insight. The company pays an external person to learn to know the
situation within the company. Later this new insight should preferably be
transferred again to an employee.
The client organisation and the software supplier have a common
goal until the contract is signed. But once the contract is signed, game can be
different. The client desires as much value at the lowest cost and with the
lowest risks and without glitches. And some suppliers may want to deliver the
minimum that still matches the agreement and this at the least effort. Both
want the project to be finished as soon as possible, but for different reasons.
The analysis may be too superficial, incomplete, ambiguous,
inconsistent or wrong. Or it may respond to only a part of the needs or even to
the wrong needs. If the agreement is based on this analysis, in the end, the
supplier delivering the solution that matches the agreement will be paid. But
the client will have to face the troubles and the higher cost. An inappropriate
analysis creates disappointment on the client’s side.
Outsourcing projects require analysis that are more complete,
consistent, unambiguous and more detailed.
It is a prerequisite that the product to be developed is well
defined. A fairly higher degree of precision and certainty makes the project
easier. Changes are possible, but they may be more difficult or costly to
achieve.
A good analysis is thus critical and should be conducted by a
professional analyst. This can be an employee or an external and impartial
consultant.
Design
The design is easier to be outsourced than the analysis.
However, the company should ensure some things:
·
the
design matches the analysis, fit the situation and solve the real problems and
needs
·
the
design must lead to an efficient functioning system
·
the
required system’s qualities are built-in by design
·
the
company understands the design thoroughly
Although, the design can be done by the partner, the company
should master the design. A close follow-up is important. The design
determines, for example, the scalability, the expandability and the flexibility
of the system. A bad design may make the maintenance costly, making changes so
hard that the company cannot make use of some opportunities, or may increase
the cost of future changes.
Programming
and Testing
Programming and testing are the phases that are the most
easily outsourced.
It is beneficial that the software supplier follows coding
policies of the client company and that the software code is well-structured,
clean and efficient.
The client organisation should test the software when
delivered. These tests should be more through than simple UAT’s. In the end,
the client organisation is responsible for putting a software system in
production. This means that outsourced software is tested several times. It is
first tested by the supplier to ensure it does deliver working software that
matches the demand. A part is retested as part of the UAT. It is advised to test the software one more
time by the client to verify and confirm it is working well and can be released
to the production.
Delivery
The delivery phase includes the handing over of software and
documentation. But, at least as important, is the assurance that a maximum of
knowledge about the delivered software is transferred. Without this knowledge,
the delivered software is nothing more than a black box of which the
functioning is assumed to be as described in the requirements or is guessed.
Project
Organisation
The company should follow up the project, ensure the analysis
activities, verify the design and establish, execute and verify testing
activities. This means that the company should appoint persons to these roles.
The software supplier is likely to have the same roles in his part of the
project.
Responsibility
of the company
The client company’s has to ensure that the project delivers
a product that corresponds to its needs. That is its main responsibility. In
the beginning of the project, the client company is responsible for the correct
identification of the needs. During the execution of the outsourced activities,
the client organisation must ensure the product the software supplier is
building corresponds to what is agreed and suits the client organisation. And
upon delivery, the client organisation is responsible for the hand over, for
the acceptance, for further testing, for the implementation and for the
transition. There might be some nuances in this list of responsibilities depending
on the specific situation and agreements.
The outsourced activities can be considered as a sub-project within
an overarching project. The company is responsible for organising this
overarching project and organisation. Even though the sub-project is managed by
the software supplier, the client company should follow up and control the work
done by the software supplier.
Follow-up,
Control and Transition
The outsourced project must be followed-up and controlled by
project manager, analysts, architects and possibly some other roles assigned on
the client-side of the project. This follow-up doesn’t concern the quality of
the activity plan, the progress of the outsourced project or its resource usage.
It is much more important to verify that the requirements are well rightly
taken into account in the design, the suitability of the design, and so on. The
software product should not be a black box. It should be at least a grey box.
The client, and more particularly, its IT department, needs to know the
architecture, the implemented mechanisms, the organisation of the source code,
and so on. This is about the understanding of what have been established before
programming, or in terms of layers of detail, the layer just above the source
code. The client should have and should validate the analysis and design
artefacts made by the software supplier.
Essential
aspects
There are some factors that require much more attention in
off-shore projects:
·
An
analysis of high quality
·
A
higher degree of formalism
·
Good
agreements will avoid many misunderstandings, wrong assumptions, discussions
and disappointments.
·
More
and effective communication
·
An
efficient way to follow-up the project
·
Good
testing
A few
issues to consider
Some issues are important to consider:
·
How
does the software company react when there is a doubt about the specifications?
·
What
are the agreements about handling changes of requirements or specifications
during the project execution?
·
Is
the software supplier ready and able to follow the client’s coding standards
and quality levels? How is this process
of transferring, using these standards and the control of their compliancy organised?
This includes documentation standards.
·
How
is the integration of the new system in the existing IT environment solved?
·
How
much knowledge of the delivered system is transferred and how is this organised?
·
What
support may be needed and what can still be expected from the software supplier
months or years after the product has been delivered?
Cultural Differences
There are differences among developers. When specifications
aren’t clear for the developer, developers may react in different ways. Some
will stop working, others will interpret the specifications without caring,
others will try to understand the purpose and guess for the right
interpretation and others will ask for clarification. There are differences among
the company cultures. There are differences among the clients and the
suppliers. With offshore projects, the cultural differences are even greater when
the parties are from distant countries. Additionally, the most obvious practical
barriers are the distance, the language and the time zones. And maybe the legal
differences play a role as well. This makes offshore projects more complex.
Anecdote: An offshore software supplier had delivered
demanded software and was partying. The client was testing the software and
found a few hundreds bugs. They called the software supplier to ask for
explanation. “We are testing the software you delivered and we found 300 bugs in
it. This is inadmissible. The contract stipulates that you would test the
software before delivery.” Software supplier: “You found only 300 bugs. We tested
it as agreed and found around 800 bugs. So, you still have 500 bugs to find.
Good luck.”
Starting
with outsourcing
Knowledge and experience in outsourcing projects can be built
up gradually.
There is a lot to learn of the experience of other’s offshore
project. Much can be learned from failed projects. There is plenty information
on the web.
An evaluation of the present capability in managing and
executing software development projects is a key to first consolidate or
strengthen this capability before engaging in outsourcing.
Nearshore is somewhat safer than offshore projects. Small and
non-vital projects are better candidates to begin with. Gradually larger
projects can be outsourced.
Good Luck with your projects!
Other Resources
Outsourcing Management Body of Knowledge
(OMBOK)™
URL: http://int-iom.org/documents/OMBOK.pdf
IAOP - International Association of Outsourcing
Professionals
URL: http://www.iaop.org/
IAOP - Outsourcing Professional Body of
Knowledge™ (OPBOK)
Keywords: software development, project, outsource, outsourcing, onsite, offsite, onshore, nearshore, offshore, project management, CIO, strategy, IT strategy, shadow IT, ERP, IT department
©2013 by Axel Vanhooren. All rights reserved
