**1. Introduction**

The organization of software projects management has long been the subject of research, the goals of which are to increase the efficiency of collective work and to support the quality of the developed products. Today, this area has developed as an independent discipline, offering various methods of managing software projects (commonly called methodologies), which have proved themselves in the practice of designing software systems. Among them are two classes of methodologies: rigid, also called heavy, or even monumental, and agile (accelerated, lightweight). The first prescribe to rely on the collection of the most complete set of requirements and their careful analysis, resulting in the construction of a seriated often call waterfall or an iterative development of the project (most of such methodologies can be found in [1]).

© 2016 The Author(s). Licensee InTech. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. © 2018 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

The latter abandon detailed a priori development planning and focus on the priority implementation of the vital needs of users (see, e.g., [2]).

Studies of problems of project management always pay attention to methods of organizing teamwork. As an illustration, it is appropriate to point out the bestseller written by F. Brooks [3], which shows that the problems associated with the division of labor in the project team and identified in the 1970s of twentieth century remain relevant today. Some specialists, noting that human resources (HR) are the main factor determining the success of project development, offer methods of accounting for it when choosing a methodology [4, 5]. At the same time, there are practically no recommendations on how to act as a manager when he/she does not have the opportunity to work with an established team with sufficient qualifications for the project. The peculiarity of this situation is the instability of the development team and the need for ad hoc design solutions. It is typical for start-up companies trying to organize their business for the implementation of a promising idea, but do not have the resources to form a full-fledged team that can act within the framework of solid methodological support, for example, in the style of the MSF (Microsoft Solution Framework) approach [6]. It is tempting to use the rules for organization of works like MSF, but the problem with most of these methods is that they are applicable only if the projects are executed by working groups of specialists who are not only qualified but also well organized in interacting with each other. This is not only a problem of the staff deficit, because of which it is necessary to employ outside persons. It often turns out to be impossible to ensure a constant workload of employees with the necessary qualifications, to provide them with comfortable working conditions and stability of wages. All this increases the risk of instability of the team.

In accordance with the Capability Maturity Model for Software (SW-CMM) standard, which is supported in numerous approaches to improving the software development processes that go back to the Paulk, Curtis, Chrissis, and Weber ideas (see [7]), instability of the command is usually considered as a characteristic of the initial level of the organization's maturity. The standard assumes that if an organization pretends to grow in maturity, it should strive to move to the following levels: repeatable, defined, managed, and optimizing by continually improving the design discipline. The standard holds that moving up the ladder of maturity makes the organization resistant to instability by developing not only the target products of the project but also documents reflecting the accepted discipline. In other words, the project team should gradually get rid of the influence of the human factor, which in its essence leads to a rigid development strategy, which all project developers are required to take.

We should note that when the instability of the team is objective, the maturity condition for SW-CMM is not achievable. However, this does not mean the impossibility of successful activity. The most notable example is outsourcing. If a manager gives the development task for an external executor as a closed proposal, if she/he composed this proposal exactly accurately and unequivocally, then the risk from outsourcing reduces to an acceptable level, and certain advantages be achieved. Nevertheless, the failures of unstable teams are possible and frequent, in many respects, they occur by the lack of suitable methodological support. In the proposed chapter, we discuss some fundamental aspects of the rational organization of the production process of unstable teams, the account of which allows the project manager to build a reliable methodology for the project activity.

The proposed material based on observations and analysis of the experience of several unstable teams, who managed to build their activities so that a better part of the projects developed was successful. The most significant contribution to this analysis made the information on the remote team that managed to determine the rules of work with external executors of project assignments during the development of a series of projects. A distinctive feature of this team is the great attention that it pays to training employees [8].

Today, communication tools allow organizing teams of performers working remotely. It has become quite common for them to be executed projects by outside performers, using e-mail, chat rooms, and teleconferences. This leads to teams with employees who may not even know each other. In most cases, remote commands are unstable. It is necessary to provide for special rules of interaction for them. We discovered this aspect of instability by observing the activities of the abovementioned successful teams. It largely influenced the approach of the project management, presented in the following sections.
