Evaluation of labor costs of a software development project: practice in the Ukrainian reality

Introduction

By writing this article, I pushed the not so long completed project. As in any other project, there were mistakes in it (including the evaluation), problems and interesting solutions, and, in spite of everything, the team’s morale, and the desire to turn in the project during, and processing delivery of the project on time, and the long-awaited vacation. All this is worth a separate article. But the main thing was the invaluable experience on the basis of which this article was created.
Very often, we evaluate the project and are greatly mistaken. And it seems to be because of the little things that appear in the course of the project, but which, in reality, could have been discovered and taken into account in advance.
The article contains simple and at the same time useful recommendations and a method for calculating estimates of labor costs for projects and will be of interest to project managers, architects, system analysts, IT solution vendors and everyone else who is involved in evaluating work on fixed-price projects.
In the article we will deal only with the assessment of labor costs for working on a project, the assessment of the duration of implementation and cost is a completely different story.
In the article, I describe my personal experience in evaluating projects, and,
of course, you could have other situations and your methods and
evaluation recommendations.
For a greater understanding of the essence, meaning and "spirit" of the article, I recommend first reviewing:

the speech of Sergey Martynenko “Writing tests as a type of testing requirements” [1], which I will often refer to in the course of this article. It is important to understand that properly formulated goals and requirements are a big and crucial step to the success of a project.
and presentation of Sergei Berezhnoy
“My Story:“ The Way of Overtime ” [2]. By and large, this presentation to the topic of the article does not have, but is related to incorrectly estimated labor costs.

The article contains the following sections:

Ukrainian reality in the implementation of the project
Problems and solutions
Preparation for assessment
The list of works for evaluation
Evaluation of writing code
Practice numbers and coefficients
Calculation example

Ukrainian reality in the implementation of the project

In the domestic market, projects with a fixed price prevail (when the budget and deadlines are planned in advance, at the conclusion of the contract). When evaluating a project, the team, in addition to standard risks and problems, should take into account the “modern and effective” approach of customers who want to combine:

On the one hand, obtaining accurate estimates of the budget and the time before writing the TOR, their inclusion in the contract, and further, during the implementation of the project, tight control of this budget and deadlines.
From the second - flexibility on the part of the development team, the implementation of all customer requirements appearing in the course of a project (since the customer often does not know what he wants until the middle of the project).
On the third, despite the misunderstanding, what and how should be implemented, mercilessly "cut" the tasks of the project plan (to reduce the cost), including the functions that the team will still have to perform.

In case of unsuccessful project management (if the team is led by the customer), the team easily exceeds the time and budget, because the contract is signed and the budget is agreed, then the loss works.
It is clear that blaming only the customer for everything is wrong. It is necessary to understand that a project assessment is often carried out without sufficient analysis of requirements, tasks are insufficiently and incorrectly written, and very often, only programming is included in the assessment, testing and management are not sufficiently taken into account. When signing a contract, sellers go to meet the customer, reducing the price, and during the project, the team does not sufficiently firmly defend its position (the project manager first of all, but in this case it’s worth saying “team”, because all participants should aim at the result and in the event the participant sees / anticipates the problem should inform her supervisor).
In addition, there is another factor - the diversity of projects, systems and technologies, and the lack of qualified professionals. This means that when planning a project, an architect or project manager may not take into account that they can get a specialist in the team who has not previously performed similar tasks or who has not been qualified enough. It is clear that in this case, the performance will be lower than expected.
How can you do in this situation? How to evaluate the project so that the estimated labor costs are sufficiently accurate?
For a start, it is worth considering the problems and trying to find their solution.

Problems and solutions

1. The customer wants to know the exact figures on the cost and timing of the project before signing the contract

Decision:
1.1. Identify and formulate acceptance criteria. How to do it? See [1]. The bottom line is that the customer needs to ask the right questions: “How do you know that the project is successful?” And “Who will hand over the system to whom and how?”, As well as the person who will make the decision to get an answer to the question “what you need make the project be accepted ”
1.2. Identify as many requirements as possible and, most importantly, limitations to the project (i.e., not only functional, but also non-functional requirements)
1.3. Test requirements. In simpler language, it is required to check that the written requirements are realistic, consistent, and formulated in such a way that it is possible to unambiguously check whether the solution corresponds to them. Again, I recommend to watch [1]
1.4. Based on this, write as detailed as possible a list of tasks (see further in the article)

