From Russia with CAD
Home News Articles About in Russian

All articles

Articles

22 Apr 2020

How to Outsource Your Software Development Project Successfully. Part I

David Levin

Preface

This article is on understanding the custom software development market. It is based on the experience gained by LEDAS, a company I co-founded in 1999.

For two decades, companies have outsourced their difficult engineering software projects to LEDAS. They found in our team an effective balance between in-house and external capabilities. We have the ability to deal with innovations, engage in high-level communications, are reliable, offer reasonable pricing, and provide solutions of quality.

These are the advantages that LEDAS has formed over its 20-year history. The knowledge-intensive industrial software development projects we carry out have been highlighted by twelve continuous years of contracts with Dassault Systèmes, the largest CAD software vendor in the world.

For more information about LEDAS see our company web site, in particular the post �How LEDAS Solves Hard Engineering Problems�.

About This Article

As I began writing this article, I had in mind to review the criteria for successful outsourced projects that you might read on the Web, and then to illustrate my view with examples from the experiences we at LEDAS gained. The criteria for success typically come down to the qualities of the software development service should have. From my point of view, such criteria are one-sided as they suffer from two defects.

Firstly, custom software development is a joint project between customer and contractor. Its success depends on the capabilities and qualities of both sides, as well as on an optimal distribution of responsibilities between them. When discussing what makes an outsourced project successful, you must also consider the qualities of the customer.

Secondly, outsourced projects differ very much not just in the subject matter and scope of work, but also in the volume of research needed to carry out projects that are innovative, with extreme conditions for performance, and ones with very specific requirements. This means that the volume and specifics of the research required need to be considered, along with other success metrics in custom software development.

When it comes to determining rates for outsourced software development, oft times the economic level of the region in which the service provider is located is practically the only parameter used to set the project�s budget. However, the complexity of the project and the actual capability of the customer to himself implement a critically important project can become decisive factors.

In this article, I review the conditions necessary for successful custom software development by delving into the attributes of customers and project complexity. To date, the article consists of the following sections:

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
4. On the Fair Price of Custom Software Development

Sections 3 and 4 are placed in the Part II of this article.

1. Four characteristics of the relationship between service providers, customers, and projects

After providing outsourced software development services to the global market for more than 20 years, LEDAS has accumulated a lot of experience in dealing with different kinds of customers and their projects. Based on our experience, here I outline four kinds of project types by means of a quadrant.

Case Study Quadrants

Let me begin by distinguishing between two primary groups of projects:

A. Substantially experimental projects that require deep research that possibly even involve inventing brand-new algorithms and architectures. I characterize these projects as innovative, and so I call them �complex projects.�

B. Standard projects that can be implemented with common algorithms. These do not involve new knowledge, yet the task of assembling the program code may be complex. Such projects are referred to as �straightforward� ones.

The quadrants below illustrate the relationship between project complexity and the capabilities of customer and the service provider. (See Fig. 1.) I use parameter L to denote the capabilities of customer C and service provider P in organizing and maintaining software engineering projects, as well as conducting research and development.

Fig. 1

Quadrant 1: Simple-Low
Quadrant 1 corresponds to simple projects from customers who have a low capability in effecting software development on their own � the inexperienced customer.

Quadrant 2: Simple-High
Quadrant 2 also corresponds to simple projects, but from customers with a high ability to carry out their own software development � the knowledgeable customer.

The LEDAS portfolio contains a few cases that belong in quadrants 1 and 2, possibly because potential customers may see our company as one that specializes only in complex projects; they may then assume we charge high rates.

So it is worthwhile noting that simple projects are attractive to outsourcing teams, like ours, when, for example

The project is a large, long-term, and sustainable
The customer is interested in having a more advanced version of his solution developed next
The overall cost of the project is acceptable to both parties
The customer shows he has a high level of trust in the capabilities of the service provider

And there are other factors that may also come into play.

In any case, competent software development providers, such as LEDAS, never reject inquiries from potential customers without studying the projects� specifications scrupulously.

