From Russia with CAD
Home News Articles About in Russian

All articles

Articles

23 Apr 2020

How to Outsource Your Software Development Project Successfully. Part II

David Levin

In the Part I of this article:

Preface
1. Four characteristics of the relationship between service providers, customers, and projects
2. How Big Is the R in Your R&D Project?

3. Ten Steps to Success

Outsourcing a project is effective only when customer and service provider understand each other well, as well as agreeing on the responsibilities carried by each. Here I prepared a list of qualities that both parties should agree on before entering into a contract.

1. Capabilities necessary for software development

Outsourcing service providers are obliged to post on their Web sites information about the team�s capabilities, technologies, and skills. Customers, however, cannot always fully evaluate how relevant this information is to their projects. This is especially difficult for customers when it comes to capabilities that are largely scientific or require special applications in solving broad classes of problems.

2. Success stories

Service providers strive to mention the names of previous customers associated with success stories. Potential customers, however, never have access to the reality of �success� stories from potential development partners. Customers tend to prefer to keep quiet about how successful their project turned out, or even that it had been outsourced. In spite of learning hints or even getting the full details, such stories are hardly reliable indicators for evaluating a provider�s success in completing new projects.

3. Project organization and effective maintenance

No amount of technological capability is helpful when contractors are not able to organize projects. The situation is hardly improved when contractors do have experience in organizing development projects, but then acquire customers who do not understand the unique approaches of software development.

It may become even worse with the customers who have proven to themselves that they are successful in managing processes in their own industry using the waterfall approach. They may mistakenly think that software developed in agile mode demonstrates a lack of discipline, and that the agile approach will ultimately be destructive to their project. It is difficult to convince them that large and knowledge-intensive software projects are almost impossible to implement in pure waterfall mode. Customers, who believe that any deviation by the contractor will entail chaos and failure, may try to transfer their in-house approach to the custom software project aggressively.

4. Effective communication

A permanent and effective channel of communications between the customer and the development team is crucial. Qualified contractors tend to be more interested in regular communications than do customers.

Serious projects are accompanied by multiple updates, because an exhaustive specification at the start of a project impossible. As well, customers� production environments inevitably change during implementation. Experienced contractors understand that constant reporting tracks problems that may arise. Regular communication solves conflicts as contractors receive feedback from customers.

As noted earlier, LEDAS improved its skill in professional project management and related communications through multi-year contracts with Dassault Systemes. These skills allow our team to proactively establish a proper level of communication with customers who may not as sophisticated in organizing software projects.

5. Quality control

Quality control (QC) is testing part of the project process, and relies on communications maintained between project partners. Not every customer is familiar with professional QC methodologies. In software engineering, it involves two-way access to the project database, maintaining and organizing regular work with an adequate test base, effectively responding to deviations from the stated quality metrics, and so on.

Oft times, only the customer can provide the adequate number of tests, which sometimes can be rather difficult to construct. On the other hand, customers do not always recognize the need to work cooperatively through a shared database of meaningful tests. Without this, the project cannot be carried out at the proper tempo and level of quality.

A competent contractor is no less interested in quality control than the customer, as professional quality control is the only means of objectively assessing the development�s progress and final result.

6. Initial phase of cooperation

When customers decide to go ahead with outsourcing a complex project, selecting a reliable outsourcing team is not possible by studying only Web sites for information. The more reliable method is to ask each potential partner to perform a preliminary analysis of the task, and then to have each outline their plan for implementation. Depending on the scale of the project, this phase may take two to eight weeks and involve two or three discussion sessions.

Even though some customers may not have the appropriate technological background to assess the potential outsourcing partner, the experience they have in their field will likely be sufficient to assess the effectiveness of the prospective outsourcers.

During this phase, the contractor in turn also assesses the prospects of working with the customer. It must be understood that if the contractor considers the customer to be incompatible, the project is unlikely to be succeed. There are some cases where one of the partners recognizes the poor compatibility, but nevertheless hopes everything will in the end work out, somehow. It will, in fact, likely end badly. Or very badly.

When a lengthy complex job is undertaken, a pilot project is inevitable. Pilot phases are rarely mentioned in information you find online about outsourcing. Neither is it ever mentioned that this kind of investment by customers can be risky. It seems strange that when you plan to invest millions that you should skimp on spending tens of thousands to see if the project is at all viable. Miser pays twice. Or loses a lot.

7. Protection of intellectual property

Perhaps the fundamentally most important point to outsourcing is the intellectual property belonging to the customer. Competent contractors understand the concerns customers naturally have on this issue, and so are prepared to sign the legal documents related to non-disclosure agreements.

