Tuesday, February 10, 2009

Application Outsourcing Services

In tough economic times, businesses have three choices: ignore the situation, accept defeat, or take control. The first two options—doing nothing and riding out the storm or accepting the pounding—can be paralyzing, with devastating consequences. However, by taking control, businesses can stay ahead of competitors, grow market share, and ensure viability in all types of market conditions.

One way to take control is to consider all your options when it comes to your people, your processes, and your technologies. How can you make your people more productive? How can you streamline your business processes to minimize mistakes and maximize efficiency? And what technologies can help you achieve those goals quickly and cost-effectively?

With the evolution of Application Outsourcing services, companies have new choices when it comes to technologies, along with unprecedented opportunities. Instead of buying and setting up an extensive IT infrastructure—servers, networks, security, and licensed software, along with a staff to manage it all—customers who choose to outsourcing there applications management function of their IT department to a Software Outsourcing Company like Symbyo . And instead of the headaches associated with upgrades and new releases, customers simply decide which new features they want to use and take care of all the details. It’s all part of the larger picture of cloud computing pioneered by consumer companies such as Amazon.com and Google, in which people use the computing resources of other companies for their own purposes.

Symbyo Technologies is a pioneer in making this business model available to business users as well.

One of the advantages of cloud computing is that companies can focus on what they do best and on what gives them the most value for the smallest investment. Taking advantage of the cloud is one way to take control because it supports the following basic approaches. These approaches are always important to business success—and in difficult economic times, they’re critical.
:: Executing on business goals in a way that achieves revenue growth, while lowering costs and minimizing risk.
:: A strong commitment to supporting existing customers to expand the user base, ensure loyalty, and turn customers into advocates.
:: Smart and rigorous financial investments that focus on getting up and running quickly, with solutions that are flexible, support managers in making critical decisions, and make life easy for end users.

Within these approaches, there are key strategies for doing more with less, for empowering customers and partners, and for increasing the effectiveness of internal resources such as IT, sales, marketing, and customer service. This article explores how can support these strategies and how companies like yours have used Application Outsourcing to not only survive, but to thrive.

Tuesday, January 27, 2009

Implementation of ITIL-based processes


Overview


Until recently, internal IT departments have been relatively insulated from the corporate concerns of staying ahead of the competition. Certainly, IT has always existed in support of maintaining a competitive advantage, but that support has been largely tactical, given that IT has historically been viewed as a cost center, not a strategic business unit.

Things have changed dramatically in recent years as more and more businesses are moving out of a cost-centric view of IT’s potential — and into a realization that IT can transform business processes. This phenomenon is largely driven by increased competition in the marketplace, and the understanding that moving toward an IT-driven, customer-centric business approach isn’t a luxury — it’s imperative.

IT operations are increasingly expected to operate as a business unit, and with this expectation comes a slew of new challenges: improving performance, reducing operational costs, driving effective organizational change (via new processes and technology) to support IT’s bid to succeed in this new role and demonstrating the business impact of the department.

Yet, how does a legacy IT department transform itself into a business unit capable of delivering proactive, responsive service management across the organization? How does it provide not only the technology, but also the services, budgeting forecasts and metrics required to support the business goals of the company?

Failure can mean IT remains a nonstrategic cost center and its leader — the CIO — has no voice in strategic business decisions, or as is the trend recently, IT is outsourced completely. It’s a case of evolve or die, and the stakes are high for both the department and the organization it supports.

This article discusses how IT can function more effectively as a business unit, by using asset and service management solutions to implement and support IT Infrastructure Library® (ITIL®)-based processes for managing:
  • • Configuration.
  • • Incidents.
  • • Problems.
  • • Change.
  • • Releases.
  • • Service levels.
  • • Availability.
Establish ITIL processes to align IT with business objectives

ITIL provides a nonproprietary, concrete framework for implementing service management best practices that are aligned with overall business objectives. Basing IT processes on ITIL guidelines enables organizations to more effectively manage IT changes, assets, personnel and service levels — going beyond simple IT asset management and service desk applications to deliver proactive IT business improvement. A well-implemented service can help:
  • • Reduce the occurrence of IT failures.
  • • Improve service levels and customer satisfaction.
  • • Reduce fixed and variable costs.
This helps IT to develop credibility, improve performance, reduce costs and achieve business effectiveness and efficiency in the use of information systems. Moving toward a service oriented IT model is daunting but possible — especially given the best-in-breed service management software tools that are available and specifically designed to facilitate ITIL processes.

However, most ITIL-related offerings fall short in two important areas: resource management and service costs. If a solution has built-in capabilities for detailed analysis of labor, materials, and asset and service provisioning costs related to ITIL process activities, IT managers would have the information they need to support both a more effective service delivery process and ongoing service delivery investment decisions.

IBM Maximo® asset and service management solutions are built on a single, unified platform to support key IT business processes — enabling different groups to work together more seamlessly, generally free of data conflicts or duplication.

Two core products generate a single comprehensive view

Combining two core products — IBM Maximo Asset Management for IT and IBM Tivoli® Service Desk — Maximo asset and service management solutions provide a comprehensive view that helps:
  • • Optimize IT processes.
  • • Maximize return on assets.
  • • Reduce risks and costs.
  • • Improve service levels.
One of the keys to more efficient management of IT assets is knowing what the organization has and where it’s located. That’s why Maximo asset and service management solutions integrate with autodiscovery solutions such as Maximo Discovery to help an organization build and maintain information on deployed IT assets more efficiently. By incorporating this information into Maximo asset and service management solutions, customers can make more prudent investment decisions regarding technology resources and capital.

Even better, Maximo asset and service management solutions can grow with the organization as the ITIL processes are phased in. Each organization can implement Maximo software to create a more complete asset and service management solution — or choose to establish individual components according to a phased ITIL service delivery implementation. However the organization chooses to use them, Maximo asset and service management solutions integrate with most business systems, allowing each customer to work the way he or she wants to work.

Integrate ITIL processes with the IT environment

As described in the following sections, Maximo asset and service management solutions integrate seven ITIL processes from the ITIL Service Support and Service Delivery groupings. Consequently, they help organizations bridge what is sometimes an enormous gap between business and technology — and develop a superior service delivery approach to better meet internal and external customers’ needs, at a justifiable cost.

Optimize ITIL service support processes


Configuration management
Configuration management is the process of identifying, recording and reporting on all IT components in your infrastructure. The key to a successful configuration management process is the ability to discover, identify, verify and record all configuration items (CIs) and their relationships in a central or federated configuration management database (CMDB) and use this
as the official database of record to help maintain an accurate picture of
your IT infrastructure.

