15 Jul 2013

Little Practical Guide to Outsourcing Software Development Projects

Little Practical Guide
Software Development Projects

Axel Vanhooren

More and more projects are outsourced. It can be done onsite or offsite, be it as a onshore, nearshore or offshore project. This tactic can reduce the cost. But outsourced projects require a much better preparation and more formalism. Since more people are working on this type of project, more coordination is needed.  Outsourced projects are more complex, larger and riskier than when they would have executed in-house.
Taking the decision for outsourcing a software development project has more consequences for the client company or client organisation.

The decision is not straightforward at all. In essence, four aspects play a major role in the decision

·         Financial aspects
·         Practical implications for the company/organisation
·         Ability to set-up and manage offshore projects
·         The offshore software supplier
·         The type of project

Why doing outsourcing?

Cost Reduction
Probably the most cited argument is cost reduction.  Achieving a cost reduction may be not as easy. It doesn’t come down to take the plan of the project as if it was executed in-house or on-shore and using local salaries, local hiring fees and a supplier margin to compute the cost benefit. The reason for this is that outsourced projects have other requirements than in-house executed projects.

We need to consider that software development projects shouldn’t be managed as a cost, but as an investment. During the lifecycle of a software system, we need to look continuously on how to maximise its value for the company. And, the cost of the project that created the software is a fraction of the total cost of the software system’s life. Yet, during this project a lot of important decisions are taken concerning the scope, the purpose, the architecture, the design and the technologies. They have a great impact upon the future life of the system. They determine whether the system can respond to opportunities and at what cost. It determines how well it can evolve and thus influence the duration of its life. This project defines the basis of the further lifetime of the software system and influences thus the profitability of the system.

Other Reasons
Although the cost is the most cited reason, it may be not the real reason. Or, other reasons may play a role as well: understaffed IT department, lack of IT competencies, lack of trust in the IT department, a consumer’s attitude (preference for solution acquisition over doing the effort of solving problems), and so on.

The strategy to reduce drastic the internal IT department is highly questionable. Competencies in implementing changes, problem solving skills, project management skills, IT competencies and the capability to innovate and to renew itself are vital to organisations or companies. The importance of these skills depends, among other, of the size of the organisation.

Such reasons are symptoms of a very deep and serious issue that will threaten the company or organisation over time.

Good reasons are indeed the cost reduction, keeping the focus on the company’s core activities and vital systems, freeing most capable resources to work on essential projects, using faster knowledge the company doesn’t master yet, temporarily having more IT people working for the company (hiring external consultants is an alternative) and transfer of some risks. These are probably not the only reasons.

Implications of outsourcing

Outsourcing a software project can be interesting, but it has some implications.

·         During the outsourcing of the construction of a software system, information is passed to the software company. Information is spread outside the organisation.

o   Information about the way the business operates and how it is managed. It gives some insight in the processes, the logic, the available information, the services, and so on.
o   Projects are a way to transform a company. Projects give some clue about the company’s strategy, its intentions and its focus.
o   It may give indications to the outside world, or at least to the software company, how well the organisation is able to manage projects, and thus its capability to evolve and to transform itself.

·         The client organisation loses some control over its own systems and processes. Usually, the knowledge about a system developed through outsourcing is smaller than about in-house developed systems.
·         Outsourcing a project provides some power to the software company. The software company that built the built software system has more knowledge of that system than the client company does.
·         The organisation may become dependent of external providers.

Consequently, as a general rule, outsourcing strategic projects - projects that determine the position of the company/organisation in the years to come -, systems dealing with core processes or systems containing critical logic should not be outsourced.

Outsourcing all the systems containing the core processes of business or outsourcing a major part of the systems is a very risky strategy.

The lesser knowledge the organisation has over its system, the greater is dependency of the software company(/-ies), the more it is vulnerable.

Who can do outsourcing?
The IT department has to decide whether it outsources or not a project. This department is responsible for the automation of the processing of information within the company or organisation. They are also responsible for the implemented systems. If the business community starts to define and build information systems, whatever the way they choose, they engage in shadow IT. This undermines the information processing within the company, the ability of the IT department to take up its responsibilities and to play its role fully, and, ultimately, it will undermine the company.

