How to quickly and accurately assess the project without TK
With this combination - quickly, accurately, without TK - it seems that the problem has no solution. However, in the work of a freelancer, such tasks arise constantly, therefore, in the struggle for survival, orders have to learn to solve them. To begin, let me explain what the words in the title mean.
Quickly means that before the customer decides on the choice of the performer (another performer, since you are not yet ready to answer the most important question).
Precisely - it means that it is close enough to the real cost of the project, which could be announced after the agreement of the TOR (and even better after the completion of the project, when the exact amount of time spent on development is already known).
And finally, what does it mean Without TK ? It is clear that there are practically no projects without TZ (in the style of “go there, I don’t know where, bring it, I don’t know what”) practically does not happen. Another thing in which the customer provides you with this very TK.
Based on my experience, I can highlight the following:
The customer is not able to provide at least something similar to the TK. It happens that he formulates the task in one phrase - “Develop CRM for theatrical school” or “To do something like on kakoy-to-site.com , but with slight changes”. Probably, it seems to the customer that this phrase contains the necessary amount of information for estimating the amount of work, so he is surprised that you are not ready to immediately name the cost of your services.
')
The word "TZ" customer calls a few pictures of the prototypes, drawn by hand or in Excel. It should be clarified that prototypes in Excel are a feature of orders in my specialty (databases and CRM), and to some extent they solve the problem of understanding what the customer needs. In other cases, the quality of the prototypes themselves may be higher, but the essence remains the same - these are just pictures with a small description, but without a detailed explanation of what should work. It is also possible the opposite version of the TZ level 1 - a brief description of the functional blocks without any indication how it should look.
The technical assignment exists in a fairly detailed form - with prototypes of screens, a description of the data structure and the logic of each interface element, but some ambiguities remain - the ability to interpret the same function of the developed system in different ways. For example, what is behind the phrase "the manager sees only his orders"? Orders he created? Or assigned to him? Or orders of clients for whom this manager is responsible? This can only be clarified in a dialogue with the customer.
There is a TK of this level and another problem. It happens that the customer describes in too much detail not only the logic of the system, but also his ideas about how this logic should be implemented - what technologies you should use, what algorithms to use. Sometimes these requirements are somehow justified (for example, the customer plans to maintain the system independently in the future, therefore he wants you to use only familiar technologies), but, as practice shows, often the customer simply does not know how they usually implement such things, and wrote the first thing that came to mind. If you do not clarify this point in time, you risk wasting time trying to implement the proposed scheme, while the initial problem is solved much easier.
The highest level imaginable. As a rule, this is achieved after you carefully study the details of the TZ, identify all disputed issues and agree the final version with the customer. Hooray?! It turns out that even in this case you should not relax: at any time (in the process of development or in the process of trial operation), the customer may have suggestions that he seems to be insignificant, but in fact may require radical changes to the system. Or some kind of functionality may be implied by the customer, but not be explicitly spelled out in the TK, because "this is obvious."
The problem is that often you have the TK of only the first or even zero level, and at the same time the customer requires you to name the cost and terms.
In order for the desired project to get you, you need to be able to quickly name the right price . What price can be considered correct?
On the one hand, it should not be lower than the cost, otherwise there is no point in taking on the project. Of course, there may be exceptions to this rule. For example, when you are just starting your path to freelancing and working on reputation and portfolio, you are not so much interested in price as in getting the “plus in karma”. But we are not considering this option now - we assume that it’s still a matter of business, which should work in a plus.
On the other hand, the high price may scare the customer away if other bidders offer him a significantly lower price. There may also be an exception. If the customer already has a positive experience with you and knows that you are setting an adequate price and for this price do the job well and on time, then perhaps he will choose you even at a higher cost. However, in this case, the customer is likely to contact you directly, and you do not have to participate in the competitive selection.
So, you need to set the project cost, covering development costs. At the same time, either the price should be approximately on par with the proposals of other performers, or (if it turned out to be much higher) you should be able to correctly justify it.
1. If the TOR is too short for an accurate assessment (level 0 or 1), you can begin to ask the customer clarifying questions and get too carried away with it. Discussion of TK can be delayed indefinitely. In this case, the customer, first of all, gets tired - why answer your questions, if it is still unknown, will you be the chosen contractor? Secondly, it seems to the customer that the abundance of questions means that you have no experience in solving such problems - so why bother to contact you at all?
2. If you are lucky and the TZ is quite detailed (level 2 or 3), then you want to evaluate the project with all the details described. We take the task, select the stages of work, we divide each stage into small understandable tasks that are easy to assess. The result should be the most accurate assessment of the project - information for this is quite enough. However, with this approach, you forget that the assessment is needed not only accurate, but also fast. While you evaluate all the smallest details of the TK, the customer has the feeling that you have forgotten about him - you do not write to him, you do not ask questions, you do not offer anything concrete. And when you finally give him a ready assessment of the project, it may turn out that he has already found the performer (who did not think so long) and all your efforts were wasted.
3. If the prices offered by other performers are already known, you are guided by them and are afraid to offer a higher price. In this case, it may happen that you get the order, but you have to make it at a loss - do you need it?
4. If, looking at the TOR, you see how to improve this system that has not yet been developed, you suggest that the customer immediately take into account those needs that will almost certainly arise in the course of the project. The mistake is that the details that are obvious to you may be invisible or unimportant for the customer, and he will regard your care as a desire to impose unnecessary functionality on him for an additional fee.
To begin with, I define the main large functional blocks of the project, without detail. Such blocks, as a rule, for projects of the same orientation turn out to be very similar. For example, in any CRM there is a customer base, orders, managers, rights delineations, etc. These blocks differ in a specific set of fields, behavior when performing actions, but the approximate amount of work is the same. In the process of working on a project, I first spend time on the planned work on all functional blocks, then (if there is time left) I can meet the wishes of the customer. When the set time comes to an end, I point out to the customer the agreement “to do only what is clearly stated in the TK”. As a rule, the customer agrees that the work is done, and if you really want to realize the wishes, we agree on the next stage of work, which is paid separately.
After identifying the main blocks, I identify potentially problematic places — the functions described are too vague. These can be phrases like "integration with the SMS distribution system". In some cases, this phrase may mean “do something, I don't care,” in others it may mean “choose the SMS system that is right for me and justify your choice by comparing all systems available on the market”. In such cases, it is better to immediately clarify what was meant, or to lay more time and, accordingly, money to work out such units.
And finally, if the project has tasks that, in principle, can be easily solved, but I still have no relevant experience , I estimate them on the assumption that I can already solve such problems. Then the cost is not higher than that of other artists, and the extra time I spend on learning how to solve such problems can be seen as an investment in the future. Of course, we must understand that such a “space for growth” in the project should not be too much, otherwise the customer may not be satisfied with the terms proposed by me.
It is clear that the ability to evaluate a project in large blocks and at the same time see potentially dangerous parts comes with experience. And for starters, it’s enough to follow two rules:
If the goal is to get this order by all means, be prepared to accept conditions that are obviously unfavorable for you. If the goal is to earn adequately spent efforts, learn to spend a minimum of effort and time to evaluate the project, while being ready to justify your price if necessary. And with those to whom your price even in a reasoned form does not fit, leave without regret.
If you assume that in the course of work some nuances can be revealed that will significantly increase the complexity (and, accordingly, the cost) of development, immediately inform the customer that for the agreed amount you will only do what is clearly stated in the TK, and everything else ready to discuss later.
Quickly means that before the customer decides on the choice of the performer (another performer, since you are not yet ready to answer the most important question).
Precisely - it means that it is close enough to the real cost of the project, which could be announced after the agreement of the TOR (and even better after the completion of the project, when the exact amount of time spent on development is already known).
And finally, what does it mean Without TK ? It is clear that there are practically no projects without TZ (in the style of “go there, I don’t know where, bring it, I don’t know what”) practically does not happen. Another thing in which the customer provides you with this very TK.
Based on my experience, I can highlight the following:
The levels of elaboration of technical specifications
Level 0
The customer is not able to provide at least something similar to the TK. It happens that he formulates the task in one phrase - “Develop CRM for theatrical school” or “To do something like on kakoy-to-site.com , but with slight changes”. Probably, it seems to the customer that this phrase contains the necessary amount of information for estimating the amount of work, so he is surprised that you are not ready to immediately name the cost of your services.
')
Level 1
The word "TZ" customer calls a few pictures of the prototypes, drawn by hand or in Excel. It should be clarified that prototypes in Excel are a feature of orders in my specialty (databases and CRM), and to some extent they solve the problem of understanding what the customer needs. In other cases, the quality of the prototypes themselves may be higher, but the essence remains the same - these are just pictures with a small description, but without a detailed explanation of what should work. It is also possible the opposite version of the TZ level 1 - a brief description of the functional blocks without any indication how it should look.
Level 2
The technical assignment exists in a fairly detailed form - with prototypes of screens, a description of the data structure and the logic of each interface element, but some ambiguities remain - the ability to interpret the same function of the developed system in different ways. For example, what is behind the phrase "the manager sees only his orders"? Orders he created? Or assigned to him? Or orders of clients for whom this manager is responsible? This can only be clarified in a dialogue with the customer.
There is a TK of this level and another problem. It happens that the customer describes in too much detail not only the logic of the system, but also his ideas about how this logic should be implemented - what technologies you should use, what algorithms to use. Sometimes these requirements are somehow justified (for example, the customer plans to maintain the system independently in the future, therefore he wants you to use only familiar technologies), but, as practice shows, often the customer simply does not know how they usually implement such things, and wrote the first thing that came to mind. If you do not clarify this point in time, you risk wasting time trying to implement the proposed scheme, while the initial problem is solved much easier.
Level 3
The highest level imaginable. As a rule, this is achieved after you carefully study the details of the TZ, identify all disputed issues and agree the final version with the customer. Hooray?! It turns out that even in this case you should not relax: at any time (in the process of development or in the process of trial operation), the customer may have suggestions that he seems to be insignificant, but in fact may require radical changes to the system. Or some kind of functionality may be implied by the customer, but not be explicitly spelled out in the TK, because "this is obvious."
The problem is that often you have the TK of only the first or even zero level, and at the same time the customer requires you to name the cost and terms.
How to evaluate the project in such conditions?
In order for the desired project to get you, you need to be able to quickly name the right price . What price can be considered correct?
On the one hand, it should not be lower than the cost, otherwise there is no point in taking on the project. Of course, there may be exceptions to this rule. For example, when you are just starting your path to freelancing and working on reputation and portfolio, you are not so much interested in price as in getting the “plus in karma”. But we are not considering this option now - we assume that it’s still a matter of business, which should work in a plus.
On the other hand, the high price may scare the customer away if other bidders offer him a significantly lower price. There may also be an exception. If the customer already has a positive experience with you and knows that you are setting an adequate price and for this price do the job well and on time, then perhaps he will choose you even at a higher cost. However, in this case, the customer is likely to contact you directly, and you do not have to participate in the competitive selection.
So, you need to set the project cost, covering development costs. At the same time, either the price should be approximately on par with the proposals of other performers, or (if it turned out to be much higher) you should be able to correctly justify it.
What mistakes can be made at the work evaluation stage (from my experience):
1. If the TOR is too short for an accurate assessment (level 0 or 1), you can begin to ask the customer clarifying questions and get too carried away with it. Discussion of TK can be delayed indefinitely. In this case, the customer, first of all, gets tired - why answer your questions, if it is still unknown, will you be the chosen contractor? Secondly, it seems to the customer that the abundance of questions means that you have no experience in solving such problems - so why bother to contact you at all?
2. If you are lucky and the TZ is quite detailed (level 2 or 3), then you want to evaluate the project with all the details described. We take the task, select the stages of work, we divide each stage into small understandable tasks that are easy to assess. The result should be the most accurate assessment of the project - information for this is quite enough. However, with this approach, you forget that the assessment is needed not only accurate, but also fast. While you evaluate all the smallest details of the TK, the customer has the feeling that you have forgotten about him - you do not write to him, you do not ask questions, you do not offer anything concrete. And when you finally give him a ready assessment of the project, it may turn out that he has already found the performer (who did not think so long) and all your efforts were wasted.
3. If the prices offered by other performers are already known, you are guided by them and are afraid to offer a higher price. In this case, it may happen that you get the order, but you have to make it at a loss - do you need it?
4. If, looking at the TOR, you see how to improve this system that has not yet been developed, you suggest that the customer immediately take into account those needs that will almost certainly arise in the course of the project. The mistake is that the details that are obvious to you may be invisible or unimportant for the customer, and he will regard your care as a desire to impose unnecessary functionality on him for an additional fee.
How I evaluate projects now:
To begin with, I define the main large functional blocks of the project, without detail. Such blocks, as a rule, for projects of the same orientation turn out to be very similar. For example, in any CRM there is a customer base, orders, managers, rights delineations, etc. These blocks differ in a specific set of fields, behavior when performing actions, but the approximate amount of work is the same. In the process of working on a project, I first spend time on the planned work on all functional blocks, then (if there is time left) I can meet the wishes of the customer. When the set time comes to an end, I point out to the customer the agreement “to do only what is clearly stated in the TK”. As a rule, the customer agrees that the work is done, and if you really want to realize the wishes, we agree on the next stage of work, which is paid separately.
After identifying the main blocks, I identify potentially problematic places — the functions described are too vague. These can be phrases like "integration with the SMS distribution system". In some cases, this phrase may mean “do something, I don't care,” in others it may mean “choose the SMS system that is right for me and justify your choice by comparing all systems available on the market”. In such cases, it is better to immediately clarify what was meant, or to lay more time and, accordingly, money to work out such units.
And finally, if the project has tasks that, in principle, can be easily solved, but I still have no relevant experience , I estimate them on the assumption that I can already solve such problems. Then the cost is not higher than that of other artists, and the extra time I spend on learning how to solve such problems can be seen as an investment in the future. Of course, we must understand that such a “space for growth” in the project should not be too much, otherwise the customer may not be satisfied with the terms proposed by me.
Conclusion
It is clear that the ability to evaluate a project in large blocks and at the same time see potentially dangerous parts comes with experience. And for starters, it’s enough to follow two rules:
Always remember your primary purpose.
If the goal is to get this order by all means, be prepared to accept conditions that are obviously unfavorable for you. If the goal is to earn adequately spent efforts, learn to spend a minimum of effort and time to evaluate the project, while being ready to justify your price if necessary. And with those to whom your price even in a reasoned form does not fit, leave without regret.
Secure yourself from unsubstantiated customer claims in advance.
If you assume that in the course of work some nuances can be revealed that will significantly increase the complexity (and, accordingly, the cost) of development, immediately inform the customer that for the agreed amount you will only do what is clearly stated in the TK, and everything else ready to discuss later.
Source: https://habr.com/ru/post/201652/
All Articles