CIs comprise all components of the IT infrastructure that currently exist, or will exist in the future, in the IT environment — such as PCs, servers and network devices, software and software license agreements. A CMDB not only contains the attributes and history of each CI but also the relationships between and among them. Organizations that actively engage in a configuration management process benefit from:
  • • Accurate and detailed IT asset information.
  • • Greater peace of mind regarding software license compliance.
  • • Better understanding of the potential impact of changes and fewer problems as the result
  • of changes.
  • • Expanded knowledge of budget needs.
  • Maximo Asset Management for IT supports asset tracking, asset reconciliation, compliance management, contract management and procurement, helping the organization to:
  • • Track IT assets, locations and changes and understand the relationship of assets to services.
  • • Record and manage all contracts for software licenses, leases, warranties and maintenance.
  • • Create and enforce technology standards.
  • • Provide a streamlined process for procuring and receiving IT assets.
  • • Reconcile deployed assets against authorized assets (those purchased and under contract).
  • • Support other key ITIL processes such as incident management, problem management, change management, release management and service level management via a comprehensive, integrated asset database.
With Maximo asset and service management products, CIs are stored in a central database that is accessible to all — which helps avoid costly integrations. The products present a logical, current picture of the organization’s infrastructure and services by identifying, controlling, maintaining and verifying each version of existing CIs, as well as their relationships with each other and the customers they support — helping to improve service management processes.

Incident management

Incident management is the process of restoring normal service operation as quickly as possible to help minimize an incident’s adverse impact on business operations. In ITIL terms, an incident is any deviation from the expected standard operation of a system or service. Best-practice incident management involves immediate service restoration utilizing standard processes of investigation, diagnosis, resolution and recovery.

Tivoli Service Desk documents incidents from end users, service technicians and network systems management applications. Streamlining the process further, it leverages ticket types and classifications with powerful visual workflow escalation and e-mail notifications for quicker resolution, helping to meet customer expectations and improve service desk efficiency. Consolidation of user communication across channels — including phone, e-mail, Web and fax — captures each incident, creating a searchable knowledgebase that can vastly reduce staff response time to anomalies or outages if similar incidents reoccur. Incidents can be linked with appropriate problems or changes, and are associated with their related CIs in the CMDB.
Problem management

A problem is the underlying error in the infrastructure that is the cause of one or more incidents. Problem management is the process of diagnosing the root cause of the error and arranging for a correction. Furthermore, it seeks to prevent recurrence of incidents related to these errors. Effective problem management depends on IT’s ability to quickly and accurately determine the root cause and turn an unknown error into a known error — that is, problems for which the root cause is determined and attributed to a specific CI.

With Tivoli Service Desk, IT operations can more readily identify and classify the root cause of problems, assisting staff to quickly recognize and resolve known errors with minimal downtime. Built-in, real-time dashboards provide insight into all levels of service desk operations, so that any support staff, manager or executive can monitor role-based key performance indicators (KPIs) in an intuitive, graphical display. Dashboards provide actionable information and can identify potential problem areas, enabling IT to take appropriate corrective actions in most cases before critical services are adversely affected. Tivoli Service Desk enables the creation of changes from identified problems and ties appropriate incidents to these problems.

Change management


Change management is the process of ensuring that standardized methods and procedures are used for efficient and prompt handling of all changes — to help minimize the risk of change-related incidents and improve day-to-day operations.

In ITIL terms, a change is any action that alters the form, fit or function of one or more CIs. Most often, an authorized individual initiates a change via an approved request for change (RFC), which details the proposed change and includes both a justification and authorization for the change. Change management is vital to any IT organization that wishes to provide the highest level of service delivery. A finely tuned process enables improved stability of the IT environment, provides a clear audit trail for compliance and helps to maximize the efficiency of IT staff. In addition, a true change management process helps decrease help-desk incidents generated by random, unapproved or unmapped changes.

Change management is an essential process in the overall service delivery approach because it arms IT staff with the ammunition to respond to change, and to more successfully support the organization’s business goals. Change management should offer a road map for significant alterations to the IT infrastructure, thereby helping to reduce operational risk and decrease the time and effort of implementing the alterations.

Maximo asset and service management solutions offer comprehensive change management capabilities within IBM Maximo Change Manager, which is available with both Maximo Asset Management for IT and Tivoli Service Desk. Maximo Change Manager helps minimize the often overwhelming breadth of a change management process by parceling its components into smaller, more manageable pieces:
  • • Tasks
  • • Labor
  • • Materials
  • • Services
  • • Tools
Maximo Change Manager automates requests and approvals, leveraging powerful visual workflow and escalations, and provides proactive service to help reduce outages. Thanks to a shared central database and unified design of Maximo asset and service management, IT staff can invoke change management from problem management, thus proactively planning for changes as part of an overall IT asset management process. Changes are automatically updated, and notifications of scheduled changes can alert support staff to actions that could temporarily increase the number of incidents. Additionally, Maximo Change Manager can identify and classify RFCs, and its workflow utilizes predefined processes for review and approval according to ITIL guidelines.

Release management

Release management is the process of ensuring that all aspects of a release, both technical and nontechnical, are considered together in order to
optimally navigate the release, and bridge the gap between application development and operations.

An effective release management process depends on the ability to ensure that only authorized and correct versions of software, hardware and other related

assets (training materials and documentation, for example) are available for use. This requires two key elements: the Definitive Software Library (DSL) and the Definitive Hardware Store (DHS). The DSL is a physical location that holds all original software in use throughout the organization, whether third-party or in-house. Similarly, the DHS (which may comprise one or several locations) securely stores spare hardware that has been preconfigured to meet the operating standards within the live environment.

Maximo Change Manager includes release management capabilities and simplifies the release management process by making available, anytime, all available information about approved software and hardware. Maximo Change Manager draws the information from a CMDB that serves as a virtual complement to DSL and DHS, and as the basis from which all technology releases are defined and deployed.

Maximo Change Manager includes built-in capabilities to identify and classify releases, and to plan and schedule their rollouts. Capabilities include defining individual rollout tasks and identifying the required personnel resources, materials, services and tools.

And, since all releases are changes, Maximo Change Manager creates logical associations between the two processes. As a result, it enables an organization to bundle changes (rather than execute similar changes one at a time) to help increase change efficiency and cost efficiency. Once releases are deployed, CIs are automatically updated in the CMDB.

Help improve ITIL service delivery processes


Service level management
Service level management is the process of maintaining and improving IT service quality through a constant cycle of establishing agreements, then monitoring and reporting on them to meet the customers’ business objectives.

Successful service level management depends on planning and implementing service level agreements (SLAs), or contracts between IT and its customers that guarantee a service deliverable in quantitative terms. The building blocks of SLAs are:
  • • Operational level agreements (OLAs) that document all goals and metrics agreed on by internal IT groups working toward a common goal.
  • • Underpinning service contracts that capture the metrics agreed on by IT and any of its external vendors.
