Striving for Perfection: Is Ideal Project Estimation Possible? or How we estimate projects at JetBase

Everyone knows that accurate estimation of web development projects is important, but the question is how to achieve it. My name is Sergey, and I am CTO at JetBase. Every day, I estimate hundreds of projects, and on Thursdays, I conduct a team lead school, where there are separate lessons dedicated to estimation.

In our agency, we have developed a methodology for estimation and constantly refine it. Today, I would like to share my observations and experience with everyone interested. Be prepared for real examples from practice and no less statistics and figures.

I am writing this article for everyone interested in the topic, but primarily for my fellow team leads and also for our clients who contact our sales department daily and request prices. Accurate project estimation is crucial for these two categories of people.

I have often encountered the frustration of both beginners in team leadership and clients. Newcomers team leads feel frustrated when faced with insufficient client data and are afraid to ask additional questions, while clients, in turn, are puzzled when they see certain figures. Both need perfect estimation but is it easy to achieve? Let's figure out what's the real story.

Do You Really Want TikTok?

Let's start with a story about a client who once approached us wanting to create a social platform similar to existing and popular streaming applications like Instagram and TikTok. The requirements provided were quite general, as is often the case in 95% of situations, and, as usual, there was no mention of the project's business goals.

It wasn't difficult to guess that the business goal of the project was advertising sales. The client's overarching desire was to know how much time and money it would take to achieve this goal. Well, we could give approximate figures like 3 years and 1 million dollars but it's not our approach at all.

Our company's goal is to do quality work, and the objective of the technical team is not just to provide an estimate, but to analyze the requirements and outline the project's implementation over time, in sprints and stages.

We aim to evaluate the tasks that are essential to the project, concentrating on the core of the project. Over the years, it has become clear to us that this approach is more realistic and practical than giving rough estimates and then trying to fit into them. Moreover, the era of turnkey product development has passed.

Nowadays, all products are developed iteratively, evolving in the environment, in space.

Returning to the client who wanted to create a platform like TikTok, firstly, personally, I believe that copying someone else's path is not the most reliable way. From our perspective, we suggest not making a TikTok, in other words, not mentioning it at all. Instead, we propose analyzing the project based on its essence, describing its business goals, addressing the pain points of users, and figuring out how the product can solve user's issues.

In other words, create an MVP, test it, make changes. Only then will it become clear what the platform will actually represent. In the end, it might turn out to be completely different from TikTok, perhaps more like Snapchat.

About Project Estimation — In General and Very Briefly

Now, let's get to the essence — what the estimation process looks like at JetBase. We have previously written in detail about estimation in the article "Software Development Estimation: A Comprehensive Guide."

Here are the three main stages estimation process consists of (there will be theory, but after that, you will see it all in practice):

Estimation Stages:

Stage 1. Obtaining initial data from the client with wireframes, a brief from JetBase.io

At this stage, our team of developers led by a team lead conducts an analysis of the project, involving not only understanding technical aspects but also identifying the essence of the project. Often, this implies some business goal. For example, a client may want to create a website for conference participant registration or an app with vegetarian recipe recommendations. In the first case, the goal is ticket sales, and in the second, subscription sales.

Stage 2. Creating the project architecture, breaking it down into subtasks

If in the first stage described earlier we want to understand the project's essence — the core, then here, on the second stage, we take this big project idea and break it down into small parts, simultaneously visualizing the constructive functions. In other words, we decompose the large task into subtasks and create the project's architecture. This stage is crucial and unavoidable. There are many types of decomposition into subtasks, but we'll talk about that another time.

Visualizing the project workflow and architecture instills confidence in all involved, particularly those investing substantial funds. At JetBase, we sign contracts with our clients only after meticulously outlining project workflows through big, medium, and small tasks. This ensures peace of mind for our clients and fosters a clearer understanding in our collaborative work.

Stage 3. Project estimation by scope of work, roles, responsibilities, and hours.

Here begins the crossing the t's and dotting the i's — the actual estimation. At this stage, you need to engage your mathematical mind and not miss anything important; every numerical value affects the final amount. At the same time, do not forget that project estimation is not only science but also art, and much will depend on how you can see through the numbers and tables the essence of the project for which all this meticulous work is being done.

