Developer in the project management triangle

Two approaches are outlined that potentially allow an objective assessment of how far the developer’s work on the project meets the requirements of quality, time and budget.



Project management is the organization of the process for successful, that is, for the allotted time and without exceeding the allocated budget, to achieve the goal. In this case, the final product must possess the properties specified initially and be of acceptable quality.



In many cases, it is necessary to find a balance between the time, cost and content constraints of the project. A very graphic illustration is the design triangle, (the picture is because the three sides of the triangle are connected, and the change of one side affects at least one of the other two sides, demonstrating the process of balancing constraints).

')

As an example, consider the situation when you want to shorten the deadline for the project. To do this, you may need to increase the budget and use more resources, with which the same amount of work will be completed in less time. If the increase in the budget is unacceptable, it is necessary to reduce the content of the project, since with cash resources it is not possible to complete the entire planned scope of work in less time.







Creating, within the allotted time and within a given budget, quality software that meets the real needs of the customer is a process that can and should be described in the project management language. The developer is one of the key roles in this process. It seems to me that it is fundamentally possible to evaluate the developer’s professionalism if one systematically evaluates the results of his work from the perspective of how well they correspond to the threefold limitation.



Ideally, each task that is assigned to the developer should be solved so that:

1. the time of work did not exceed the time of preliminary assessment of the duration of this work,
2. code quality met predetermined criteria and standards
3. the cost of solving this problem did not go beyond the allocated part of the budget.

Naturally, the imposed restrictions must be adequate, both in terms of generally accepted standards, and with respect to the capabilities of the developer himself. (But the discussion of this issue is beyond the scope of this article, and by default we consider that each task, according to the solution of which the developer’s professionalism is assessed, is correct and does not have extremely excessive demands).

Why do we need this?

1. Increase HR performance.
   
   Objective, as far as is generally possible, the criteria of developers' professionalism could, for example, help the HR manager to select the performers who best fit the requirements for this project for a specific project. Developers themselves, having the ability to objectively compare their abilities with the abilities of their colleagues, could more clearly understand the qualities they should work on in order to increase the demand for their work and improve their rate.
2. Satisfied customer.
   
   In addition, the introduction of the use of objective criteria of professionalism is beneficial to the customer, because from his point of view it improves the quality of material and labor resources management, thereby increasing the overall quality of business management.
3. Low cost, relative to expected effect.
   
   The price you have to pay is not too burdensome: increasing the requirements for discipline and accurate data collection and processing.

But the formation of such criteria requires a strong formalization in the description of the development process. By the current moment we have two ways outlined. They differ in the approaches to two of the three sides of the project management triangle: time and budget. Before turning to these differences, we very briefly describe the idea of ​​our approach to quality assessment.



In addition to the standard QA methods, it is intended to obtain code quality metrics using static analyzers such as SonarQube . I think that this data can be quite correlated with the results of each developer’s work in the project, as well as to evaluate any parts of the project and the project as a whole. It is possible that an additional parameter assessing the quality of the developer’s work will be the ratio of the time spent on solving the problem to the time spent on correcting the related bugs.

Now about two possible approaches to money and time

The first look at this problem is based on the fact that it is far from being possible in all cases to have all the initial data . In general, for calculating indicators related to hitting the deadlines, the following are necessary:

• assessment of the task in hours of the developer who will be engaged in it (previously agreed with the developer himself);
• data on how many hours were actually spent on this task (this requires a time tracker);
• due date due to which the task should be ready.

It should be noted that, as a rule, the task can be considered completed after several people have worked on it, at least the developer and tester, which implies adequate planning of their working time and their smooth interaction during the work on the task. A detailed study of all these issues deserves a separate article, but the most important thing is that in this approach all values ​​that can be measured in hours, days, etc., are related to indicators of time.



Regarding budgetary characteristics, this approach considers three project options from the point of view of pricing:

1. Fixed cost project does not imply a deviation from the budget characteristics in principle.
2. The Time and Material project means that the cost is linearly related to the hours spent, which means that deviations from the budget are identical with deviations from the deadlines. Thus, in these cases, there are virtually no budget metrics.
3. With a lax fixed cost project, in which it is possible to coordinate budget changes, it is potentially not clear which part of the budget change should be attributed to the “merit” of a particular developer. In general, this approach means that in the project management triangle for an individual developer, budget figures cannot be adequately displayed, and only the quality / deadlines remain.

The second glance suggests that part of the time metrics be counted on budget figures. Hitting the dates here is measured using calendar dates - Start date, Due Date, Actual Date. Specifically, the time metric can be measured as the number of dead dates per task, or as the ratio of differences between Start date / Due Date and Due Date / Actual Date. The budget indicator is based on a preliminary assessment of the time and the actual time spent on the task. The budget discrepancy here is supposed to be calculated as the average deviation of the elapsed time from the time of evaluation.

In connection with all the above, a few natural questions arise:

First, which of the two approaches, in your opinion, best describes the professionalism of the developer in the context of meeting the deadlines / budget / quality? And what options besides the design triangle could one use?



Secondly , I would like to understand whether it is possible to correlate budgets in money with estimeyta and really spent hours in tasks? What are the dates and do they relate to estimeytam or to the Start date and Due Date?



Is it possible to take into account differences in projects in terms of pricing approach (fixed cost, time and material, other options) when calculating the budget metric for a specific developer, or does it only make sense for the fixed cost approach?



Thirdly , it is interesting how correct it is to use a model that illustrates the objective limitations arising in project management for a quantitative description of the developer’s professionalism?



I will be glad to hear your opinion on this matter!