Reflecting on My First Year as an IT Engineer: Major Failure in My First Cost Estimation

Overview

As a new graduate engineer, I would like to write about the estimation experience I had at the end of my first year.

At the end of my first year, I was lucky enough to be involved in estimating a project despite being a rookie. This is a story about how I failed by making an underestimated proposal.

*Note: The actual development took place at the beginning of my second year. I plan to write about the struggles of that phase in a separate article.

Objective

This article aims to reflect on my experience with estimation and to provide perspectives on what to be careful about next time I have such an opportunity.

I hope this will be helpful for those who are involved in estimation for the first time.

Reflection on the Estimation

Prerequisites

It was around February or March of my first year as a new graduate.
I had been in charge of system development for the same client for about half a year since my first assignment.

The project was an agile development project, and I had already experienced two development-to-release cycles. The estimate was for the third round of development.

Also, the scale was roughly 2-3 people working for about 3 months.

The estimation was handled by a two-person team: the PM and myself.

Actual Estimation Work

The tasks I was actually involved in were as follows:

• Hearing requirements from the client during weekly meetings
• Preparing for the weekly meetings
• Estimating development effort

Note that the PM was in charge of anything related to money.
*Parts related to money: Calculating the estimated cost based on development effort, negotiating the price with the client, and signing the contract, etc.

I will elaborate on these tasks a little further.

Hearing requirements from the client during weekly meetings

Since it was an existing client, we held weekly meetings, and the process was mainly for the client to explain their requirements.

While it depends on the project, it wasn't a situation where we were heavily proposing solutions from our side.
It was more like the image of requirements definition.

We would listen to the requirements summary, dig deeper into the purpose and specifics of what they wanted to do as needed, and present several ways to achieve it.

Preparing for the weekly meetings

Naturally, we had to prepare in advance.
This mainly consisted of preparing materials for the proposals we would present.

As written in the previous section, the main focus was explaining plans to achieve the client's requests.

In particular, for parts that heavily influenced the effort (and cost), we prepared several patterns and had the client select one, which was our approach.

Estimating development effort

Next, we started estimating the development effort.

Once the development image became solidified and we reached a timing where it was "about time" in terms of the schedule, we submitted a rough estimate.

Regarding the "about time" aspect of the schedule, there was a general desired release date, and we had to work backward from the period of "Estimate submission -> Client approval -> Order -> Development -> Release" to determine that it was time to submit the estimate.

*Depending on the client, the approval and ordering process can take a fair amount of time.
In my project, it took nearly a month, so it was necessary to move quickly.

Effort estimation was done by solidifying the image of functions and deliverables for the client's requests and calculating based on our past development experience.

In my project, the development used Salesforce Flows (low-code development), so for example, the estimate looked like this:

• The XX feature requires 3 flows, each taking 4 days, for a total of 12 days.
  Thinking through this phase by phase and function by function, a total of 60 days of effort was required.

Finally, I submitted it to the PM for review and correction before presenting it to the client.

*It seems there were price negotiations afterward.

What to watch out for in estimation

As I mentioned at the beginning, the estimate I created was an extreme underestimate, and the period required for actual development was too short.
*As a result, there were various chaotic moments during the development.

Here, based on "what kind of failures I made in estimation," I will write about what I think should be handled carefully.

Failing to break down tasks

It goes without saying, but if tasks are not broken down, the estimate will be too small. You should break down tasks before estimating the effort.

For example, I feel that I overlooked tasks such as the effort required for code reviews and the creation of test specification documents.

I would like to write more specifically about the "creation of test specification documents."

I feel that the reason I overlooked this task was that the development was centered around new members due to member turnover.

Until then, one member would be responsible for one feature and handle everything from development to testing. Also, even when other members helped with testing, they were existing members who understood the content well.

Therefore, to put it extremely, it was fine to write sloppy test specification documents.

On the other hand, this development was centered around new members. It became more common for development and testing to be performed by different members who did not understand the specifications well.

Therefore, it was necessary to write the test specification documents more accurately and in detail, which took more effort than anticipated.

Not performing risk analysis for each task

This leads to the topic of test specifications in the previous section, but risk analysis is crucial.

In system development, you never do the exact same development twice, and many risks are lurking.

For example:

• Member turnover
  • It takes effort to catch up on the project and technologies.
• New technologies
  • It takes effort to investigate and catch up on feasibility.
  • *This requires sufficient consideration even with low-code development.
    Rather, low-code may have more constraints, so one must be careful about feasibility.
• New clients (or new contact persons)
  • If there is a misunderstanding about communication rules, that will become a bottleneck and delay development.
  • For example, response speed is surprisingly important; I think you should be careful if replies to questions are slow or if decisions are constantly postponed.

After analyzing these risks, you need to take countermeasures or submit an estimate that includes risk buffers.

Perceiving requirements as minimal

Requirements tend to expand.

More requirements emerged than the requests I had heard during the estimation, which ended up squeezing our effort.

To be precise, during estimation, the requests are abstract, and they become specific requirements as development progresses. In that process, more functions than anticipated end up being necessary.

It is inevitable that requests are abstract during estimation. Therefore, I believe it is necessary to concretize for yourself what kind of functions seem to be needed for those abstract requests.

On top of that, it is required to reflect that in the estimated effort including risks.

Alternatively, it is also important to clarify the "estimation prerequisites" when making a proposal or estimate.

Since assuming "all possible functions" would lead to enormous effort and cost, you can prevent requirements from ballooning by aligning with the client on "the assumption is that we will develop up to this point" (if requirements do balloon, it is easier to get an additional order).

Not taking requirements definition lightly

If requests expand, it also takes a lot of time to decide on them.

In addition, requirements definition is not something that we can just work hard on unilaterally; it requires close alignment of understanding with the client.

It is necessary to consider not just the effort, but how many meetings will be required.

For example, suppose the requirements definition is estimated at 10 days. If the weekly meeting is only once a week, you can only hold 2 meetings, which is far from enough to complete the requirements definition.

Also, care must be taken with how effort is used.
For example:

• If one PM is involved at 0.5 man-months (due to concurrent work with other projects), "estimated effort is 10 man-days" = "actual period is 20 days."
• On the other hand, if two PMs/members are involved at 1 man-month each, "estimated effort is 10 man-days" = "actual period is 5 days."

It is obvious, but the latter case is likely to be problematic.
And in fact, my estimate was in a situation like the latter.

*I believe it is also necessary to estimate by visualizing as much as possible how many meetings are needed and what will be decided in each meeting.

The order was split

This is somewhat special, but the order (release) was split for client convenience.
*Because if the order amount is large, approval takes time.

We planned to release several features in 3 months, but they were split into releases every 1.5 months.

Initially, I disregarded this because the effort didn't change, but there was a significant risk lurking here.

This is because if the period is long, you can have a certain degree of flexibility by shifting tasks back and forth.

For example, even if the requirements definition period in the previous section is short, you can adopt a method of prioritizing development from the functions that have been decided to protect the overall schedule.

However, in this case, because the release was split, task flexibility was not possible, and I ended up struggling.

Summary

So far, I have reflected on my estimation experience and written about things to be careful about.

• Tasks were not broken down
• Risk analysis for each task was not performed
• Requirements were perceived as minimal
• Requirements definition was taken lightly
• The order was split

Next time, I want to apply these lessons to be able to provide highly accurate estimates.
(Although, since estimation is difficult, I suspect I will probably fail again.)