Get best of the week

Contract development of electronics. Project calculation




Every month, dozens of applications for the development of electronics come to us. And each potential customer wants to know the cost of solving his problem, regardless of how well he understands it. Can a contract developer please everyone? How to weed out the "hopeless" in advance? How to evaluate those projects that have a chance of development? This is our new article.

What projects should not be considered


When we first started, each application in the mail seemed like a gift of fate. We sat down with our entire small team and came up with how cool we are implementing this project. It seemed that it was necessary to give every potential customer the maximum detail. It is necessary to choose the main technical solutions, break down the work into stages, down to individual tasks, draw a Gantt chart, calculate the cost of the product and describe all this as detailed as possible in a commercial proposal (KP). We spent on each CP up to several days, and customers went on eternal consideration. Over time, the understanding came that you can not waste time engineers and screen out projects without a future


even before diving into technical details. First of all, it is necessary to understand the seriousness of the intentions of the future Customer. Alas, requests like “I saw yesterday on the Internet a device for 50,000 rubles, do me the same for 30,000 rubles” are more common than we would like.

What do we need to ask in order to assess the chances of the project to succeed?


  1. Why does an organization need a given product (product creation goals)? We need to find out the most accurate formulation of the business task. So we filter out dreamers with the next "brilliant idea" of an automated bath mat, with bluetooth and a mobile application.
  2. Who is the initiator of the project (DM)? We find out who is responsible for the technology and who allocates the budget. Usually these are different people, and they require different approaches in terms of sales.
  3. ( )?
  4. . : , , , .?
  5. ( , )?
    . , , , .
  6. ( )? , , , . « » =)
  7. ( .., )?
  8. ?

    • — :
      1. (, )?
      2. ?
      3. (), ? -? ?
    • — : . , , . « », , .
    • ? ? ? — .
  9. ? — :
    • (, )?
    • (, )?
    • ?
    • , ?
    • ( )?
  10. () ( )? «», - . , 9 .
  11. ? , . , , .
  12. (, , , )? « , ». , -.
  13. ? : , .
  14. ? – .
  15. ? (, , , , ). . ?
  16. ? ?
  17. (, , )?
  18. ? .


-




So, the client and the project meet all the requirements, we begin the assessment. The assessment is inaccurate and unfit. If we do not yet have TK, we get an unfit assessment with a large spread. Wrote TK - received an inaccurate assessment. Without TK, the score has a tolerance of ± 400% or more. This is called the cone of uncertainty: The graph about the interfaces, but the essence on different projects is the same. The more we know, the less uncertainty. Do not spare time and effort on TK.




Our project appraisal meetings have the unofficial name of “Vanga Club”. Participants familiarize themselves with the materials on the project in advance. At the appointed hour, the Club receives: a businessman, a project manager, a leading circuit engineer, a leading programmer. Sometimes additional specialists with narrow expertise are invited, as well as representatives of contractors. So many people are needed for a comprehensive review of the project. The merchant is happy with his luck and strives to satisfy the client by simplifying the requirements. The project manager will have to bring the project to life, he will be responsible for the timing, cost and amount of work. His desire is to lay a reserve, take risks into account. Engineers want to do better than yesterday. They can easily refuse a simple, but "uninteresting" option. Without a project manager, you can take an underestimated order, because a businessman is very eloquent.Without a merchant, you can count so much that the client does not even answer the letter.



The meeting begins with a general discussion of the problem to form a common understanding by all participants. Then, a hierarchical structure of work ( WBS ) is built for the project .
For a single device, software and hardware parts are allocated. For the system, different parts are added like test software, simulators, server part, etc. The resulting parts are split into smaller parts, for example, hardware branches into two revisions of the PCB and the Design. The next stage is to break up the parts into separate tasks. If everything is clear with the implementation, the tasks should be small. The task "Write firmware" categorically does not fit. We consider normal specific tasks with small ratings, for example: “MCU I2C Driver”, “Raise a Project”, “E3 Scheme”.
You should not evaluate the complexity of tasks ahead of time, because their complexity and relationships will become clear only when they are all written on the board.

All tasks are assigned labor in hours. The method is an expert assessment . A clock can take values ​​from a number of powers of two: 2, 4, 8, 16, 32, 64, 128 ... Tasks with an assessment of 128 hours or more appear when the implementation is not clear. This means that it is worthwhile to carry out work to clarify the requirements, verify the applicability of the technology, and sometimes even just disperse and smoke a google.
According to my observations, it is possible to increase the accuracy of the assessment, first of all, requesting the opinion of less experienced developers. So they learn to evaluate tasks faster on their own. If a reputable engineer has already spoken out, everyone else tends to simply agree with his opinion. And when the work on the project begins, the tasks will most likely be solved not by him, but by those who did not say anything. We will still hear their assessment, but not at the right time.
When all tasks are evaluated, we summarize the results and add 30% to the software for debugging and another 30% to software testing. These figures are taken from statistics on completed projects.
As a result, the following picture appears on the board:



The assessment is usually accompanied by a keen discussion of the details, because there can be many options for solving the problem. So it takes no less than an hour. Given the time to prepare, even a preliminary assessment of the project can cost 5-20 hours of leading developers.

We all want to make successful products, electronics that will benefit people. We discuss how the results of the assessment (timelines, resources) are consistent with the objectives of the project as a whole. It may be worth offering the customer other ways. For example, to cut functionality for MVP, or to take more expensive hardware in favor of cheaper development. It is useful to roughly calculate the overall economics of the project for subsequent stages: production, production, support. These figures show the relative weight of resources and time for the stages of the project and can significantly change their perception (both ours and the customer).

The ratings received from the Wang Club are entered in Redmine. EasyWBS is suitable for quickly adding tasks in a visual form:




To determine the timing of development, we build iron tasks in chains (waterfall). We get this Gantt: For software, we divide the labor intensity into the productivity of the number of people that can be involved in the project at the same time. As you know, what one programmer does in a month, two programmers do in two months. So you should not take into account all your personnel resources when calculating. Also, not in every project programmers can start work from the very start. It happens that you need to wait for iron, your own or purchased. The same delay can occur at the junction of stages and revisions of iron. To inform the customer, the received dates can not be taken. Unless with the prefix "optimistic forecast." It is better to give a small margin. He will come in handy.






In the Calculation module, rates for specialists are added and costs for co-contractors, production, materials, devices, etc. are added. An excellent commercial offer for the customer.pdf we create directly from here. Read how our colleagues evaluate projects differently using the example of a single request. Small analytics of twelve KP . So, the project is accepted, evaluated. It remains to sign the contract - and go ahead, rewrite tasks, change technical solutions, expand requirements, changing the project beyond recognition!









For us there is no question whether to evaluate projects or not, because we are doing projects for clients, it will not work to get a contract without evaluation. But with internal projects in companies, the situation is different. Often, internal projects are not evaluated. And very in vain. The consequence of this approach is the underestimation of time and resources. Neither the team nor the management can evaluate the current progress of the project. Hence the misunderstanding and demoralization of the team.

And now - let's go discuss in the comments your approaches to project evaluation!

More articles:


All Articles