Throughout the negotiations, contractors also have the right to defend their interests, without violating the rights of the customer. For example, a tough customer might insist that the development team never again participate in a similar project for any other customer. Contractors should negotiate a reasonable limitation, say, of five years.

8. Managing the exit

A legal outsourcing agreement includes the contractor�s obligation to transfer to the customer all the information the customer will need to work independently with the newly developed software. Obligations include know-how, technical documentation, and the code annotated in detail.

9. Maintenance of developed software

Once a complex software project is complete, professional service providers usually consider post-production maintenance and additional development as natural next phases. Supporting the life-cycle is also assumed to be the next phase for many outsourcing contracts.

A problem arises when customers are not sufficiently familiar with problems that inevitably occur after project completion, even in software systems that have been formally debugged and adopted. They may underestimate the amount and the cost of quality support. Some customers believe that maintenance no longer needs the higher level of expertise required during R&D, and so replace the original development team with another one that costs less.

10. Cultural differences

Cultural differences can occur when customers and contractors are on different continents. My remarks are based on the experience of LEDAS, which in its business and human characteristics works more like Western culture.

One way to look at this issue is by means of low- and high-context cultures. Low-context culture is considered inherent in the West. It is characterized by direct, explicit, and unambiguous communications; the context necessary is low. The second form is associated with the East, in which communication is carried out with a preference for implicit and non-verbal means; a high level of context is necessary.

Roughly speaking, the low-context culture in the West trusts words and facts more, while the high-context culture of the East focuses more on emotions and trust. The contrast between the two is somewhat simplified, especially in the era of globalization. Nevertheless, it reflects reality and so it needs to be taken into account when establishing partnerships.

If you are a software outsourcing provider for whom the culture of the West is deeply organic, you should be prepared for problems when communicating with an eastern customer. On the other hand, while �East is East, and West is West,� the West itself is far from culturally homogeneous, and individual human quirks can outweigh differences in culture.

Cultural differences should not be ignored by developers and no less than by customers. If you, as a customer, have a high-context culture and consider it obligatory at the beginning of a project to have a detailed description of every small stage, you are laying the foundation for future conflict. You invite failure by hiring an outsourcing team for which agile is the only acceptable form of project management.

Appropriate backgrounds and acquired ethics allow both sides to constructively respect the other culture, and so achieve a reasonable compromise while working cooperatively. In any case, being involved for long periods in a joint effort creates high levels of trust between partners. The trust built up eliminates cultural differences significantly, and ends up becoming a factor decisive towards the project�s success. Integration and cooperation between different cultures may even be especially advantages in generating great results!

The LEDAS office, see more here

4. On the Fair Price of Custom Software Development

The prices charged for software outsourcing services are typically based on just two considerations: the region where the contractors are located, and roles in the development team. Paying a lower cost and contracting a large team does not guarantee success. Rates for teams working in the East are radically different from rates in the West. The rate for a competent system analyst is also radically different from ordinary programmers of the same team.

While researching pricing, I found no correlation between rates and the nature of the task facing the customer. My review of worldwide rates gave me the impression that the only considerations are projects with hard deadlines and ones that implement a single, well-defined task, at least initially. But in fact projects that develop according to a detailed task specification have little in common with the implementation of the initial idea -- that of creating a competitive (or even unparalleled!) product capable of adapting to the market over a long-life cycle.

When customers want to implement complex projects without having the competence and skills to define its objectives but have sufficient financial capabilities, then the correct strategy for them is to attract a competent development team by offering a very high rate. (See quadrant 3 in Part 1 of this article.) Otherwise, the customer risks becoming a character in the proverb, "Miser pays twice," or else lose the chance to implement a brilliant idea.

About a decade ago, a Western company known for its CAM products decided to replace its system as it had become outdated. A large team, from a country famous for low outsourcing prices, was invited to work on the project. After a year, it became obvious that the team could not cope with developing such a high-tech solution. The project came to a standstill as the customer urgently looked for a replacement developer. It paid a significantly higher price to contract a firm that had the ability to solve difficult tasks, even though it used smaller teams of developers but who had the appropriate level of capabilities. Since then, the CAM firm has become a regular customer of LEDAS.

So, the real price depends on numerous factors determined ultimately during the negotiations phase when the objectives of the project are refined. Nevertheless, when searching for an appropriate outsourcing team, customers will definitely be guided by typical regional pricing and the reputation of the developers from that region.

For your reference, the price of LEDAS services is determined as follows: Generally, the qualifications of our team in the field of engineering software correspond to the qualifications of software teams found at the world's leading companies, such as developers located in the environs of Boston USAs. Yet the LEDAS price is far less than that charged by USA-based developers.

Some of the LEDAS competences