How we evaluate projects
Clients budget is not endless. Before they decide to develop a project, they obviously need to be sure that I can cover the development costs. Since clients pay us for every hour of work, clients usually ask me what approach we use in project appraisal - how do we not let a client go crazy when we tell them that we will not tell the exact price.
Over the past 5 years of our work in consulting, this process has changed quite often, but for the last two years we have used the one described below.
After the first contact with a potential client (lead), we usually arrange a meeting or call on Skype. Before this meeting, I try to find out more information about the lead such as: how he / she found out about us, who he is and what he is working on, where he is, etc.
During the meeting, I talk about us, a little about our history and approach to remote work and management. After that we delve into the details of the future project and I try to find answers to the following questions:
')
If a client wants to develop a startup from scratch:
If the client is an organization with its development team :
Then we can move further into the details of the components of the project, which could be complex, such as payment, external API, etc. My goal here is to determine which technical features may require more time.
At the end, I ask the client to send me some useful information that he already has on the project, for example, mockups, design, presentation, etc. Some customers ask us to sign an NDA before sending materials.
After the first meeting, I usually talk to Victor, our CTO, and give him information on the project that I collected. This is a key point, because Victor usually asks questions about the project, which I did not think about during the first meeting with the client. We make a list of new questions to the client and we either write to the mail or get answers to them by phone.
At this time, Viktor and I are discussing other things, for example, how this project can fit into our calendar, which framework, library or technology it would make sense to use in this project, and how similar these things are to what we have already realized ( in order to improve our future ratings).
After we have dealt with our main questions to the client, we begin to paint user usage scenarios (user-story). We usually create a temporary project in PivotalTracker with all user-story. We add them to epics to group them by functionality, for example: users, payment, orders, admin panel, etc.
Then we do the assessment using the Estimation Party . Usually we ask someone from our team to join this process in order to have the most clear assessment.
We estimate the complexity of each user-story on a scale of 0, 1, 2 or 3 points. Very roughly: 1 point is half a day of work, 2 points a full day and 3 points will take 2 days of work. If we see that some user-story is more than 3 points, we break it into more than one user-story.
As soon as we have evaluated all user stories, we add such routine tasks as creating a basic application, creating a repository, creating a staging environment, or creating mockups if they are not there.
We summarize all the points of the estimated user-story and divide them by our internal velocity - the number of points that one developer can implement in one week (based on previous projects). So we will know how many weeks the project will take. Example:
At that time, we have a project assessment in weeks. However, our experience tells us that we all also know less than half of the details of the project - the rest either the client is not up to us or he does not yet know about them. Customers always learn more about their project during its development. Given this, we increase our assessment of something like:
Then we multiply the resulting time by the average number of paid developer hours per day, which is about 7 hours (we work 8 hours, but we write out the bill only for the productive time of work), and finally multiply the number of hours by our hourly rate:
Here we also decide how many developers it makes sense to involve in this project, given how many user-stori can run in parallel. If we decide that two people will be able to work in parallel, then we divide the temporary assessment in half, but the cost estimate will not change.
And in the end, we send the client either a simple PDF document (several pages) or email with all user-story (and their estimate), time and cost estimate. We try not to spend a lot of time on drawing up fashionable documents, we do not see the point.
In this message, we immediately say that this assessment is made on the basis of the information that we have at the moment. We also explain to the client that he has complete freedom to change the course of project development without discussing with us why we did not include it at the beginning of the project. The only rule for making changes in the workload is that they must be made at the beginning of the week (during the planning of the sprint), but not during the sprint.
After the project has been approved and development has begun, at the beginning of each week (usually we work with weekly sprints) we do a sprint-planning where we decide which user-story we will work on this week and what information we need from the client to implement them. At this point, we often find new details in some user story and change its assessment.
With weekly iterations and daily stand-up meetings, we provide the client with transparency of the development process, what has been done, what remains and how we are close to the initial assessment. Thus, there can be no surprises.
Please note that we require our customers to designate a product owner from their team who must attend every stand-up rally and sprint planning. It is necessary for us.
Evaluation of the project is a key part of the project, but this is something for which we do not take money and can not always get this project. Therefore, our goal for the whole process is to keep it as simple as possible in order to avoid potential costs, trying to be as accurate as possible in our estimates.
Over the past 5 years of our work in consulting, this process has changed quite often, but for the last two years we have used the one described below.
First meeting
After the first contact with a potential client (lead), we usually arrange a meeting or call on Skype. Before this meeting, I try to find out more information about the lead such as: how he / she found out about us, who he is and what he is working on, where he is, etc.
During the meeting, I talk about us, a little about our history and approach to remote work and management. After that we delve into the details of the future project and I try to find answers to the following questions:
')
- What is the project about?
- What are the competitors in the market?
- If there are competitors, then how is your project different?
- How is he going to make money on this project?
- Why did he decide to develop in Ruby?
- Does he have other developers or designers with whom we could or should have worked together?
If a client wants to develop a startup from scratch:
- Will the development of fulltime?
- Are there any other founders?
- How is he going to finance the project?
- Does he have experience launching start-up projects?
If the client is an organization with its development team :
- Which development team do they have?
- What technology stack do they use?
- How do they manage projects? Do they use scrum?
- Do they write tests?
- Why did they decide to resort to outside help?
Then we can move further into the details of the components of the project, which could be complex, such as payment, external API, etc. My goal here is to determine which technical features may require more time.
At the end, I ask the client to send me some useful information that he already has on the project, for example, mockups, design, presentation, etc. Some customers ask us to sign an NDA before sending materials.
Internal discussion
After the first meeting, I usually talk to Victor, our CTO, and give him information on the project that I collected. This is a key point, because Victor usually asks questions about the project, which I did not think about during the first meeting with the client. We make a list of new questions to the client and we either write to the mail or get answers to them by phone.
At this time, Viktor and I are discussing other things, for example, how this project can fit into our calendar, which framework, library or technology it would make sense to use in this project, and how similar these things are to what we have already realized ( in order to improve our future ratings).
We write task and make their assessment
After we have dealt with our main questions to the client, we begin to paint user usage scenarios (user-story). We usually create a temporary project in PivotalTracker with all user-story. We add them to epics to group them by functionality, for example: users, payment, orders, admin panel, etc.
Then we do the assessment using the Estimation Party . Usually we ask someone from our team to join this process in order to have the most clear assessment.
We estimate the complexity of each user-story on a scale of 0, 1, 2 or 3 points. Very roughly: 1 point is half a day of work, 2 points a full day and 3 points will take 2 days of work. If we see that some user-story is more than 3 points, we break it into more than one user-story.
As soon as we have evaluated all user stories, we add such routine tasks as creating a basic application, creating a repository, creating a staging environment, or creating mockups if they are not there.
Determine the price plug
We summarize all the points of the estimated user-story and divide them by our internal velocity - the number of points that one developer can implement in one week (based on previous projects). So we will know how many weeks the project will take. Example:
Total Points: 120
Our cycle per week: 12 points
120/12 = 10 weeks
At that time, we have a project assessment in weeks. However, our experience tells us that we all also know less than half of the details of the project - the rest either the client is not up to us or he does not yet know about them. Customers always learn more about their project during its development. Given this, we increase our assessment of something like:
Estimated time: 10 to 14 weeks
Then we multiply the resulting time by the average number of paid developer hours per day, which is about 7 hours (we work 8 hours, but we write out the bill only for the productive time of work), and finally multiply the number of hours by our hourly rate:
10 weeks * 5 days * 7 hours * $ 100 = $ 35.000
14 weeks * 5 days * 7 hours * $ 100 = $ 49.000
Cost estimate: from $ 35,000 to $ 49,000
Here we also decide how many developers it makes sense to involve in this project, given how many user-stori can run in parallel. If we decide that two people will be able to work in parallel, then we divide the temporary assessment in half, but the cost estimate will not change.
We send an assessment
And in the end, we send the client either a simple PDF document (several pages) or email with all user-story (and their estimate), time and cost estimate. We try not to spend a lot of time on drawing up fashionable documents, we do not see the point.
In this message, we immediately say that this assessment is made on the basis of the information that we have at the moment. We also explain to the client that he has complete freedom to change the course of project development without discussing with us why we did not include it at the beginning of the project. The only rule for making changes in the workload is that they must be made at the beginning of the week (during the planning of the sprint), but not during the sprint.
We check the score before each sprint
After the project has been approved and development has begun, at the beginning of each week (usually we work with weekly sprints) we do a sprint-planning where we decide which user-story we will work on this week and what information we need from the client to implement them. At this point, we often find new details in some user story and change its assessment.
With weekly iterations and daily stand-up meetings, we provide the client with transparency of the development process, what has been done, what remains and how we are close to the initial assessment. Thus, there can be no surprises.
Please note that we require our customers to designate a product owner from their team who must attend every stand-up rally and sprint planning. It is necessary for us.
Conclusion
Evaluation of the project is a key part of the project, but this is something for which we do not take money and can not always get this project. Therefore, our goal for the whole process is to keep it as simple as possible in order to avoid potential costs, trying to be as accurate as possible in our estimates.
Source: https://habr.com/ru/post/293786/
All Articles