Offshore Software Development

Risk Four: Differing Internal Processes

2006-12-14T12:57:00.000-08:00

Sometimes the vendor's processes could be a lot different from what Client is using for executing their internal projects. If these differences are not discussed beforhand, they could become a risk and cause project delays.
_____________________________________

Each vendor will have somewhat unique processes and methodologies that they follow when developing a project. It is important to evaluate how this differs from your in-house processes, and how the two differing approaches can best be “meshed” together during a development project.

It is best if a development project is guided by a well-defined, common software development and project management methodology. The best vendors follow industry standards, such as CMMI and ISO 9001 QMS (as Hanu Software does). This common methodology should cover libraries, tools used, version control and quality assurance processes, as well as security metrics for each project.

Once the process is agreed upon and established, it is equally important that monitoring is in place, to ensure that these processes are being properly followed. Clients should have each project milestone clearly defined, including what deliverables are planned during each phase, with specific deadlines for the completion of each. The client should also have a clear understanding of what their obligations are in regards to reviewing and approving each delivered product, including the requirements documentation, the system design, test cases, and any test issues that arise.

In general, the more involved your company is with the project, the more smoothly the project will go. This is why it is important to have a designated contact within your firm, whose role is to communicate with the vendor project manager and/or development teams. This person, as well as key stakeholders in the project, should be available to review progress reports, review finished deliverables, and be available for telephone conference. If the vendor has questions related to your firm’s products and applications, which require answers in order to continue development, your designated company contact is responsible for arranging for the proper technical resources to provide answers.

Painless Merging of Methodologies

- Agree upon a consistent methodology based upon industry “best practices” that your firm and the vendor will follow prior to starting the project

- Monitor compliance with the agreed-upon standard

- Set up specific times to clarify and answer questions, especially at the outset of any project or outsourcing relationship

Your company’s project manager or designated contact will need to review the status of any deliverables as well as any testing done, and be available to communicate frequently with the vendor project manager. Most project problems occur to infrequent or poor communication between the firm outsourcing, and the vendor. But the “no news is good news” approach is rarely true; in fact, the opposite will often occur. One of the easiest ways to reduce this risk, and to catch problems early on, is to initiate frequent communication, with regular times specified for project reviews.

Differences in development methodology can occur, if one firm prefers an RUP approach with exacting specifications, while another firm prefers agile methodologies. One firm may have a preferred tool in place for source code control, or for coding standards, or for testing builds. These issues can often be worked out by communicating the reason for each approach, and then choosing a consistent methodology. Most frequently, you will ask the offshore team to adopt your in-house methodologies, but you may be surprised to discover that they have methodologies or tools that equal yours, especially if they have significant experience in a technology. This is where teamwork, and communication between the project and development team managers is critical.

Related to methodologies are evaluating how the firm being outsourced to handles sudden requests for large volumes or rapid delivery. Check on how flexible and scalable your vendor is, and whether they have processes in place for hiring additional staff as required for larger projects. This includes having sufficient project management staff in place to ensure adequate monitoring and communication with your firm. Ask them: “What is the smallest project you have worked on? The largest project?” to help determine whether they can scale to meet your needs. You will also want to check references for projects that are similar to yours.

Managing the Risks - Offshore Outsourcing

2006-05-23T16:25:00.000-07:00

It is a well known fact that the offshore outsourcing (or any type of outsourcing for that matter) carries known and unknown risks. The important thing is to find out if your offshore outsourcing provider is aware of these risks and has a plan to either mitigate it or eliminate it altogether.

In this post, I will share some of known risks related to offshore outsourcing.

Risk One: Requirement Misunderstanding - Many times it happens that the requirements get written in a hurry to get the project started as soon as possible. This is okay if the project is being done inhouse. However if it being outsourced, it becomes a risk. If the specifications are not written properly or are incomplete or enough details are not provided, the project will have problems on various fronts such as Project Understanding - what needs to be done and delivered, Project Planning - putting together firm dates for delivery, Change Controls - lots of change control will be generated later on in the project life cycle, which could obviously delay the project as well as increase the cost.

Per the study conducted by Software Engineering Institute, not enough understanding or the clarity around the customer requirements is one of the top reasons on why software projects fail or get delayed.

In order to mitigate this risk, make sure that your provider has gone through the requirement understanding phase before starting the coding phase. The requirement understanding phase should have multiple rounds of discussion with all the involved parties to fully understand and document their requirements in the Software Specification Documents. This phase is independent of technology selected for the project. The provider should also prepare the HTML mock-ups which is an excellent way to capture the application flow. [These mock-ups should reused during the coding phase for embedding the application method calls.]

Requirements Development
The Requirements Development phase is about gathering the needs of the customer and translate into requirements specification of what the system must do. Requirements Development consists of three related activities:
• Gathering User Requirements, which is accomplished by interviewing the potential users about the system they want, building the interactive prototypes, writing the Requirement Specification documents.
• Analyzing Requirements, which is about determining the acceptability, implement ability, and testability.
• Inspecting Requirements, which is accomplished by discussing the proposed requirement in detail. The goal is to identify the issues and errors related to the requirements ambiguities or discrepancies.

The deliverable from this phase is a detailed requirments document which should get jointly reviewed and signed off.

Risk Three: IP & Data Security

2006-11-22T12:53:00.000-08:00

IP & Data Security - Companies considering outsourcing their software development need to know and protect themselves against the risks related to the Intellectual property violations as well as Data Security. In order to mitigate this risk, clients need to check with the vendors on steps that they will take to protect their IP and the sensitive data such as customer information, employee information, financial data and market research data. This should be done during the Vendor Selection process.

Clients should ensure that selected vendor has the well documented Information Security Management (ISM) Policy. Vendors need to provide a dedicated project and data server to their clients with audit control access on all the servers. Client should check that the Vendor’s facility is secured with smart card control access and vendor’s development team members have signed the Confidentiality agreements. In addition, the development contract should include clauses for Non-compete, Non-disclosure and non-solicitation.

Risk Two: Quality

2006-10-30T09:27:00.000-08:00

In my last post, I discussed the risks related to the requirement understanding. In this post, I'll cover the risks related to the quality of a software project and what steps your provider should take in order to reduce or eliminate the risks related to the quality.

Quality - Often times, customer receives the application from the offshore provider which looks okay on the surface but is full of defects. What happens is the offshore team in order to meet the dates, skips the most important phase of the software project life cycle - Testing.

To ensure the excellent quality of application, the provider must do the testing at the various stages of the software project. For instance, during the coding phase, the developers must write the Unit Test cases for their module/form, and test the program thorougly. Once the coding is complete, QA group (assuming your provider has one) should execute the System Test Cases (written after the requirements are finalized) and make sure that the system performs as per the customer's requirements.

Another way to improve the quality of the software projects is to do the Inspections of the work products.

Each hour spent on quality assurance activities such as design reviews saves from 3 to 10 hours in downstream costs.

A requirement defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time.

Inspections are detailed technical peer reviews of software designs or implementations. The customers should ask their offshore provider to conduct inspections at every stage of the development or the maintenance process. Because of their ability to detect and correct defects in upstream work products, inspections help us control cost and schedule of the project.

Offshore Software Development

2006-05-19T05:38:00.000-07:00

Offshore Delivery Model

For organizations to stay ahead in today’s fast changing business scenario, time is the single biggest factor – time to market, time to launch new products, time to respond to customers. Organizations are faced with a growing number of challenges and business risks due to rapid advances in technology and increasing pressures on margins.