Chapter III: "Offshore Outsourcing Methodology for Small and Mid-size Businesses", Part 1

One of the main OOBP.org objectives is to define the best practices and principles that would increase the effectiveness of software outsourcing projects being conducted by small and mid-size business. Here are three ASAP principles that account for specifics of the SMB outsourcing realities and contribute to the overall methodology that is now being developed by the OOBP community.

ASAP (As Soon As Possible)
Amount of time allocated for release of the first functional version of the system should not top 20% of the total allotted schedule and may only be preceded by the knowledge transfer and requirement specification stages. The project development time should be clearly outlined and determined at the start. This allows avoiding some common risks:

• Dismissal, illness or transfer of key stakeholders and developers to another project might lead to the loss of important information. Managing this risk by duplication, detailed documentation and formalization is usually too expensive and ineffective for relatively small projects.
• Shared resources conflicts between client and vendor - for example time on testing servers, potential users, etc.

Immature companies which are aware of these risks often try to protect themselves by overstating the time and budget estimates. This leads to more relaxed work at the start ("we have plenty of time") and doesn't solve the problem in the end: all reserves are spent in the beginning and in the middle of the project.

ASAP (As Specific As Possible)
The most important principle of OOBP.org SMB methodology is maximum relevance of every activity for the real project requirements. Irrelevant requirements become the core of the most devastating risks, which like a malignant growth destroy the solution from the inside and reveal themselves only when it is to late for treatment.

SMB methodology distinguishes three types of requirements that should be avoided:

• Abstract requirements as a result of different expectations on the part of client and vendor. For example, the client wants to develop an important and complicated system using cutting-edge technologies so that the system could remain up-to-date for a longer period of time. Usually such technologies are pretty raw, immature and untried, which leads to the prolongation of the terms and often several remakes of the system or its components. The vendor, in turn, may decide to try using multi-level architecture, thinking it would work better as it is more complicated. As a result, you get the more expensive and longer project, higher risks and all this just for the love of the game.
• Irrelevant requirements tend to appear from the analysis of incomplete and controversial initial requirements. Often the development starts with the creation of engines, libraries, and platforms that are useless on their own, but supposedly help further application development, making it easier and more effective. The first change inthe requirements usually shows that the assumptions made initially are false and the libraries created on the basis of these assumptions can't be used.
• Internal requirements may emerge when a client or a vendor decides to use the existing tools and processes in a new project without a reason. Many companies often try to increase their profits (or reduce costs) using the existing code. This could be very efficient, but in most cases this leads to adding unnecessary functionality, extra dependencies, and inherited problems. Besides it is next to impossible to determine a person responsible for the system's malfunction if it occurs.

ASAP (As Simple As Possible)
From all possible solutions, choose the simplest (the cheapest and fastest to implement) one unless there is a 100% certainty that this approach doesn't work or doesn't meet the requirements. A typical problem is over-complication of the initial system requirements due to the excessively sophisticated architecture. This may seem obvious, but rarely people do check if the solutions really should be as complicated as they sometimes are.

Using the simplest solutions has one more important advantage - developers do not get too "emotionally" involved in architectural and technical solutions they create. If they do, they may end up developing elements of aesthetical and historical value for them, but without actual use for the required system. They might leave these elements in the system, even though it might make the system more complicated, reduce quality and increase risks.

I. Choosing a Vendor

"Do Your Homework: Know Your Offshore Options"
www.informationweek.com

One of the biggest challenges for small and midsize businesses that want to place IT work offshore is finding a reputable provider. While large companies typically have entire departments dedicated to identifying and vetting contractors, most small companies don't have such in-house expertise. However, small businesses always find some alternate ways to find the right vendor. Current article considers networking, web-based SMB communities and trade associations to be a precise toolkit for smaller buyers choosing an appropriate vendor.

Read Article | Back to Top

II. Outsource to...: South Africa

"Outsourcing Matures in South Africa"
www.sharedxpertise.org

Outsourcing continues to attract attention in South Africa. Supplies and recipients are learning to work together to achieve greater efficiencies, and recent surveys in the IT outsourcing sector in South Africa reveals a general maturation in the outsourcing market, with some significant shifts. the right partner.

Read Article | Back to Top

III. Mid-market Challenges

1. "Small-Scale Offshoring"
   www.informationweek.com
   
   In the upshot small-scale business will benefit from outsourcing. Yet the right offshoring procedure often appears as a result of an initial negative experience. The article investigates two cases of small companies, whose IT jobs were moved offshore. As a result, both companies, IT and non-IT, found it extremely useful to outsource. The cases show some steps one should stay away from, and grounds the necessity of delegating work.
   
   Read Article | Back to Top

2. "Is Outsourcing Worth It? How One Can Outsource Wisely"
   openoutsource.com
   
   Recent trends in the software development market show that onshore IT development is no longer the most efficient approach. Competition is so high that in some cases in the U.S. and Europe IT personnel took up farming instead of adapting to new global trends in IT. This article is mainly for those who plan to remain in the IT industry despite the surprises it continues to bring.
   
   Read Article | Back to Top

IV. Things to Outsource

"KPO: Intellectual Capital, Ahoy!"
www.financialexpress.com

Current developments in the BPO arena bring more and more companies to a conclusion that moving their processes offshore will be an effective step. While large-scale businesses find it cost-and-time-effective to move most of their non-core jobs offshore, there are additional benefits for mid-size businesses. For SMBs, there are also challenges to invest in Knowledge Process Outsourcing (KPO) as KPO service providers allow their clients access to highly specialized experts. Further, the article looks at the People Philosophy and Development, Recruiting, Training, Quality and Expertise - things that make BPO successful.

Read Article | Back to Top