Selection of the offshore software supplier
Selecting the right software supplier is a crucial step. Establishing the required criteria and doing research may help. The software supplier should preferably have experience in the technologies expected to be used, in similar projects, in outsourcing or offshore projects and in similar methodologies as those used by the client’s organisation. The availability of sufficient resources is another factor that may be considered. Guides about the selection of IT suppliers can be found on the web.

What phases of a project can be outsourced?

Analysis activities can be outsourced. This includes the elaboration of business case or any other type of preliminary analysis. It is favourable, but not mandatory, that the analyst knows the business area and the company. Actually, some consider not knowing the business domain or the company as an advantage. Their arguments are valid as well.

However, it is easier when the analyst can talk with many different stakeholders, organise interviews and workshops. It is very helpful that he or she is present on the premises of the company. Analysis is about acquiring knowledge and insight. The company pays an external person to learn to know the situation within the company. Later this new insight should preferably be transferred again to an employee.

The client organisation and the software supplier have a common goal until the contract is signed. But once the contract is signed, game can be different. The client desires as much value at the lowest cost and with the lowest risks and without glitches. And some suppliers may want to deliver the minimum that still matches the agreement and this at the least effort. Both want the project to be finished as soon as possible, but for different reasons.

The analysis may be too superficial, incomplete, ambiguous, inconsistent or wrong. Or it may respond to only a part of the needs or even to the wrong needs. If the agreement is based on this analysis, in the end, the supplier delivering the solution that matches the agreement will be paid. But the client will have to face the troubles and the higher cost. An inappropriate analysis creates disappointment on the client’s side.

Outsourcing projects require analysis that are more complete, consistent, unambiguous and more detailed.

It is a prerequisite that the product to be developed is well defined. A fairly higher degree of precision and certainty makes the project easier. Changes are possible, but they may be more difficult or costly to achieve.

A good analysis is thus critical and should be conducted by a professional analyst. This can be an employee or an external and impartial consultant.

The design is easier to be outsourced than the analysis. However, the company should ensure some things:

·         the design matches the analysis, fit the situation and solve the real problems and needs
·         the design must lead to an efficient functioning system
·         the required system’s qualities are built-in by design
·         the company understands the design thoroughly

Although, the design can be done by the partner, the company should master the design. A close follow-up is important. The design determines, for example, the scalability, the expandability and the flexibility of the system. A bad design may make the maintenance costly, making changes so hard that the company cannot make use of some opportunities, or may increase the cost of future changes.

Programming and Testing
Programming and testing are the phases that are the most easily outsourced.

It is beneficial that the software supplier follows coding policies of the client company and that the software code is well-structured, clean and efficient.
The client organisation should test the software when delivered. These tests should be more through than simple UAT’s. In the end, the client organisation is responsible for putting a software system in production. This means that outsourced software is tested several times. It is first tested by the supplier to ensure it does deliver working software that matches the demand. A part is retested as part of the UAT.  It is advised to test the software one more time by the client to verify and confirm it is working well and can be released to the production.

The delivery phase includes the handing over of software and documentation. But, at least as important, is the assurance that a maximum of knowledge about the delivered software is transferred. Without this knowledge, the delivered software is nothing more than a black box of which the functioning is assumed to be as described in the requirements or is guessed.

Project Organisation
The company should follow up the project, ensure the analysis activities, verify the design and establish, execute and verify testing activities. This means that the company should appoint persons to these roles. The software supplier is likely to have the same roles in his part of the project.

Responsibility of the company
The client company’s has to ensure that the project delivers a product that corresponds to its needs. That is its main responsibility. In the beginning of the project, the client company is responsible for the correct identification of the needs. During the execution of the outsourced activities, the client organisation must ensure the product the software supplier is building corresponds to what is agreed and suits the client organisation. And upon delivery, the client organisation is responsible for the hand over, for the acceptance, for further testing, for the implementation and for the transition. There might be some nuances in this list of responsibilities depending on the specific situation and agreements.

The outsourced activities can be considered as a sub-project within an overarching project. The company is responsible for organising this overarching project and organisation. Even though the sub-project is managed by the software supplier, the client company should follow up and control the work done by the software supplier.