Once defined and agreed on, SLA metrics must be actively monitored by both IT and the customer to ensure the commitments are met and to verify that service quality is cost-justified and gradually improved.

Maximo asset and service management helps manage service level operations and provides advanced processes for creating, managing and monitoring SLAs. It enables increased communication between IT and its internal customers and helps to align service levels with business strategies. For example, the service catalog feature allows IT organizations to more clearly define the services they will provide the business. They can then link assets, locations, contracts and SLAs to these services. Users can proactively monitor service levels via predefined key performance metrics (KPMs). Escalation management capabilities help manage resources properly to more consistently achieve service level commitments.

While SLAs are most closely associated with the service desk, service level management capabilities enable an organization to tie SLAs to other ITIL processes, enabling tighter management of configurations, changes, releases, problems and incidents. For example, it can be used to establish target response and resolution dates in incidents, problems, changes and releases, allowing for more agile service support and greater reliability in
daily operations.

Finally, Maximo asset and service management solutions can be used to establish reliability, capacity and availability commitments for assets, locations and services, assisting users to more proactively deliver critical business services.

Availability management

Availability management is the process of optimizing the capabilities of the IT infrastructure, services and supporting organization to deliver a cost-effective and sustained level of availability, to help the business meet its objectives. “Availability” tends to be a catch-all term that encompasses system reliability and resilience, maintainability, serviceability and security.
Availability is defined and promised within individual SLAs, but availability management moves a step beyond service level management in that it requires a thorough understanding of the IT infrastructure’s capabilities to deliver, and a sound process improvement loop to help optimize performance.

Both Tivoli Service Desk and Maximo Asset Management for IT utilize KPIs to calculate the following availability metrics:
  • • Total availability and unavailability
  • • Mean time between failures (reliability)
  • • Mean time to repair (maintainability)
  • • Vendor responsiveness (serviceability)
Escalation and workflow capabilities monitor and proactively notify managers of availability shortfalls and flag opportunities to improve. Specific availability metrics — such as downtime — can be analyzed using operational availability data provided by integrations to third-party solutions.

Maximo asset and service management solutions deliver extended benefits
Most comparable software solutions offer tools and processes to jump-start ITIL implementation, but they fall short in two important areas: resource management and service costs. While a robust system to manage IT assets and services is an excellent start on the journey toward a service delivery model, it’s not enough. An organization must also understand the impact such a model has on its labor, materials, assets and ongoing service costs. An IT organization’s ability to implement each of the seven critical ITIL processes and its understanding of how to best deploy resources both impact corporate service delivery effectiveness. Similarly, the ongoing management of costs associated with service provisioning also influences corporate service delivery effectiveness. Only when an organization has all of these capabilities will it achieve true unification among the business processes in IT.

To this end, in addition to its embedded ITIL service delivery principles, Maximo asset and service management solutions include core work management capabilities that allow organizations to granularly track reported costs associated with:
  • Resources (labor, equipment).
  • Tools.
  • Materials (spare parts, consumables).
  • Time.
Work management capabilities in Maximo asset and service management solutions support both reactive and proactive work activities and support mature work management processes in the IT department. Managers can track costs and set priorities based on service levels; they can also match job tasks to available resources and resource requirements, estimate and obtain approval of costs, establish priorities and initiate actions across the enterprise using the following features:
  • • Tracking tools enable detailed analysis of resource usage and costs — helping decrease both internal and external labor costs.
  • • Graphical work assignment manager helps optimize schedules and labor utilization, and assign
  • the right person with the right skills to the right job.
  • • Standard procedures functionality enables IT to streamline known processes and verify quality
  • of work.
  • • Analysis tools and KPIs help IT make informed decisions about resource and skills investments, according to the requirements expected to meet service levels.
  • • Operating agreements help improve organizational communication and can be used to verify that other internal or external providers support service level commitments appropriately.
Conclusion

IT organizations face a substantially higher burden of proof when demonstrating their organizational viability and justifying new IT investments than they did just a few years ago. To prove its value to the rest of the organization and protect its position within it, IT must strive to become a proactive, business-driven entity. Moving toward an ITIL-informed service delivery model can be used to enable this transformation in ways that enhance IT’s ability to function as a value-added business unit.

Maximo asset and service management solutions help provide a smooth implementation of ITIL best practices, directly out of the box. Designed on a single, modern and agile platform, its processes are designed to work together and help minimize the cost of ownership. Maximo asset and service management solutions are part of Symbyo Service Management, which helps align IT functions with business objectives.

For more information

To learn more about how Maximo asset and service management solutions can help your organization implement ITIL processes across your infrastructure, contact your Symbyo representative or visit www.Symbyo.com

Tuesday, January 13, 2009

Winning outsourcing strategies -- How to increase value and reduce risk

1. Introduction
With today’s tenuous economy forcing organisations
to cut costs, whilst at the same time increasing the
value that they gain from efficient, secure business
practices, one key area in which they can increase the
value of their offerings is in developing specialised
software applications or services that supplement the
more general capabilities of commercial off-the-shelf
packaged applications. Such custom applications can
add value in numerous ways, such as allowing greater
collaboration with business partners, or improving the
efficiency of specific billing systems. This is leading to
continued rapid growth in the proportion of software
applications used by organisations that are developed
as one-off projects.
However, maintaining a large application development
and testing staff is costly and requires that specialist
resources be hired and retained. Because of this, more
and more organisations are choosing to outsource the
development of software applications to specialist third
parties that have experienced resources available, and
can use their expertise to develop applications faster
and, generally, at lower overall cost. However,
outsourcing is not without risk and requires careful
planning and control to ensure that projects run
smoothly and fulfil the requirements set.
This report aims to show how 200 of the very largest
organisations in their industries in the UK and the US
that are outsourcing significant parts of their software
applications development needs are handling their
outsourcing projects. Based on interviews with those in
charge of the outsourcing projects, this research aims
to uncover the processes that they put in place to
ensure that outsourced software application projects
deliver value, and how they drive risk out of the
projects. Further to this, questions were asked about
other fast-emerging forms of outsourcing, including
cloud computing and Software as a Service (SaaS). In
many of these cases, the main focus will be on the
writing of code that acts as “glue” between existing or
hosted services, or in the creation of functional
components, rather than an entire application being
written from scratch. This means that security is an
issue that must be considered in these situations also.
2. Drivers for outsourcing
As Figure 1 shows, the primary drivers for outsourcing
software application development across all
respondents are to speed up the development of
projects and to reduce the costs involved, followed by
the need to augment staff resources through access to
the specialist resources that are available through
outsourcers. Also, as comparison with Figure 2 shows,
these factors are a key consideration among those that
outsource the most—rather than doing projects in a
piecemeal fashion where specific skill sets are not
available for developing a certain application. This is
something that financial services organisations, in
particular, could learn from.
However, some industries have been faster than others
to embrace outsourcing as a means of adding value and
reducing costs across their application portfolios. As
Figure 2 shows, the use of outsourcing for software
development is currently greatest among public sector
and retail organisations, whilst transport and financial
services organisations are comparative laggards.