Quadrant 3: Complex-Low
Quadrant 3 corresponds to complex projects from customers with low capabilities in doing their own software development.

An example of this kind of project we took on was a multi-component cloud-based system for BIM (building information modeling). The project was offered to us by a large international construction company at an estimated cost of 30 man-years of effort.

This case study demonstrates the advantages and disadvantages to this kind of project. The client trusted our reputation as a service provider, and so assigned us this large project that was strategic to them, and paid us very well for the work. Despite the client being very successful in its field (building construction), the firm had only a vague idea of what software engineering involves. With the best of intentions, the client tried to apply its industry�s procedures to the completely different field of software development. As a result, the client at times thought the project was veering off on an incorrect course.

Nevertheless, the end-result of this ambitious project was valuable to the customer. The experience was valuable for us, as the man-years we spent working on it enabled our staff to accumulate a host of capabilities in an industry that was new to us. Today, BIM is one of the fields greatest in demand and is considered globally one of the most promising industries.

Some of the LEDAS competences in AEC/BIM, see ore here

Quadrant 4: Complex-High
Quadrant 4 consists of complex projects offered by customers who themselves have a (very) high capability in software engineering. This quadrant is characterized typically by a good mutual understanding between the partners as to the planning required and the estimated cost.

An example that illustrates this kind of project was the series of contracts offered to LEDAS by Dassault Systemes. From the very beginning, the customer considered LEDAS as a team operating with a high level of capability, both in software engineering and in mathematics. The continuous partnership (estimated as 100 man-years) with the world leader in CAD/PLM brought to our team a tremendous amount of experience in developing complex software. Just as importantly, LEDAS attained the ability to organize and manage software projects at an industrial scale.

Dominique Florak, Dassault Systèmes, Senior Executive Vice President,
Products, Strategy � R&D, in the LEDAS office, Novosibirsk, 2004

Today, almost all outsourcing projects of LEDAS are of complex-low and complex-high types. Among the latter case, there is a big and long-term one which by complexity of its tasks and qualification of a customer can be compared to the projects with Dassault Systemes. This experience successfully confirms all specifics of relationships between a customer and provider related to a complex-high type of a project.

2. How Big Is the R in Your R&D Project?

Complex projects usually require sufficient research. Here I describe the role that research plays in software development.

The process of building a software system is referred to as research and development (R&D). Research is done first, and then the software is developed.

Research is the initial stage during which new methods, algorithms, and architectures are selected or invented. Following the results of the research stage, development is the programming/coding stage.

All projects involve at least a small amount of research, but as a project becomes more complex, the bigger the research stage needs to get. This is illustrated by the simplified graph below that shows how the research (R) part in R&D depends on project complexity (C) during development (D).

Fig.2

Waterfall Projects vs. Agile Projects

In simple projects, the R and D stages tend to not intersect; they take place sequentially. We begin by conducting comprehensive research, and then fix the details of the project. Following strictly the agree-upon specifications, we finally immerse ourselves in coding, which needs no more research.

More commonly, however, projects consist of repeated research and development stages. As we complete one step, it is no longer considered. This basically is the approach that corresponds with the waterfall style of software development, although my description may be somewhat of an exaggeration.

In most real-life projects, we find that the workflow from time to time returns to the research stage, resulting in repeated redesigns of the code. Additional research is often required to optimize the next step in coding. The research itself may at times require reconsideration because of unexpected results from new tests. The fact is that as you develop a complex system it is almost impossible to fully envisage the influence of subsequent stages on the development, until this influence reveals itself in extensive testing. This scenario corresponds to the development style known as agile.

It is not the case that returning to the previous stages of research is inherent in all software projects, but many experts and developers believe that agile development is definitely the best possible approach to non-trivial software development.

A problem may occur when customers, who are not familiar with the particular ways of software engineering, incorrectly perceive that the agile working style is a result of poor planning and a lack of discipline. Such a customer may become unhappy upon learning that code that has been considered completed and debugged, needs to be reworked. Such a client may come to the conclusion that the project is going poorly. This is not the case.