2. The customer wants to see a more or less detailed list of work, which, when agreeing on the cost of the project, cuts the most inappropriate ways as soon as possible.

Decision:
In terms of work, it is important to single out all the tasks, not just the "visible" ones.
For example, there are user requirements for viewing certain data. The team identified which tasks need to be implemented and estimated the total amount of work at 56 hours, breaking them down like this:

The ability to view all records - 8 hours
The ability to filter by field 1 - 8 hours
The ability to filter by field 2 - 8 hours
sorting by field 1 - 8 hours
sorting by field 2 - 8 hours
grouping by field 1 - 8 hours
grouping across the field 2 - 8 hours

But in reality, these tasks have basic functionality - creating tables in the database, stored procedures or views for the sample, creating business objects, connecting them to the security module, connecting to the logging module, configuration, and so on.
What will happen if the customer says: no, this is too long. Let's reduce and remove tasks for grouping and sorting (minus 32 hours). In this case, the seller who discusses the work on the project "there is nothing to cover." On the other hand, in 24 hours, the entire volume is not in time in principle.
Therefore, I recommend highlighting the basic functionality, which can be removed only by removing the entire task. In this example, this task “Retrieving data from a database” takes, say, 28 hours, and the remaining tasks, 4 hours each.
This will allow the auction to more properly behave the seller, not substituting for the same team. By removing unnecessary features, there will still be enough time for development.

3. A detailed analysis of the requirements, the writing of the TZ and a more or less clear area of work on the project occurs after the signing of the contract

Decision:
3.1. Identify as many requirements and constraints to the project that you want to implement in the system and how to correctly formulate and verify each requirement [1].
3.2. Very often it turns out that the items that the customer has removed, still pop up and have to be done, and therefore, to protect themselves, in the contract, in addition to the project plan, you need to make a clause restricting the scope of the project. It should include all the items that the customer has removed from the proposed plan, as well as other items that the team sees and considers as clearly beyond the scope of the project. All software development methodologies emphasize this. In fact, this may be issued as an annex to the contract or as part of a technical task.
3.3. It is very important to determine the work that must be done by the customer. It is also required to be fixed in the contract (annex to the contract, technical task) with an indication of the deadlines for implementation

4. Almost until the middle of the project, the customer himself does not know what he wants (not to mention the requirements gathering stage)

Decision:
4.1. Include a time frame for possible changes (i.e., at what stages of change are, in principle, possible)
4.2. Schedule periodic demonstrations (for example, at the requirements gathering and planning stages - once a week, at the development stage - once every two weeks) to take into account the labor costs of preparing and conducting them
Demonstrations should be conducted not only for business customers, but also for employees of other customer departments that are potentially involved in the project (system administrators, key users, security, etc.)
This will allow to receive comments at the early stages, discuss problems, allow the user to get used to the interface and functionality.

5. The customer wants the team to flexibly approach his wishes (changes, additions) and implement them within the project, and not as part of subsequent refinements, and the customer categorically does not want to hear anything about changing the project budget

Decision:
5.1. We explicitly include time for possible changes in the project plan (we put a buffer on terms and budget, out of risks), which, at the request of the customer, will be spent on the necessary changes and improvements. This, firstly, provides opportunities for working on changes within the project, and secondly, forcing the customer to be thoughtful about change requests, since this resource is already clearly limited
5.2. Consider the possibility of an iterative approach to development and plan these iterations. Take into account the number of meetings, deliveries, demonstrations, and more.
5.3. As written above, in the contract (as an annex to the contract, or in the technical task) we include a clause describing everything that is beyond the scope of the project and which the customer explicitly refused.

6. The customer wants to see a lot of documentation on the system.

Decision:
We include in the calculation of the cost of the project the cost of creating documentation (as you will see below, the amount can be substantial)

7. In the event that the project team is formed anew, there is a risk that the qualifications of a specialist may be lower than expected.

Decision
When planning tasks and time for their implementation, it is necessary to focus on specialists at a level lower than expected to attract to the project.

8. IT technologies and tasks are becoming increasingly difficult, that it is increasingly difficult to identify the pitfalls of selected technologies in the early stages of the project.

Decision:
8.1. You need to put in the plan for some time on the risks that the team can use at their discretion

8.2. Perform tasks related to high-risk technologies as early as possible.

Where to begin