As Figure 3 illustrates, those industries that are
leading, in terms of the level of outsourcing they are
undertaking, have seen the greatest growth in
outsourcing over the past couple of years. This is also
borne out by qualitative insights from interviewees, a
significant number of which among those outsourcing
more than three-quarters of their application
development projects indicated during their interviews
that they had recently made the move to outsourcing
100% of their software development needs.

Over the next couple of years, the level of outsourcing
is still expected to expand, as Figure 4 illustrates.
Although the level of increase is likely to be lower
than previously, at least 20% of respondents in every
industry will see increased outsourcing activity.

3. Outsourcing can be a risky
strategy
With any outsourcing project, an organisation must
place its trust in the hands of its chosen partner. This
means that the organisation must trust that secure
coding best practices have been followed and that
applications have been developed with adequate levels
of security built into them—for example, ensuring that
a programmer cannot have placed a backdoor into an
application that could allow them to access that
application after it has been delivered, which could
lead to them carrying out a security exploit. However,
as Figure 5 shows, organisations are outsourcing even
those applications that are used to process and transmit
the most sensitive data, such as financial and human
resources applications.
Figure 5 also shows that it is organisations in those
industries that outsource the most significant
percentage of the application development needs that
fully outsource the most sensitive applications—and
yet these are the very ones who we will encounter the
fewest issues with their outsourcing projects. Among
public sector and retail organisations, respondents are
confident enough to fully outsource development of
any type of application included in the chart whilst, in the financial services sector, just 17.5% are happy to
fully outsource the development of financial
applications.
Does this mean that those that are outsourcing the most
are putting themselves at greatest risk? On the
contrary; throughout this research, answers to
questions indicated that those organisations that are
outsourcing the highest proportion of their application
development needs are putting in place the tightest
safeguards—in terms of requirements set out in
contracts, in defining what security tools and
procedures should be used, and in the level of testing
of applications that they are demanding of their
outsourcers. This provides them with the confidence
that they need to trust their outsourcers with even the
most business-critical software applications.
As Figure 6 indicates, their trust in their outsourcers
appears to be well founded. Having taken the trouble
to clearly define requirements upfront, respondents
from those industries in which outsourcing is most
prevalent have encountered fewer problems with
outsourcing projects going wrong. For example, just
22.5% of financial services organisations report that
they have experienced no problems with outsourced
application development projects, compared to 77.5%
of retailers. Conversely, 30% of financial services
organisations have had to take legal action against an
outsourcer as a result of a failed project, compared to
just 7.5% of retailers. In total, 17.5% of projects
resulted in legal action being taken but, as may be
expected, organisations in the US took legal action in
twice as many cases as their counterparts in the UK.
Overall, projects running over budget are the most
common problem, experienced by a full 43.5% of
respondents, rising to 61% of those outsourcing less
than half of their application development needs. As
well as this, 32.5% of all respondents reported that
projects had been called off completely owing to
problems—rising to 46% in the US.
Yet Quocirca does not believe that the types of project
being outsourced are inherently different—retailers are
dealing with the financial details of customers, just as
financial institutions are. The supply chains of retailers
are far more complex than those of finance, and the transaction volumes are generally higher. Therefore,
project complexity does not seem to be a factor in this.
The fact that legal action has been taken in some cases
demonstrates that there was a problem with the
outsourcing contract drawn up—giving the
organisation nothing to fall back on when problems
occurred in terms of an agreed-upon resolution and
escalation route. Outsourcing contracts must contain
specific requirements detailing vulnerability measures,
remediation cost recovery, and specific thresholds for
acceptable risk, in order to protect organisations from
potential harm. This is especially important for those
organisations with the least experience of outsourcing,
in order to avoid the creation of overly complex, oneoff
contracts that could contain loopholes which could
be exploited should the dispute need to be settled in
court. For example, by defining acceptance criteria that
include a list of specific critical vulnerabilities,
vulnerability classes, or that mandate a maximum
vulnerability risk level, the organisation can describe
the conditions that will result in the application being
rejected and returned to the outsourcer for remediation.
By doing this, an organisation protects itself against
the most common threats to its software and systems,
giving it legal recourse should the outsourcer refuse to
fix those vulnerabilities. In addition, requiring artefacts
that attest to the application’s security level puts the
onus on the outsourcer to either engage a security
certification clearing house or automated source code
analysis tool to provide reliable information. These
best practices, stipulated up front, reduce the likelihood
of legal action greatly.
Figure 7 takes a different slant on the same data—
comparing problems experienced with outsourced
development projects by the level of outsourcing
undertaken. This clearly shows that outsourcing does
not need to be considered as a risk—so long as the
correct processes are put in place. It would seem that
experience matters.
As Figure 8 shows, this has ramifications for
outsourcing providers themselves. If any project
should not go according to plan, those organisations
with the least experience of outsourcing are likely to
impose the stiffest penalties, adding to the costs
involved in a project for an outsourcer and reducing
their profitability. Such “stick with little carrot” contracts do not tend to work in reality—a contract that
majors on how resolutions are to be reached between
the two parties will always be a better bet. Therefore, it
is in the best interests of outsourcing organisations, and
not just the companies that are outsourcing the
business to them, to ensure that best practices are
followed in clearly laying out exactly what the
requirements are at the start of the project. This is
especially true for new customers, but also for new
projects with existing clients, where contracts
developed previously can more easily be repurposed.
In addition to this, the fact that more than 50% of all
respondents would move to another outsourcer clearly
shows the risk of project failure for outsourcing
providers. This would indicate that levels of loyalty are
low and do not necessarily translate to repeat
engagements. In order to engender loyalty and
differentiate themselves, outsourcing providers should
chase a mix of best overall value coupled with special
deals to attract and retain customers. Part of this could
be done through additional differentiation, such as
adherence to ISO standards for code testing to provide
a layer of assurance that the provider follows best
practices.
4. The importance of getting the
contract right
Prior to the start of any outsourcing project, it is
essential that organisations take time upfront to define
their requirements for the application to be developed,
including determining how business critical it is and
what levels of safeguards need to be built in to ensure
that the application delivered is secure. These
requirements will form the basis of any contract and
will be reinforced through any service level agreement
put in place.
When taken across the board, respondents to this
survey gave mixed results when stating what they
considered to be the essential goals that should be built
into the contract. The main exception was for
requirements related to staff at the outsourcing partner,
for which most were in agreement that stringent
requirements should be defined. Among those
outsourcing less than half or half to three-quarters of
their application development needs, fewer than 20%
of respondents in each category defined the other
requirements mentioned as essential. However, far
more consistency and emphasis was seen from the
“guru” group (those outsourcing more than threequarters
of their application development needs).
Since this group has been shown to suffer the fewest
problems and rarely experiences project failure, it can
be inferred that Table 1 shows the best practices that
should be adopted in any code outsourcing project.
No less critical than identifying the baseline goals of
the software and the required experience of the
developers, organisations must also define what
requirements they have related to application security
and the use of security tools and techniques in the
development of software applications by outsourcers.
These processes should then be written into the
contract to provide remediation assurances should the
security of applications fail to live up to the standards
set. Again, fewer than 20% of respondents outsourcing
less than half or half to three-quarters of their
application development needs are taking the trouble to
define these requirements and to specify the standards
needed in the contract. For this reason, the best
practices related to application development and
security requirements that should be built into
outsourcing projects (Table 2) are drawn from those in
the “guru” group—those with the most experience of
outsourcing of application development.
However, it should be pointed out that attestation that
secure coding best practices were followed, while
important, is by itself not enough. What is actually
needed is some level of certification that such practices
were followed, including detailed results that prove
this. There are many ways of testing applications that
will give repeatable, reliable metrics for this, including
the use of source code analysis, penetration testing and
manual code review.
In order to ensure that requirements have been
followed, organisations should not only ensure that
applications delivered are audited, but also should
specify how they require this to be done in the
outsourcing contract for each project. However, a
similar pattern emerges here in that those for whom
outsourcing is not a clear strategy are paying only lip
service to these needs (Figure 9). This places them in a
poor position in terms of verifying that the applications
will perform as required, without serious security
vulnerabilities present. It also increases the risk for
these organisations that applications will fail to
perform as they should.