Research, Quality, and a Strict Timeframe

The quality of the software being developed depends on how well the research stage was carried out. When projects lack effective research, the solution can't be made sufficiently scalable, extendible, or reliable, nor demonstrate high performance.

On the other hand, since timeframes of projects are always limited, the research phase cannot be unlimited; it needs to leave enough time for high quality coding. This means that research should stop at a reasonable point in time, even when the research group claims that a few more months of work will bring unbelievably outstanding results!

When considering timeframes, there are special cases. For example, research could well show that a particular branch of a project -- or even the project itself -- is at a dead end. Terminating the project early results in saving a lot of resources.

In a counter example, research might reveal new, unexpected approaches. In this case, it makes sense to extend the direction of research with the assistance of a special team, possibly a small one. The new business prospect may turn out to be more valuable than the original proposal.

Fig. 3 shows a simplified chart of how quality Q changes as the volume of research R increases.

Fig.3

Research and Optimization of Timeframes

For sure, every customer would prefer to minimize the time it takes to implement a project, provided that targets are under control. In this regard, consider a well-known methodological illustration shown in Fig. 4:

Fig.4

In this chart, the green curve illustrates a project with great attention to stage R, while the red curve corresponds to a project in which the role of the research was underestimated. The total time for each project is the area under each of the graphs. We see that underestimating the amount of research needed can lead to a significant increase in the time to complete the project.

This picture is very simplified (deliberately grotesque), as it does not illustrate the more complex relationship between R and D in, for example, typical agile-style developments, as I discussed earlier.

The considerations I address are purely qualitative. Quantitative assessments can hardly be justified for real-life projects, and so decisions on the specific balance between project parameters can be made on the basis of capability, experience, and mutual trust of participants -- albeit taking into account certain methodological points.

Aspects to Research

The domains of research are multifaceted, as they include

Selection and development of optimal methods and algorithms
Decomposition of complex problems into modules, areas of knowledge, and data representation
Rationalizing the use of specific development tools
And more

Certain sections of mathematics (computational and discrete) and a range of software engineering methods can be involved in carrying out the analysis, as necessary.

In the most advanced stage, research adds system analysis to the problems needing solving. It assists in turning a preliminary and even vague statement of the design problem into a detailed and constructive implementation plan. Such a transformation assumes dialog between consultants and customers and performing some experiments when necessary.

When faced with knowledge-intensive projects requiring innovation, previously accumulated competence does not, unhappily, guarantee success. For high-end software development, the effectiveness of developers depends substantially on their ability to promptly detect when new capabilities are needed, and then to master them. Such an ability is closely connected to the talent, creativity, and foundational background of each employee.

In the Section 1 of this article I have mentioned a successful project from the field AEC/BIM. This field was initially rather new for LEDAS but today brought to our company one of its key competences . Digital medicine is an even brighter example of a successful and energetic mastering of a new field. See Digital Medicine Drives LEDAS 2019 Revenues 20% Higher.

Some of the LEDAS competences in Digital Medicine, see more here

Nearly all of the success stories found on our site are characterized by a high research component. But to present details of the research processes used for industrial projects is a difficult task � never mind that the research constitutes substantial know-how proprietary to the customer, as laid out in our contracts.

I can, however, mention one example of a project that needed a large gathering of research. One of the most important components of a CAD system is the geometric constraint solver. It involves complex algorithms, and so in the early 1990s the field was monopolized by British company D-Cubed, now a division of Siemens Digital Industries Software (formerly Siemens PLM Software). But in 2001, LEDAS began to develop its own line of geometric constraint solvers for 2D and 3D geometry, which we called LGS 2D and LGS 3D. See Fig. 4. We successfully brought LGS to the global market, and it was licensed by dozens of CAD companies in USA, Europe, Japan, Korea, China, and Russia.

Fig. 5. Examples of 3D geometric constraints in action

To learn more about what geometric solvers are and to get further impressions of the research involved, feel free to continue reading our story �LEDAS Has Developed Five (!) Constraint Solvers� published on our company blog.