Successful Estimation. Real Example

Certainly, one must learn from mistakes, but in the Team Lead School, where I teach on Tuesdays, during a practical lesson, I provide an example of precise estimation. This is a real example from JetBase's portfolio, where we estimated hours with utmost accuracy. A miracle? No, just a mix of science and art and a lot of meticulous work. It took us two weeks for this estimation, and that is a relatively short time frame.

During the analysis stage, we found that the project's essence is participant registration for offline games. This was not explicitly stated in the client's initial data, but it is crucial to know from the start. Then, we took these initial data from the client and their wireframes, breaking the project into modules that describe what needs to be done at a high tech level, for example:

— Create the initial application — Connect database — Create project entities — Setup configuration for external services etc.

Next, each module needs to be broken down into features and sub-features with a detailed description for each on both the frontend and backend. Let's look at a real example. Here is a page from the mentioned project.

An inexperienced or disengaged team lead might estimate this page roughly and, let's say, allocate 8 hours of work. One can understand their perspective, as clients often approach developers for a quick and final project figure and are reluctant to wait for an extended period.

But at JetBase, we don't follow that approach. We invest more time in estimation, but we achieve a more accurate result. Here's what our estimation for the mentioned page looks like:

The thing is, for future project specialists, estimating sub-features is much simpler since it is a technically clear and understandable task that the team lead identifies during the estimation stage. This is where the secret of precise estimation lies — in meticulous decomposition.

And if you continue to decompose each module as in the example of the page discussed above, and then calculate all the risks and related tasks, the result is a clean and reliable estimation.

Below, I will provide an example of a poor estimation, and to conclude the entire story about good estimation, I can say that achieving the so-called ideal or purity is not that difficult. It is entirely possible and even necessary for all participants in the process. As Steve McConnell said in his book "Software Estimation: Demystifying the Black Art":

"A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets."

Unsuccessful Estimation. Real Example.

Before reaching the current level of estimation expertise at JetBase, we made mistakes. We learned to improve from them, and fortunately, there weren't too many. Now, I'll briefly mention an example of poor estimation, so you understand where the risks are hidden and why it's a sad story for both the team and the client.

Background:

Once a client approached us to create an online learning portal for actors and professionals in the film industry. There was very little data available initially, but we still estimated the project, resulting in a fixed overall estimate.

Outcome:

As I mentioned earlier, we provided a fixed price for the project. However, in reality, we ended up exceeding the estimated budget because it baceme apparent that more time was needed for the work. While our client did not object to this, the issue arose when they did not make any payments for the work stages (sprints), which allowed them to reject the project entirely at the end.

Consequently, we had to redo the entire project, which required double the effort, yet we were not compensated for our work. We worked without payment to safeguard our reputation, while our client lost their precious time and became disappointed with their experience in web development. Mistakes should be compensated.

Where the mistakes were buried:

• Client provided insufficient data at the start.
• We didn't utilize agile methods.
• Client didn't pay for work stages, so wasn't involved in interim results.
• We provided a fixed price instead of estimating sprints (we could have used the accurate estimation method described earlier).

Summing Up

Regarding those two examples of estimation provided above, it's evident that certain strategies and practices are crucial for accurate estimation in web development.

From these cases, several key conclusions emerge:

• Fixed-price estimation should be avoided as it often doesn't accurately reflect the actual needs of the product.
• Clients' requests often do not align with the reality of the project either.
• More input data at the start leads to better estimation accuracy.
• The more meticulous the decomposition of tasks, the more accurate the estimation will be.
• Effective communication, such as involving clients in regular demo overviews and planning sessions, is essential for informed decision-making and efficient product development.

In addition, I want to emphasize that the problem of accurate estimation and, in general, any technical issues are not just technical problems that the IT sector should worry about. Clients and businesses must also be involved; then, there will be more green light for meticulous estimations, leading to mutual benefit and less demand for clumsy fixed-price approaches.

I hope my article was helpful for both IT professionals and stakeholders looking for a web development team. Feel free to contact us if you need a project estimation — we will do our best to tailor it to your specific needs.

Source: Business’s ‘It’s not my problem’ IT problem.