As I wrote earlier, understand what needs to be done in order to achieve the goal of the project and turn it in [1]
Identify as many requirements and constraints to the project. Do not forget to identify the requirements for:
a. Documentation. If you do not know what software documentation happens - you can refer, for example, to GOST (ESPD) 19.101-77 "Types of programs and program documents" [3] or specifications of other methodologies, and on this basis to offer the customer a list from which he will be able to choose the right
b. Non-functional requirements [4], which, for example, may include: localization, backup, monitoring, logging, security, data migration, initial data upload, installation requirements, configuration requirements.
This information can be obtained from customer IT and security services.
Test received requirements [1]
Write down the list of tasks as detailed as possible, so that each task has quite measurable deadlines. For example, at the project evaluation stage, tasks can be broken down and evaluated until the day
The assessment should involve specialists in different areas: project manager, developer, test engineer, deployment and implementation specialist, usability specialist, product management specialist (product manager, they can be the same analyst)

The list of works for evaluation

Before we turn to specific numbers and coefficients, consider what tasks you need to remember to include in the list of tasks

Stage of analysis and collection of requirements

Meetings with customer for interview and results report
Writing a requirements document
Testing Requirements
Writing and negotiating the contract and other initiating draft documents

Solution design

Writing TK
Writing solution architecture
Testing TK and solution architecture
Training of subject matter specialists
Installing development and test environments
Writing a test plan and options for testing the system
Meetings with the customer

Development and internal testing

Weekly Developer Meetings
Programming
Code enhancement
Demonstrations (preparation and conduct)
First installation of the solution on the testing environment
Passing test cases

Customer Testing

First installation in customer’s test environment
Deliveries of beta versions
Completion and correction of faults

Implementation

Installation on a working server
User training
Writing instructions

Additionally

Time to risk
Time to change
Project management

The first step is to evaluate the duration of the work on the programming of the solution, then additional factors and assumptions can be applied to calculate the full term of the project.

Evaluation of writing code

To evaluate the development work, I recommend sticking to the following rules:

* To achieve the goal of the project, break it into user actions (User stories), which break into tasks, which in turn into subtasks, etc. And so on until each task becomes clear to a junior developer person and will have clear criteria for how to verify its implementation.

* Do not forget to highlight the basic tasks that can not be excluded
Do not forget to take into account such tasks:

Creating an installation utility
Creating a configuration utility (perhaps there will be several of them: initial configuration, configuration of system parameters, security configuration)
Creation of the primary data upload utility and, possibly, the migration utility to the new version
Creation of diagnostic utilities (utilities that will help check if everything is installed correctly and help to identify faults)
Creating a logging module. Even if the customer does not need it - it will greatly help to identify errors and shortcomings.
Creating a security module

Practice numbers and coefficients

For an introduction to the project of a new person and the installation of a development environment for him, plan at least 40 hours (1 week)
Weekly developer meetings - 4 hours each week for each developer
Initial installation of the solution on the test server - plan 80 hours (2 weeks)
For the preparation of each demonstration - 8 hours (the time it takes the architect to assemble and test the modules before the demonstrations; 8 hours if there are 3 developers in the project, if there are more developers, then we increase the same)
Meetings (demonstrations) with the customer - each meeting is 4 hours long (in my experience, it’s better to go to three: project manager, architect, analyst, or testing specialist)
The first installation in the customer's test environment - 40 hours
The first installation in the working environment of the customer - 40 hours
Preparation and dispatch of each delivery - 8 hours (this includes compiling, packing, writing the installation process, installation assistance)
Refinement and correction of malfunctions (refactoring) - 25% of the development
Tasks for testing 30-50% of the time spent on development (development of requirements document, development of technical specifications, functionality, etc.)
Time to risk - at least 10% of the total time
Time to change - at least 10% of the total time
Project management - 15% of the total project time
Completion and correction of faults - 25% of development time
The analyst creates an average of 3 pages of approved documentation per day.

Calculation example

For example, as a result of the assessment, some figures were obtained.

After analyzing the tasks for development (including design), we got 1200 man-hours.
We decide that the development tasks will be conducted by 3 developers. Then the development work will take 10 weeks.
It is required to write and coordinate a lot of documentation, including requirements, TK, solution architecture, user instructions, and so on. Total net output is 400 pages.
The application has complex business logic, so there is a lot of testing (so we take 40% of the development)
We plan 5 meetings with the customer to identify requirements
We plan 3 meetings with the customer to agree on the vision and draft decision
We are planning 4 product demonstrations to the customer at the development stage.
We plan 10 deliveries to the customer’s test environment