Not only is the risk increased that their organisation
could be compromised by a security attack against
weaknesses in software applications, but it is also
likely that costs will be increased as such flaws ultimately cost more to put right. Should the flaw not
be caught early and result in a security breach that is
brought into the public domain, this could have a
further detrimental impact in terms of the
organisation’s brand reputation and profile.
The efforts taken by those in the “guru” group can be
seen in Figure 10. By building stringent requirements
into contracts and enforcing standards through service
level agreements and data handling procedures, those
outsourcing the most do not need to worry about the
level of control handed over to outsourcing partners in
terms of what types of data they are comfortable with
outsourcers handling, as Figure 10 shows. This can be
done by detailing such requirements as encryption for
data at rest and in motion, unacceptable vulnerabilities
and/or vulnerability classes, and the use of synthetic
and anonymised data for testing purposes.
Obviously, agreements have to be in place to ensure
that the outsourcing company adheres to the legal
requirements for handling any data provided to them—
in accordance with the laws that organisations, as their
customers, are party to. Therefore, the outsourcing
company must understand and be able to demonstrate
adherence and compliance to such areas as data
protection, data leak prevention, and so on.
Having taken the trouble to define what is required in
the contract, no respondents in the “guru” group feel
that handing confidential information over to
outsourcing partners is a risk as the appropriate
safeguards have been built into the contracts. This
demonstrates a solid trust relationship between such
organisations and the outsourcing companies—
something that both sides must strive to maintain. One
breach of process or security from either side breaks
the relationship too easily and, as the research shows,
with loyalty being low within the code outsourcing
market, organisations can easily decide to go
elsewhere.
5. Reducing risk through use of
appropriate security tools
As well as specifying requirements in the contract for
an outsourcing project, organisations must define
processes for the tools and techniques that they require
their outsourcer’s development staff to use. The organisation must also ensure that applications are
thoroughly tested for security before those applications
are delivered. Table 3 outlines the most important tools
and techniques that should be used by outsourcing
partners in developing software applications, again
according to those in the “guru” group. However, in
stark contrast to the answers to questions regarding
contract development, there is much greater equality
being seen among all respondents in the use of security
tools and techniques.
Whilst this means that they are taking secure
development processes seriously, the use of these tools
and techniques should be contractually required—not
just be expected.
Not all vulnerabilities are of the same risk to an
organisation. It is the responsibility of the organisation
to prioritise vulnerability types as to the risk they pose
the organisation. This then defines the most critical
vulnerabilities that must not be present in code in order
to reduce risk to their organisation. Again, there is
greater equality here amongst organisations according
to their level of outsourcing, but those in the “guru”
group are still outperforming the rest (Figure 11).

The vulnerabilities shown in Figure 11 are some of the
most common and are considered to be amongst the
most critical in terms of security. However, each
application developed is different and its design and
components could lead to a vulnerability not generally
considered to be a serious risk in most situations
leading to severe problems owing to the configuration
of particular code.
New vulnerabilities, attack methods and vectors also
become known at various points during the lifetime of
an application, and the outsourcer must be able to
demonstrate that they can deal with this. To gauge the
level of risk posed by each type of vulnerability
according to how it could affect a particular
application, risk-rating systems can be used to
determine how serious any flaws encountered are,
incorporating the level of risk that an organisation
would face should those vulnerabilities be exploited
(Figure 12). This provides an automated way of
proving that the most severe vulnerabilities are not
present in applications before they are accepted and
put into use.

6. Testing applications for
security
Since security should be a key criterion for acceptance
of a software application developed by an outsourcer,
organisations must require that initial security testing is
done by outsourcers. This should not, however,
absolve organisations from the need to test the security
themselves or to have independent validations done.
For one thing, this denies an outsourcing provider the
chance to claim that the application was signed off by
the organisation to which it is delivered in the case of
dispute. As shown in Figure 9, above, it is considered
best practice to write into the contract that the
organisation has the right to audit the application
before acceptance.
As Figure 13 shows, requiring outsourcers to perform
initial testing is a best practice that is not lost on the
most experienced outsourcers. Those still developing
their outsourcing programmes would do well to
emulate this, since performing tests in-house is a more
expensive option and requires that the organisation has
sufficient qualified resources to conduct those tests. As a general rule of thumb, testing in general, not just for
security, eats up around 25% to 30% of an application
development project in terms of time, resources
required and cost of testing.
Organisations outsourcing the development of software
applications should also define the most serious errors
for which the outsourcer should ensure that tests are
conducted. As Figure 14 shows, this is a requirement
set among the majority of organisations, although the
“guru” group still performs the best, reducing overall
risk of failure of applications delivered.