Follow-up, Control and Transition
The outsourced project must be followed-up and controlled by project manager, analysts, architects and possibly some other roles assigned on the client-side of the project. This follow-up doesn’t concern the quality of the activity plan, the progress of the outsourced project or its resource usage. It is much more important to verify that the requirements are well rightly taken into account in the design, the suitability of the design, and so on. The software product should not be a black box. It should be at least a grey box. The client, and more particularly, its IT department, needs to know the architecture, the implemented mechanisms, the organisation of the source code, and so on. This is about the understanding of what have been established before programming, or in terms of layers of detail, the layer just above the source code. The client should have and should validate the analysis and design artefacts made by the software supplier.

Essential aspects
There are some factors that require much more attention in off-shore projects:

·         An analysis of high quality
·         A higher degree of formalism
·         Good agreements will avoid many misunderstandings, wrong assumptions, discussions and disappointments.
·         More and effective communication
·         An efficient way to follow-up the project
·         Good testing

A few issues to consider
Some issues are important to consider:

·         How does the software company react when there is a doubt about the specifications?
·         What are the agreements about handling changes of requirements or specifications during the project execution?
·         Is the software supplier ready and able to follow the client’s coding standards and quality levels?  How is this process of transferring, using these standards and the control of their compliancy organised? This includes documentation standards.
·         How is the integration of the new system in the existing IT environment solved?
·         How much knowledge of the delivered system is transferred and how is this organised?
·         What support may be needed and what can still be expected from the software supplier months or years after the product has been delivered?

Cultural Differences

There are differences among developers. When specifications aren’t clear for the developer, developers may react in different ways. Some will stop working, others will interpret the specifications without caring, others will try to understand the purpose and guess for the right interpretation and others will ask for clarification. There are differences among the company cultures. There are differences among the clients and the suppliers. With offshore projects, the cultural differences are even greater when the parties are from distant countries. Additionally, the most obvious practical barriers are the distance, the language and the time zones. And maybe the legal differences play a role as well. This makes offshore projects more complex.

Anecdote: An offshore software supplier had delivered demanded software and was partying. The client was testing the software and found a few hundreds bugs. They called the software supplier to ask for explanation. “We are testing the software you delivered and we found 300 bugs in it. This is inadmissible. The contract stipulates that you would test the software before delivery.” Software supplier: “You found only 300 bugs. We tested it as agreed and found around 800 bugs. So, you still have 500 bugs to find. Good luck.”

Starting with outsourcing
Knowledge and experience in outsourcing projects can be built up gradually.
There is a lot to learn of the experience of other’s offshore project. Much can be learned from failed projects. There is plenty information on the web.

An evaluation of the present capability in managing and executing software development projects is a key to first consolidate or strengthen this capability before engaging in outsourcing.
Nearshore is somewhat safer than offshore projects. Small and non-vital projects are better candidates to begin with. Gradually larger projects can be outsourced.

Good Luck with your projects!

Other Resources

Outsourcing Management Body of Knowledge (OMBOK)™
URL: http://int-iom.org/documents/OMBOK.pdf

IAOP - International Association of Outsourcing Professionals
URL: http://www.iaop.org/

IAOP - Outsourcing Professional Body of Knowledge™ (OPBOK)

Keywords: software development, project, outsource, outsourcing, onsite, offsite, onshore, nearshore, offshore, project management, CIO, strategy, IT strategy, shadow IT, ERP, IT department
©2013 by Axel Vanhooren. All rights reserved

8 Jul 2013

Types of Requirements

Business Requirements
Stakeholder Requirements
User Requirements
Program Requirements
Project Requirements
Process Requirements
Management Requirements
Enterprise Requirements
Solution Requirements
Product Requirements
System Requirements
Software Requirements
Change Requirements
Regulatory Requirements
Quality Requirements
Functional Requirements
Non-functional Requirements
Usability Requirements
Indirect Requirements
High-Level Requirements
Detailed Requirements
Information Requirements
IT Requirements
Data Requirements
Design Requirements
(non-)Technical Requirements
Testability Requirements
Security Requirements
Documentation Requirements
Implementation Requirements
Requirements Specifications

And there are many more  ...