Based on this, we decide that for this assessment we will be guided by the following team:

3 developers
1 test engineer
1 business analyst
1 systems analyst (architect, he will also perform infrastructure tasks)
1 project manager

Now we will write down tasks and time for performance. At the same time, the tasks associated with the creation of documentation and its testing cells are empty, at the bottom of the table is a single field containing summary information based on the creation of 400 pages of documents.

Tasks	Roles	Number of persons	Time	Total
Stage of analysis and collection of requirements
Meetings with customer for interview and results report	Leader, analyst, architect	3	5 times x 4 hours	60
Writing a requirements document	Analyst, Architect
Testing Requirements	test engineer
Writing and negotiating the contract and other initiating draft documents	Project Manager	one
Solution design
Writing TK	Analyst, Architect
Writing solution architecture	architect	one	40	40
Testing TK and solution architecture	test engineer
Training of subject matter specialists	Everything	7	40	280
Installation of development environments	Architect, developers	four	sixteen	64
Install Test Environment	test engineer or architect	one	40	40
Writing a test plan and options for testing the system	test engineer
Meetings with the customer	Leader, analyst, architect	3	3 times x 4 hours	36
Development and internal testing
Weekly Developer Meetings	Architect, developers	four	10 meetings for 4 hours	160
Programming	Developers	3	400	1200
Code enhancement	architect	one	3 x 100	300
Preparation of the demonstration	architect	one	4 demonstrations of 8 hours	32
Demonstration	Architect, Project Manager, Analyst	3	3 x 4	36
Tasks test engineer (passing test cases), 40% of the development	test engineer	one		480
First installation of the solution into the testing environment	testing specialist or architect	one	80	80
Customer Testing
First installation in customer’s test environment	architect	one		40
Deliveries of beta versions	architect	one	10 deliveries of 8 hours	80
Improvement and correction of faults (25% of the development)	Developers	2		300
Implementation
Installation on a working server	architect			40
User training (let's say 3 lessons of 4 hours)	Analyst	one	3 x 4	12
Writing instructions	Analyst
Writing documentation	Part Analyst, Part Architect		135 days, 3 pages	1080
Documentation testing	Test engineer		30% of its writing	320
Total				4680
Additionally
Time to risk			10% of development	120
Time to change			10% of development	120
Project management	Project Manager		15% of the project	700
Total		Approximately 5620 hours

Based on the data obtained, the estimation of the development tasks directly (1200 hours) is much less than the total labor costs (more than 4 times).

A large amount of time is spent on testing and optimizing code, writing documentation, introducing specialists into a project (including setting up an environment for work) and managing a project.

Conclusion

I repeat that these calculations are my practice and observations regarding the definition of labor intensity (I remind you that the article does not consider the assessment of the duration of the project and its budget) and, accordingly, you may have your own experience and methods and recommendations for assessing the complexity of the work.
I am pleased to hear critical reviews and comments to improve this technique.

I hope that this article will help you more reasonably and more clearly to give estimates for projects, and in time to take into account as much as possible the "little things" that may affect the labor costs in your projects.

What can you see more on the topic? See the links section.

Links

1. Sergey Martynenko “Writing tests as a type of testing requirements” http://vimeo.com/13803733

2. Sergey Berezhnoy “My Story:“ The Way of Overtime ”

3. GOST (ESPD) 19.101-77 "Types of programs and program documents" http://www.rugost.com/index.php?option=com_content&task=view&id=48&Itemid=50

4. Natalia Zhelnova. Non-functional software requirements: how to determine them and where to get numbers
akiselev87.wordpress.com/2011/07/14/naly -girl-non-functional- tr
5. S. Arkhipenkov “Estimating the laboriousness and timing of software development” http://www.arkhipenkov.ru/resources/sw_project_estimation.pdf

6. Ten deadly sins in assessing the complexity of software development http://leopard.in.ua/2010/03/22/desyat-smertnyx-grexov-v-ocenke-trudoyomkosti-razrabotki-programmnogo-obespecheniya/

7. Mikhail Ostrogorsky “Approach to estimating the terms for creating technical documentation” http://www.philosoft.ru/metrics-idea.zhtml

8. Sergey Povolyashko “Labor costs and planning when testing” http://qaclub.com.ua/wp-content/uploads/d/qaclub6_19-02-10/QAClub_TestEffortsPlanning.pdf

Source: https://habr.com/ru/post/134719/

All Articles