In order to ensure that applications are tested
thoroughly, including at different stages of the
software development lifecycle, organisations should
specify the sorts of security testing techniques that
must be used by their outsourcers.
As Figure 15 shows, the majority of organisations
interviewed take the trouble to specify what testing
techniques should be used, with the greatest efforts
being taken by those in the “guru” group. However,
this also means that the organisation doing the
outsourcing must clearly understand the benefit of each
of these approaches and what value they bring to the
overall testing process in order to be clear about what
they require to be used.
Finally, it is one thing to require that applications are
tested for security defects before they are delivered,
but how can the organisation that is outsourcing
development of an application ensure that those tests
have been carried out?
As Figure 16 shows, the vast majority of organisations
either perform their own tests or require some form of
validation of the testing results. This is positive,
although those that have not taken the trouble to define
what security tools and procedures should be used in
development, as well as how applications should be
tested by outsourcers, may find themselves with a
delayed project and, potentially, cost overruns as
application flaws are uncovered just when
organisations thought the application was ready to be
put into productive use.

7. Outsourcing to external
service providers
A fast-growing strategy being seen among
organisations today is that of the hosting and
management of their software applications to external
services providers. Figure 17 shows that the use of
these services is greatest among those vertical
industries that are the most reluctant to outsource the
actual development of software applications—namely,
financial services and transport organisations.




In these vertical industries in particular, organisations
are most likely to develop their own applications for
hosting and management by outsourced providers, or
to use services such as Software as a Service (SaaS).
Where organisations use external service providers to
host in-house developed code, they will often rely on
those partners or other third parties to provide add-on
code and other services that extend the value of the
software. With SaaS, integration with other internal
systems must be achieved, often requiring some level
of customisation or add-ons to code that could impede
the performance of other applications.
This survey looked to uncover the rigour that is used in
gauging the security of the services provided by such
outsourced service providers. Figure 18 shows that
security is a key criterion for many organisations that
are outsourcing their application hosting to external
service providers.
Although the results do not vary much by industry,
organisations in the “guru” group are applying the
most stringent requirements to outsourcing contracts—
namely, those in the public sector and retail
organisations—and still slightly outperform those in
other industry sectors.



This same pattern can be seen in Figure 19, which
shows that those in the “guru” group require the most
strict security architectures from their outsourced
service providers. However, financial services
organisations could do more to learn from their peers
in other industries and should consider beefing up their
requirements for security.
8. Conclusions
As this report shows, successful outsourcing benefits
from an awareness of the likely challenges and risks
that outsourcing can pose. For those organisations with
the most experience, success is much more likely, and
their established best practices can provide a roadmap
for others to follow. The stark differences in many
places uncovered between this group of leaders, and
those with less experience in development outsourcing,
demonstrates a major gap between what can be done,
and what many are actually doing.
Making use of the best practices detailed in this report,
based on the analysis of the responses from the “guru”
group, should provide anyone looking at outsourcing
development with greater peace of mind. Creating
upfront security requirements and deliverables, as well
as specifying the means through which they will be
measured, will lower risk and result in a more secure
work product, delivered on a more predictable
schedule, that will also require less maintenance over
time.
With the proper safeguards built into outsourcing
projects, organisations will be able to achieve their
ambitions of increased speed of software application
development and reduced costs—at the same time as
they shield themselves from the risk of project failure.
This will also allow them to build repeatable processes
that can more easily be repurposed to ensure the
success of subsequent projects undertaken.
These safeguards include not only taking the time
upfront to ensure that all expectations and
responsibilities are built into a workable contract, but
also that all applications have security built in from the
ground up and that they are tested for security as a
requisite for acceptance.
As well as this, organisations outsourcing application
development must ensure that they have the right to
audit the application, or have it independently verified,
and that remediation processes are in place for dealing
with any flaws uncovered.
Dealing with these processes is not only becoming
more important as application development
outsourcing increases, but also as more organisations
undertake newer, fast-emerging types of application
outsourcing where applications, including the data they
contain, are hosted by third parties, or where service
providers write add-ons to applications, such as is
increasingly happening with delivery mechanisms such
as Software as a Service (SaaS). Best practices gleaned
from more traditional outsourcing projects will be of
help in deriving greater value and reducing risk in
these types of services as well.

Wednesday, December 31, 2008

Taking Measures for True Success: How to Choose Software That Meets Your Needs

You’ve probably already read about recent large-scale software implementation failures and their costs to companies: More than $33 million lost, as a project goes over budget and time. In excess of $54 million spent, and the project canceled before completion. Revenue loss of $100 million, as the new software fails to successfully integrate with the old. These are just some examples—global averages are often difficult to accurately determine due to companies’ reluctance to publicize failed projects.

Is the success of a software selection and implementation project really nothing more than a happy accident, and almost completely beyond your ability to control it? Why is the rate of failure so high?

One main factor Technology Evaluation Centers (TEC) has observed is that the less-than-inspiring rates of success noted above often boil down to the organization’s current experience and historical success with larger-scale implementations involving complex functionality. In other words, the success of a software selection and implementation project depends on whether your current internal resources are sufficiently skilled and experienced to define your organizational needs.

Software Selection (and Implementation) Failure

But in addition to considering your internal resources, it’s important to realize that the probability of success also depends on how you define success.
Organizations often employ “fuzzy thinking” to determine the metrics that define a successful software implementation project. Companies have a tendency to use three common metrics: if the project was completed within a scheduled time frame and within budget, and brings the full-spectrum of new functionality to help automate processes and improve efficiency, then the project is deemed a success.

However, upwards of 60 percent of companies fail to consider that completing a project on time and within budget means nothing if the software itself doesn’t meet the needs of the organization.

Let’s look at why time, budget, and functionality aren’t the only metrics you need to consider, and why choosing and implementing a software solution might be more complicated than it seems at first glance.
  • Time: “Short-cuts” can be very expensive in the long (or even short) run. For instance, many organizations elect to shave time from the painstaking requirements-gathering process. But if you discover after implementation that crucial functionality is lacking, you’ll need to spend additional time and effort to work around the deficiencies.
  • Budget: You may be tempted to cut back on certain expenses to bring your project in under budget—but, as an example, shrinking your budget for training staff means the software may not be used efficiently, as staff struggle to learn how to use it themselves, on your dollar.
  • Functionality: Even if a software package offers comprehensive functionality, there’s no guarantee it’s exactly what your organization needs (full-featured doesn’t necessarily mean “best”). The only way to properly rank your functional requirements is to define them—before you even start choosing a solution.
Time, budget, and functionality are important considerations, but they shouldn’t be used as the only measures of a successful project. And even if you meet all of them, your project isn’t a guaranteed success.

The real measure of success is whether or not the software you implement meets your business requirements.


The Big Question: How Do You Succeed?

So if it isn’t just a matter of time, budget, and a spread of features and functionality, how do you succeed? The most important part of the software selection and implementation process is to define your requirements. But, it’s not quite as easy as it sounds.
Know what you do and the steps you have to take to do it, so the software you choose does what you need it to do.

