About time accounting in software development projects

In my work, I quite often have to discuss issues of approaches to recording the time spent on software development. Do I need to take into account the time for each task? Do I need to report every day? Are “timeshats” useful and what should they look like? Who should fill in the reports and when? Etc. Sometimes the conversation goes to the confrontation of Agile-methodologies and more rigorous methods of management.
It happens that such discussions turn into a dispute, confrontation of points of view, and end with a reconciling phrase: “Of course, each company has its own specifics and features, its own business model, and therefore its own approaches to resource accounting.” And this is right, because, by and large, the principles of accounting for resources depend on the business model, but I still want to gather in one place the accumulated arguments of different parties and approaches, and most importantly - try to make an “open article,” an article in the form of a dialogue, in the form of confrontation of arguments and points of view, which will be affected by the comments and voices of readers.
In my opinion, the various options are reduced to three basic approaches:

1. Accounting spent man-hours by tasks
2. Accounting for the implemented functionality (backlog / requirements) and the overall assessment of the cost of work
3. Creative work without a list of functionality and resource control

Let's look at the differences and arguments in the choice of approaches for the following aspects:

• actual cost estimate
• metrics for evaluating upcoming projects
• monitoring current projects
• team interaction impact
• individual performance, motivation
• getting rid of inefficient employees
• emotional state of employees
• implementation of routine projects
• implementation of complex, non-standard projects

We will discuss and oppose the first two approaches, because I cannot talk about the third. I had to work in different companies and in different projects, on different technologies and in different management schemes ...
And the most interesting, technologically complex and advanced, the most unusual projects were made on the third approach. It was about these projects that I talked about at interviews, it was in them that fundamentally new products were created, and not any boring routine of the type database → business logic → business processes → client presentations → reports. I am proud to work in these projects, remember with nostalgia, feel free to say “I made these architectural decisions”, and it is about these projects that people usually listen with great interest. But on the other hand, these particular projects were very expensive and economically dubious. Now I am not ready to give any arguments for or against such projects, therefore we will consider only two approaches:

Timesheets Time accounting for each task	Backlog Accounting for cumulative time spent on iteration and functions
There is a separate or integrated system of working time (Timesheeting), requiring employees to enter information about what it spent 8 working hours per day. Extreme case of detail You can call fixing the time spent at each stage of work on a task, or even a mandatory breakdown of costs for specific dates, if the task lasted more than 1 day. If Timesheeting is separated from project management, then accounting can degenerate until the second case, when the clock is “written off” to a project or a large high-level task.	The team has a requirements management system and a selection methodology. a number of requirements for implementation in an iteration. This could be a backlog, a list of requirements, requests for changes and defects, a SCRUM or Kanban task board, etc. ') The cumulative costs of the whole team for the iteration are taken into account, and a conditional assessment of the complexity of the requirements in storypoints or difficulty points can also be made.
Accounting for "routine", small tasks
There may be a special task “other work”, which occupies a small percentage of the working time for which minor works are written off. If a job is more than a certain threshold, it will be turned on by a separate task within a specific project. Minus : for the case of several projects, the contractor creates one task “other works”, which somewhat reduces the accuracy of the distribution of work.	Small tasks are taken into account in the total cost of the project. Doubts : the lack of accounting for small works simplifies the work, but there is a danger of “getting bogged down” in small work to the detriment of the main tasks. However, an assessment of the ultimate effectiveness of the implementation of planned functions provides sufficient control over the balance between the main work and minor, unmanaged work.
Evaluation of post-factum labor costs
For each task, real costs are known. A large amount of detailed data on the costs of work performed. The accuracy of calculating the cost strongly depends on the availability and quality of the method of summing up labor costs. The reliability of the estimates can be reduced , as the performers must mask the natural labor losses in the design tasks, and there are many opportunities for indirect distortion of the estimates. Plus: allows you to identify the most time-consuming tasks, the causes of labor loss, analyze the structure of labor-intensiveness. Plus : allows you to accurately assess the cost of implementation of individual functions after the fact. Minus : high additional costs for accounting.	Known total labor costs for the entire iteration. Calculates the aggregated cost of functions without detailing by subtasks. The accuracy of calculating the cost is quite high due to the natural inclusion of all actual work and losses. The reliability of the estimates is high , since the team does not need to detail or enter invented information into the cost structure. Doubt: analysis of the causes of labor losses is of a qualitative, but not quantitative, not formalized nature. Plus: low additional accounting costs.
Accumulation of data for evaluating future projects
Accumulation statistics of the initial estimate of the complexity of the tasks and final effort to implement high-level functions / scripts of use. For example, in simplified form, this will be a table in which for each level of complexity the average aggregate cost of implementation in previous projects is indicated.
The costs for all tasks are summarized on the basis of the data on assigning tasks to implemented functions. Plus: collected detailed information on all the works. Minus: since unforeseen works must be entered into the system for accounting, they cannot always be reliably assigned for accounting to the correct functions, which distorts the estimates.	The system has levels of complexity of the functions and the actual total costs of their implementation. Plus : the aggregated estimate includes the actual level of costs along with all the losses, which makes it possible to estimate future costs also taking into account the level of unavoidable losses. Note: for T & M projects, the task of accumulating ratings may not be relevant at all.
Monitoring the implementation of the project
It is possible to require employees to report daily on the hours spent on work, which allows for a detailed picture of the progress of work. Plus: it is possible to use instrumental monitoring of the development process. Minus : the accuracy of the data can be significantly distorted due to the need to mask losses, as well as due to the unwillingness to daily and to record in detail the labor costs.	Formal monitoring of the progress of the project is available only at the level of progress on the implementation of functions. A detailed course of work and information about problems is available only to managers of specific projects participating in daily “statuses”. Plus: high accuracy of information on the progress of implementation of the requirements. Problems in the project are easier advertised due to the emphasis on the ultimate goal of implementing the functional, rather than identifying and fixing in the timetracker causes and problems that are guilty.
Team interaction
The system of accounting of labor costs is individual and requires the allocation of the cost of the task for each of the developers. In the case of collective work on the requirement, it is necessary to separately consider the work of each in the form of separate tasks. Minus: the need for the contractor to distribute 8 working hours according to his tasks limits his desire to participate in helping other team members in their tasks. Minus : additional administrative burden for the creation of individual tasks, if necessary, a significant distraction to help in solving the problems of other people.	In the accounting system there is no need to create separate tasks during collective work on them. Plus : there is no obstacle between team members for redistributing efforts and providing assistance if necessary, since the final assessment depends on the implemented requirements of the whole team, and not on individual labor indicators. Plus : no difficulties in the accounting system when working together on a task or when transferring a task between executors.
Individual performance, motivation
There is the possibility of a formal assessment of employee productivity and employment. Possible monetary motivation scheme, proportionate labor costs. Minus : the presence of an incentive to distort performance data. Minus : the possibility of performance tampering. Plus : the possibility of using formal assessment methods, including methods of detecting fraud.	It is recommended to evaluate the effectiveness of the whole team, without highlighting individual ratings. Monetary motivation is based on a proportional division of the reward between team members in case of successful implementation of the stages. Individual assessment of each team member can be formed within the team in informal ways. However, it is possible to evaluate the effectiveness of the number of requirements implemented and their complexity. Plus : the complexity of performance tampering.
Getting rid of inefficient employees
Plus : there is an opportunity to get rid of an inefficient employee according to formal criteria at the level of system rules triggering, which significantly reduces the emotional burden on the rest of the team members. Minus : there is an incentive to distort and speculative use of performance data. Plus: an effective employee can protect his reputation, regardless of personal relationships and emotional hostility.	The team almost always sees inefficient employees, however, there are difficulties of a personal nature. The decision to oust the team is taken personally by the participants. Minus : high emotional load in case of need exceptions. Minus: the impact of interpersonal relationships. However, it should be noted that this approach allows you to form emotionally stable, healthy teams that do not face the stated minuses.
The emotional state of employees
Minus : there is dissatisfaction with the need to keep a constant record of time spent Minus : dissatisfaction with a sense of excessive control and the need to justify or hide every case of loss of working time accumulates.	Plus : an atmosphere of trust and creative freedom Plus : a feeling of teamwork and mutual help
Implementation of routine projects
Plus : tight control and pressure creates a passive attitude and allows you to force employees to work on routine, uninteresting projects with acceptable performance.	Minus : efficient, productive teams with adequate self-esteem, prefer to work on interesting projects. Can avoid routine projects until the abandonment of the company.
Implementation of complex, non-standard projects
Minus: tight control suppresses creative thinking, displaces bright and extraordinary people from the team, forming mediocre teams incapable of solving non-standard, ambitious tasks.	Plus: the lack of fixation on costs, the ability to search and try new solutions, creative freedom in the team and its focus on results, allows the team to successfully implement complex, non-standard, extraordinary projects.

Further in the first 10 comments I want to build a discussion of the topic on the listed aspects with the possibility of voting for specific approaches. Let's agree in the branches with voting for arguments to put only pluses, otherwise I risk picking up the minuses in the rating on the obviously negative aspects of the chosen approaches.
However, why else risk rating, if not for the research of interest. =)
PS Once again I draw attention to the structure of the first 10 comments: this is an experiment to create an open article with the rating of its individual statements and the collection of new arguments to supplement the article.
Naturally, no one bothers to lead a free discussion outside of these 10 comments.
Ideally, I see as a result an article with votes on the items and supplemented with the most neglected arguments.