November 11, 2013 at 12:24How to quickly and accurately evaluate a project without technical requirements
With this combination - quickly, accurately, without TK - it seems that the problem has no solution. However, in the work of a freelancer such problems arise constantly, therefore, in the struggle for survival, orders have to be learned to solve them. First, I’ll explain what the words in the title mean.
Quickly - this means that before the customer decides to choose an artist (another artist, since you are not yet ready to answer him the most important question).
Exactly - it means that it is close enough to the real cost of the project, which could be announced after the approval of the ToR (and even better after the project, when the exact amount of time spent on the development is already known).
And finally, what does it mean Without TK? It is clear that there are practically no projects without TK (in the style of “go there, I don’t know where, bring that, I don’t know what”). Another thing, in what form the customer provides you with this TK.
Based on my experience, I can distinguish the following:
The customer is not able to provide at least something similar to the statement of work. It happens that he formulates the task with one phrase - “Develop CRM for a theater school” or “Do something similar to kakoy-to-site.com , but with minor changes.” Probably, it seems to the customer that this phrase contains the right amount of information to evaluate the amount of work, so he is surprised that you are not ready to immediately name the cost of your services.
The customer calls the word “TK” several prototype pictures drawn by hand or in Excel. It is worth clarifying 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 TOR level 1 - a brief description of the functional blocks without any indication of how it should all look.
The technical task exists in a fairly detailed form - with prototypes of screens, a description of the data structure and the logic of each element of the interface, however, some ambiguities remain - the ability to interpret the same function of the developed system in different ways. For example, what is hidden behind the phrase "the manager sees only his orders"? The orders he created? Or assigned to it? Or customer orders for which this manager is responsible? This can only be ascertained in a dialogue with the customer.
TK has such a 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 - which technologies you should use, which algorithms to apply. Sometimes these requirements are justified in some way (for example, the customer plans to continue to independently support the system in the future, so he wants you to use only technologies familiar to him), but, as practice shows, often the customer simply does not know how to usually implement such things, and wrote the first thing that came to mind. If you don’t clarify this point in time, you risk wasting time trying to implement the proposed scheme, despite the fact that the original problem is solved much easier.
The highest level imaginable. As a rule, this is achieved after you carefully study the details of the TOR, identify all the contentious issues and agree on the final version with the customer. Hurrah?! It turns out that even in this case you should not relax: at any time (during the development process or during the trial operation), the customer may have wishes that seem insignificant to him, but in reality may require radical changes to the system. Or some functionality may be implied by the customer, but not be explicitly prescribed in the statement of work, because "it is obvious."
The problem is that often you have TK only of the first or even zero level, and at the same time the customer requires you to name the cost and terms.
In order for you to get the desired project, 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 it makes no sense to take on the project. Of course, there may be exceptions to this rule. For example, when you just start your career on freelance work and work on your reputation and portfolio, it’s not so much the price that matters to you, but the opportunity to get “plus in karma”. But we are not considering this option now - we assume that we are still talking about a business that should work as a plus.
On the other hand, a high price can scare off a customer if other bidders offer him a much lower price. There may also be an exception. If the customer already has positive experience working with you and knows that you are setting an adequate price and for this price complete the task efficiently and on time, then perhaps even at a higher cost he will choose you. However, in this case, the customer is likely to contact you directly, and you will not have to participate in the competitive selection.
So, you need to establish the cost of the project, covering the development costs. In this case, either the price should turn out approximately at the same level as the offers of other performers, or (if it turned out to be much higher) you should be able to correctly substantiate 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 this. The discussion of TK may drag on indefinitely. In this case, the customer, first of all, gets tired - why answer your questions, if it is still unknown, will you be chosen as the contractor? Secondly, it seems to the customer that the abundance of questions means your lack of experience in solving such problems - so why bother with you?
2. If you are lucky and the terms of reference are quite detailed (level 2 or 3), then I want to evaluate the project taking into account all the details described. We take the task, highlight the stages of work, each stage is divided into small understandable tasks that are easy to evaluate. As a result, the most accurate assessment of the project should be obtained - there is enough information for this. 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 TK, the customer has a feeling that you have forgotten about him - do not write to him, do not ask questions, do not offer anything concrete. And when you finally give him a ready-made assessment of the project, it may turn out that he 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 price higher. In this case, it may happen that you get the order, but you have to do it at a loss - do you need this?
4. If, looking at the TOR, you see how you can improve this system, which has not yet been developed, you suggest that the customer immediately take into account those needs that will almost certainly arise during the implementation of the project. The mistake is that the details that are obvious to you may not be visible or unimportant to the customer, and he will regard your concern as a desire to impose on him unnecessary functionality for an additional fee.
To begin, I define the main large functional blocksproject, without detail. Such blocks, as a rule, for projects of the same orientation are very similar. For example, in any CRM there is a customer base, orders, managers, delimitation of rights, 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 the project, I first spend time on the planned work on all functional blocks, then (if time is 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 spelled out in the statement of work." As a rule, the customer agrees that the work is done, and if you really want to implement the wishes, then we agree on the next stage of work, which is paid separately.
After identifying the main blocks, I identify potential problem areas - the functions described are too vague. These may be phrases such as “integration with the SMS distribution system”. In some cases, such a phrase may mean “do it somehow, I don’t care”, in others it may mean “choose the SMS distribution system that is ideal for me and justify your choice by comparative analysis of 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 blocks.
And finally, if the project has tasks that, in principle, can be easily solved, but I still do not have the relevant experience, then I evaluate them on the assumption that I already know how to solve such problems. Then the cost is not higher than that of other performers, and the extra time that I spend on studying ways to solve such problems can be perceived as an investment in the future. Of course, you need to understand that there should not be too many such “spaces for growth” in the project, otherwise the terms proposed by me may not suit the customer.
It is clear that the ability to evaluate a project in large blocks and at the same time see potentially dangerous details comes with experience. For starters, it’s enough to adhere to two rules:
If the goal at all costs is to receive this particular order, be prepared to agree to conditions that are obviously unfavorable for yourself. If the goal is to earn adequate efforts, learn to spend a minimum of effort and time evaluating the project, and be prepared to justify your price if necessary. And with those to whom your price, even in an argumented form, does not fit, leave without regret.
If you assume that during the work some nuances may be revealed that significantly increase the complexity (and, consequently, the cost) of development, immediately inform the customer that for the agreed amount you will only do what is explicitly stated in the statement of work, and everything else ready to discuss later.
Quickly - this means that before the customer decides to choose an artist (another artist, since you are not yet ready to answer him the most important question).
Exactly - it means that it is close enough to the real cost of the project, which could be announced after the approval of the ToR (and even better after the project, when the exact amount of time spent on the development is already known).
And finally, what does it mean Without TK? It is clear that there are practically no projects without TK (in the style of “go there, I don’t know where, bring that, I don’t know what”). Another thing, in what form the customer provides you with this TK.
Based on my experience, I can distinguish the following:
Levels of technical specifications
Level 0
The customer is not able to provide at least something similar to the statement of work. It happens that he formulates the task with one phrase - “Develop CRM for a theater school” or “Do something similar to kakoy-to-site.com , but with minor changes.” Probably, it seems to the customer that this phrase contains the right amount of information to evaluate the amount of work, so he is surprised that you are not ready to immediately name the cost of your services.
Level 1
The customer calls the word “TK” several prototype pictures drawn by hand or in Excel. It is worth clarifying 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 TOR level 1 - a brief description of the functional blocks without any indication of how it should all look.
Level 2
The technical task exists in a fairly detailed form - with prototypes of screens, a description of the data structure and the logic of each element of the interface, however, some ambiguities remain - the ability to interpret the same function of the developed system in different ways. For example, what is hidden behind the phrase "the manager sees only his orders"? The orders he created? Or assigned to it? Or customer orders for which this manager is responsible? This can only be ascertained in a dialogue with the customer.
TK has such a 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 - which technologies you should use, which algorithms to apply. Sometimes these requirements are justified in some way (for example, the customer plans to continue to independently support the system in the future, so he wants you to use only technologies familiar to him), but, as practice shows, often the customer simply does not know how to usually implement such things, and wrote the first thing that came to mind. If you don’t clarify this point in time, you risk wasting time trying to implement the proposed scheme, despite the fact that the original 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 TOR, identify all the contentious issues and agree on the final version with the customer. Hurrah?! It turns out that even in this case you should not relax: at any time (during the development process or during the trial operation), the customer may have wishes that seem insignificant to him, but in reality may require radical changes to the system. Or some functionality may be implied by the customer, but not be explicitly prescribed in the statement of work, because "it is obvious."
The problem is that often you have TK only of 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 you to get the desired project, 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 it makes no sense to take on the project. Of course, there may be exceptions to this rule. For example, when you just start your career on freelance work and work on your reputation and portfolio, it’s not so much the price that matters to you, but the opportunity to get “plus in karma”. But we are not considering this option now - we assume that we are still talking about a business that should work as a plus.
On the other hand, a high price can scare off a customer if other bidders offer him a much lower price. There may also be an exception. If the customer already has positive experience working with you and knows that you are setting an adequate price and for this price complete the task efficiently and on time, then perhaps even at a higher cost he will choose you. However, in this case, the customer is likely to contact you directly, and you will not have to participate in the competitive selection.
So, you need to establish the cost of the project, covering the development costs. In this case, either the price should turn out approximately at the same level as the offers of other performers, or (if it turned out to be much higher) you should be able to correctly substantiate it.
What mistakes can be made at the stage of evaluation of work (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 this. The discussion of TK may drag on indefinitely. In this case, the customer, first of all, gets tired - why answer your questions, if it is still unknown, will you be chosen as the contractor? Secondly, it seems to the customer that the abundance of questions means your lack of experience in solving such problems - so why bother with you?
2. If you are lucky and the terms of reference are quite detailed (level 2 or 3), then I want to evaluate the project taking into account all the details described. We take the task, highlight the stages of work, each stage is divided into small understandable tasks that are easy to evaluate. As a result, the most accurate assessment of the project should be obtained - there is enough information for this. 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 TK, the customer has a feeling that you have forgotten about him - do not write to him, do not ask questions, do not offer anything concrete. And when you finally give him a ready-made assessment of the project, it may turn out that he 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 price higher. In this case, it may happen that you get the order, but you have to do it at a loss - do you need this?
4. If, looking at the TOR, you see how you can improve this system, which has not yet been developed, you suggest that the customer immediately take into account those needs that will almost certainly arise during the implementation of the project. The mistake is that the details that are obvious to you may not be visible or unimportant to the customer, and he will regard your concern as a desire to impose on him unnecessary functionality for an additional fee.
How do I evaluate projects now:
To begin, I define the main large functional blocksproject, without detail. Such blocks, as a rule, for projects of the same orientation are very similar. For example, in any CRM there is a customer base, orders, managers, delimitation of rights, 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 the project, I first spend time on the planned work on all functional blocks, then (if time is 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 spelled out in the statement of work." As a rule, the customer agrees that the work is done, and if you really want to implement the wishes, then we agree on the next stage of work, which is paid separately.
After identifying the main blocks, I identify potential problem areas - the functions described are too vague. These may be phrases such as “integration with the SMS distribution system”. In some cases, such a phrase may mean “do it somehow, I don’t care”, in others it may mean “choose the SMS distribution system that is ideal for me and justify your choice by comparative analysis of 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 blocks.
And finally, if the project has tasks that, in principle, can be easily solved, but I still do not have the relevant experience, then I evaluate them on the assumption that I already know how to solve such problems. Then the cost is not higher than that of other performers, and the extra time that I spend on studying ways to solve such problems can be perceived as an investment in the future. Of course, you need to understand that there should not be too many such “spaces for growth” in the project, otherwise the terms proposed by me may not suit the customer.
Conclusion
It is clear that the ability to evaluate a project in large blocks and at the same time see potentially dangerous details comes with experience. For starters, it’s enough to adhere to two rules:
Always remember your main goal
If the goal at all costs is to receive this particular order, be prepared to agree to conditions that are obviously unfavorable for yourself. If the goal is to earn adequate efforts, learn to spend a minimum of effort and time evaluating the project, and be prepared to justify your price if necessary. And with those to whom your price, even in an argumented form, does not fit, leave without regret.
Protect yourself from unreasonable customer claims in advance
If you assume that during the work some nuances may be revealed that significantly increase the complexity (and, consequently, the cost) of development, immediately inform the customer that for the agreed amount you will only do what is explicitly stated in the statement of work, and everything else ready to discuss later.