Don’t let the software features dictate your business processes and core activities—make sure your business activities determine the software functionality you require. To do this, you’ll need to get consensus from all stakeholders about what your core business activities are, and then create one shared definition of those activities, also known as business process modeling (BPM). Not doing so may result in disagreement about what activities are most important—and worse, disagreement about whether your chosen software is meeting the needs of your business.
To understand your software requirements—the starting point for a successful software selection and implementation—you must define your desired-state business processes.

Elements of Business Process Modeling

To define your processes, you’ll have to ensure you address all aspects of business process modeling (BPM). Note that these are not necessarily discrete, sequential steps. Best-practice software selection projects often address these elements concurrently or iteratively.
  • • Defining current processes
  • • Describing changes or additions to existing processes that improve business results
  • • Conducting review, analysis, and validation to ensure that requirements are clearly and completely described and aligned to your business objectives.
  • • Prioritizing your needs in terms of what you would like a new software system or Custom Application development to address: What are your “must-have” versus “nice-to-have” application features and functionalities?

BPM + DIY = DOA?

Your internal business analysts (BAs) may have the necessary ability and experience to fully define your requirements, but if they don’t, it sets your organization up for a less-than-successful selection and implementation. “the vast majority of projects surveyed did not use sufficient business analysis skill….” According to the study, 70 percent of organizations lost control of time and budget while at the same time attaining far less functionality. Why? Because their organizations didn’t have sufficiently experienced analysts for this type of strategic project.

In other words, most companies’ internal business analysts do not have the needed background, experience, or expertise to perform adequate or effective business process modeling. You may be imperiling your odds of success by going through the selection and implementation process alone.

If your business lacks the necessary BA expertise, what can you do about it? There are three solutions that can help you deal with the problem of inadequate analyst expertise.
  1. Hire someone to coach and mentor your current business analysts through effective business process modeling and analysis, including driving consensus and requirements-gathering, and steering you away from common BPM pitfalls.
  2. Hire outside consultants to do your business process modeling and requirements analysis for you.
  3. Let the software vendor take care of defining your processes. Attention: this “vanilla implementation”—one flavor for everyone—may sound all right, until you realize that vendors will naturally fit your requirements to the functionality of their software offerings. But the fit may not be right, and the last thing you need is the headache of relearning your business processes to accommodate an unwieldy software package.

You may have noticed that we haven’t talked about training your internal analysts in how to do BPM. The simple reason is that in-depth BPM training is a very long-term, possibly multi-year commitment—which the typical software selection project cannot accommodate.

The Last Word

Are you ready to start your software selection and implementation project? To see if you’ve now got the know-how for a successful outcome, consider these questions.

1. Your first objective for your software selection and implementation project is to
  • a) get a good price, or a price that meets your predetermined budget
  • b) meet industry best practices and regulatory compliance issues
  • c) meet your business process needs
  • d) find a solution that is “user-friendly” and easy to implement
2. The most important measurement of success for any software selection and implementation project is
  • a) finishing the project on budget
  • b) getting the maximum range of software functionality
  • c) ensuring the project is not delayed
  • d) defining your requirements accurately
  • 3. The best way to define your business processes and requirements is to
  • a) use only your internal resources, including business analysts
  • b) hire outside analysts to perform BPM
  • c) get experts to guide your internal analysts through the BPM process
  • d) hand the task over to the vendor
There are no right answers, but there are better answers. Any approach can lead to success. But the question is this: how do you improve your odds, faced with a risky and costly software selection project?
By having your requirements thoroughly and accurately defined, you have a solid basis for the other requirements for success (time, budget, functionality). And, if you decide to engage the services of dedicated experts, you can benefit from best-practice services for successful requirements definition, including courses to coach and train your business analysts, project requirements elicitation, request for proposal (RFP) preparation, and project scoping and requirements planning.

Whatever you do, make sure you don’t end up a sorry statistic. Define your requirements with the help of specialized and experienced professionals. Contact Symbyo Technologies Experts today for a free consultation.

Tuesday, December 30, 2008

Steps to select the right Outsourcing Vendor

The process of selecting a software outsourcing company vendor implies a complex multistage process to evaluate not only what the provider can do, but also the way it’s done.

If your project ends up in the wrong hands, it could endanger all your great plans for business growth. In return, with a well-selected provider, you will see savings, enhanced product value and greater speed to market, thus giving your business a competitive edge.

Introduction
The process of selecting an outsourcing vendor implies a complex multistage process to evaluate not only what the provider can do, but also the way it’s done.

First of all it’s important know that this process can and should take some time. Sometimes, this means months.

A well-organized vendor selection usually takes between 6 and 12 months and can ramp up the total cost of the project with approx. 1-10%. (For further information on this, read the “Real cost of Outsourcing” white paper).

Costs associated with this phase include analysis and documentation of requirements; creation, distribution and evaluation of RFPs (Request for Proposals); negotiations of contracts; development of SLAs (service level agreements); pay of external players: consultants, lawyers etc. Therefore, the selection of vendor is not a process to be rushed. Companies should follow a well-established methodology that defines each step of the trip. After all, the final goal is to end up with the best service provider for delivering the desired outcome.

Step 1: Define your objectives and goals
This is a basic step for all future outsourcing activities. You have to describe the process, service or product that you want outsourced clearly. You should also indicate what your goals are through outsourcing.

Another one of the first things you should do is gather a core team to evaluate vendors and participate in negotiations. The team should consist of individuals from various parts of the company, such as executives from affected business departments, legal staff and human resources responsible.

Make sure you include the answer to the following questions in formulating your objectives:
* What do you want to outsource?
* What type of an outsourcing agreement are you looking for?
* What are the offshore outsourcing locations that you are interested in?
* What are your goals in outsourcing?
* What services do you expect a vendor to provide?
* How much do you plan to spend?
* What are the risks associated with such an outsourcing agreement?

The team’s first task should be to define the high-level requirements of the outsourcing engagement. For instance, if the goal for outsourcing is to reduce costs, the organization should state it openly and leverage this process to explore ways to achieve that goal. The next step is to benchmark the current process against others in the industry. Drawing "before" and "after" process maps is a great exercise that helps companies explain where they are today and show where they want the outsourcer to take them.

Next, it’s critical that the core team determines the right type of services to be outsourced. There are many different kinds of work outsourced. However all of these outsourcing services fall in two broad categories, technology services outsourcing and business process outsourcing.
Technology Services Outsourcing The fast emerging business world of today requires companies to use sophisticated and fast computer systems and software. These technologies and systems also need to be scalable and highly adaptive. Therefore it is imperative to choose the right associate for developing these technologies. Here are some of the different categories that come under technology services.

