**2. Features of the project team**

The latter abandon detailed a priori development planning and focus on the priority imple-

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.

of which allows the project manager to build a reliable methodology for the project activity.

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

mentation of the vital needs of users (see, e.g., [2]).

166 Management of Information Systems

Unstable teams of project developers can be built in different ways, but always the project executors in such a team are divided into three groups:


With constantly working developers, management problems do not usually arise—their reliability level is known. However, if there is a need to assume the optional developer involved, then the manager has to decide to whom and on what conditions it is possible to propose a task for the solution. The main reasons for this situation are as follows:

• Inadequacy of the capabilities of key and constantly working developers for the implementation of the project in an acceptable time.


The style of work of the project manager of the unstable team assumes a permanent search of outside employees involved to perform autonomous tasks. It is necessary to distinguish tasks that involve obtaining the results needed for the development of the project environment and such tasks, the implementation of which should contribute to the success (in all senses) of project development. The latter may be loosely associated with the project, and decisions about their announcement made, for example, for checking the employee. In any case, the autonomous task should be precise and contain an awareness of when, for what, and how the results obtained would be used in the project. In accordance with the answers to these questions, the project manager should formulate regulations of work both for the performance of autonomous tasks and for products received from third-party developers. It should be noted that the autonomous task must be precise formulated. It should contain pointing of when, for what, and how the results obtained are used in the improvement of project activities. When the formulation of the task assumes repeatable using of its fulfillment results, in addition to the usual work acceptance, a special analysis is required *before* and *after* its setting and execution. The first is planning reusing, and the second is the decision of adaptation the result to the project environment evolution.

Instability of the team most often leads to the fact that it is necessary to allocate resources to adapt the skills of employees to the requirements of the project. Primarily, this concerns constantly working developers who have proved themselves in the performance of assignments as potentially effective participants of the project. Do not neglect the need for training and optional developers involved. Even in cases when they have the skills and experience necessary for the project, the autonomy of their work does not promote the growth of their status to constantly working developer and even more so to a key developer. Activities aimed at, on the one hand, the study of the feature of the project being developed, and on the other hand, the acquisition of common skills and experience, needed to support the process of stabilizing the team. These activities must necessarily be provided for when the project developers seek to become a mature and stable team. At the same time, one cannot ignore that training, as a rule, is very expensive and therefore may not be profitable in the current project situation.
