We started to develop Drupal-based projects in 2005 when Drupal 8 was released. With seven years of Drupal development experience, we’ve learned how to estimate Drupal projects really well. This is what happens when we receive an inquiry about estimating a Drupal project.
First and foremost, we gather and analyse the client requirements, project scope and budget range. Then we decide if this project is a good fit for our agency. We think of our development and management resources, and try to be realistic about whether or not we should start working on the project.
Decomposing the project
Before we can estimate any project, we have to break it down into separate pieces. It’s time to set up a few discovery meetings – contact stakeholders and ask a lot of questions about project’s scope, vision, software requirements and other high-level goals. Another important job to do is to find opportunities for functionality simplification, as it can save a lot of time, money and energy for both client and developers.
Based on the knowledge we’ve gained through discovery meetings, we create a project backlog, a document, which breaks the project into several major features. Then, these features should be broken down into smaller problem sets. This way, we can decide, which project elements may require custom development or ready-to-use Drupal solutions. On average, we need two days to incorporate separate Drupal content type, “Markup”, “Views” module into a website.
Another benefit of breaking the project to the smallest chunks is that we have a better insight into team’s progress and fall back. This allows us to reveal any problems at the early stages and discuss their possible solutions.
Estimating the time to complete a project
Time is a valuable thing. Neither we nor our clients want to waste it on mindless, non-productive activities, so we try to always get to the point and be very respectful of time. Whenever our client asks how long will it take to carry out a project, we have to address these questions.
- How many people will work on this project?
- How much of the work can be parallelized?
- Is this project going to have a fundamental change in architecture?
- How many brand new features are to be built?
- Do we plan to do lots of QA?
- Have our developers done this kind of work before?
Then, we come up with a rough estimate of the project’s time frame. While, as we’ve said, this estimate is far from being a precise one, we still need to inform a client about a project’s timeline as well as provide a target date that everyone can work towards. It’s important to understand that when we work with software, based on constantly changing code and people, that might be unpredictable and irrational, making predictions could be troublesome.
Reviewing previous projects
At this point, we try to get the most of our developing experience of similar projects, we’ve already completed. We review what Drupal solutions were used, how many hours they took to implement, how the budget turned out, what was complicated and what was easy etc. This technique helps a lot with making a realistic project estimate.
Calculating project cost: pay-per-hour / fixed price projects
Usually, to calculate project’s cost we sum up all programmer hours, that are required to complete all tasks. Codesushi uses a fixed hourly rate: $65 per hour. In case, if we need to spend more than 200 programmer hours, this rate goes down to $62. As you can see, in this case, it’s all about time consumption.
In case of a fixed price project, we either work with an existing budget of our client or help them to set a realistic and accurate budget for a project. Oftentimes, a client decides to reconsider a number or priority of project’s features to reduce the scope of work and meet the budget.
To keep things transparent, we use a time-tracking tool called Toggle that allows us to submit time sheets every day. This way, our client is always aware of our progress.
If you have any questions on this topic or just want to share your thoughts about Drupal development, please let us know in the comments.