* ecommerce
* Network/ Infrastructure
* Software/ Custom Application development
* Telecom
* Web Development and Hosting

Business Process Outsourcing (BPO)
The new global scenario requires that each company finds its own niche field that can add value to the world economy. Thus companies now try to focus their resources on areas that give maximum yield. As a spin off of this trend, service providers who focus on narrow business providers these enterprises need also emerged. Thus the term Business Process Outsourcing (BPO) came into being around 1995. The proliferation of the Internet and its emergence as a business tool helped to make BPO highly popular.

Below are the sub categories of services that come under BPO.
* Customer Relations/ Customer Contact Management
* Finance/ Accounting Processes
* Logistics
* Equipment Management
* Security

Step 2: Find out all you need to know about the vendor – Plan the RFI

The Request for Information (RFI) provides material for the first rounds of vendor evaluations. Organizations generally use the RFI to validate vendor interest and to evaluate the business climate in the organization’s industry. As opposed to a highly specific, formal Request for Proposal (RFP), the RFI encourages vendors to respond freely. It also spells out the business requirements defined by the core team, so the vendor understands
what the company is trying to accomplish.
* A request for information is just that – requesting information
* It is usually issued to acquire information on what is available, from whom and what approximate cost before writing an RFP that is based on real information rather than wishful thinking.
* Typically, vendors will not respond to an RFI unless the effort to do so is not excessive and there is an expectation that an order or at least an RFP will follow.

Contents of RFI
* The type of information usually sought by RFI’s includes things such as:
o The availability of equipment or needed services.
o The approximate one time and recurring costs.
o The differentiating factors between the goods or services proposed and similar offerings from other vendors.
* The latter is very useful in providing information to help determine mandatory and desirable
characteristics to be included in an RFP.

After vendors return the questionnaire, the issuing company matches the vendors’ responses to the company’s requirements and weights the criteria based on importance. Providers that don’t meet stated needs or haven’t responded to the specific questions are eliminated.

Eventually, the RFI process helps companies make the "go or no go" decision—that is, the choice to proceed with or walk away from a project. The data solicited identifies the availability and viability of outsourcing, cost estimate ranges, and risks. It also provides detail useful for developing project requirements.

Step 3: Prepare the RFP
The third step is to develop the RFP; send it to at least three short-listed suppliers; evaluate them; and, of course, select the best ones.

The RFI and RFP are complementary. Information collected during the RFI process can prepare the solution requirements section of the related RFP. You should have by now a better understanding of project scope and requirements, as well as a list of qualified suppliers. Leveraging the information-gathering focus of the RFI will lead to a concise RFP that articulates the business needs.

The RFP outlines the engagement’s requirements—relevant skill sets, language skills, intellectual property protection, infrastructure, and quality certifications—and gives prospective vendors the information necessary to prepare a bid. The responsibility of developing the RFP rests with the project’s sourcing leader, but various aspects of the document will require input from other domain experts.

A good RFP includes one section that states what the company seeks (business requirements) and four sections that ask about the vendor and what it will be able to provide:
* Business requirements. In brief, this section details the company’s project goal, deliverables, performance and fulfillment requirements, and liquidity damages.
* Vendor profile. External service providers differ greatly in performance, style, and experience. This part of the RFP details the vendor’s stability, services, and reputation.
* Vendor employee information. This section addresses the resources assigned at the project management, middle management, team leader, and task levels, along with the quality of people, their skills, training, compensation, and retention. If your company ranks technical skills highest should look at technical expertise before examining costs.

* Vendor methodology. The methodology segment details project management, quality, regulatory compliance and security.

* Infrastructure. This part outlines the vendor’s infrastructure stability and disaster-recovery abilities.

Step 4: Due Diligence
After vendors have sent their RFP responses, you begin the evaluation. Usually, vendors propose different strategies when they respond to an RFP. They may suggest a sole provider,
co sourcing, or multisourcing scenario, in which one, two, or several vendors, respectively, deliver the service to the company. Regardless of the structure, if the proposal meets the stated requirements, each vendor must then undergo a due diligence review.

Due diligence supports or invalidates the information the vendor supplied on processes, financials, experience and performance. It helps you determine what the provider can do right now, as opposed to what it might do if given the business. Due diligence should confirm the information supplied in the RFP and address the following data:
* Company profile, strategy, mission and reputation
* Financial status - reviews of audited financial statements
* Customer references - preferably from similar outsourced processes
* Management qualifications, including criminal background checks
* Process expertise, methodology and effectiveness
* Quality initiatives and certifications
* Technology, infrastructure stability and applications
* Security and audit controls
* Legal and regulatory compliance, including any outstanding complaints or litigation
* Use of subcontractors
* Insurance
* Disaster recovery, security and business continuity policies

Pay attention also to employee policies, attrition, service attitudes and management values; the company and the vendor need to fit together culturally.

You should evaluate the vendor’s project management competency, the level of success achieved, the quality and standards of work delivered, adherence to contract terms, and the communication process. Reliable, ongoing communications, especially in offshore outsourcing is very important; potential pitfalls can result from infrequent or vague communications. For instance, if the onshore company doesn’t clearly communicate deliverables and timelines, offshore resources might not be allocated correctly and may endanger completing the project on time.

Sometimes you must perform due diligence on more than one of the vendors that respond. The length and formality of the due diligence process varies according to companies’ experience with outsourcing, the timeline for implementing outsourcing, the risk, and familiarity with the vendor.

Step 5 (Optional): Test Project
Some companies can even conduct test projects to ensure a good fit between the company and the vendor.

These tests allow companies to review the vendor’s project management process for efficiency and effectiveness. Specifically, they look at whether project execution is completed within guidelines, whether deliverables are timely and whether the vendor has adhered to defined quality standards. Tests serve as a good method for companies to check and review the facts before making a final vendor decision.

Test projects also let companies experience the benefits of outsourcing before jumping into a long-term relationship. Often, companies will conduct a "proof of concept" (POC) with a couple of vendors to compare results and, after evaluation, choose the best one. A good method to select the best vendor is by taking the top two vendors from the RFP process and having them complete the same test project. This will demonstrate their project management capabilities, communication style, and ability to meet deadlines for deliverables. Many companies are using POCs as test beds before offshoring larger projects.

Step 6: Choose the Vendor
Eventually, the biggest step in the process of selection is picking a service provider to manage business processes and applications. Making the final decision means signing a contract that clearly defines the performance measures, team size, team members, pricing policies, business continuity plans and overall quality of work standards.

Conclusion
Last, but not least, remember that outsourcing is a long-term relationship, and choosing the right vendor is crucial to meeting your technology, business and financial objectives. If you base your decision on following the steps above, you will eliminate the risks of engaging in a wrongly-selected affiliation that can not only fail to improve your business, but even do harm.