Simple and Accurate Development Estimation for Non-Coding SIers

In this article, I will introduce the "Solufa Method for Estimating Development Effort," which I use for my own reference based on my experience in system development projects for public and infrastructure-related large enterprises with total budgets ranging from 100 million to 1 billion yen. This is not meant for formal documents submitted to clients, but rather as a tool to help you predict, with minimal effort at the start of a project, to what extent it will exceed its budget or deadline.

The Larger the Development, the More Estimates Deviate—and Usually for the Worse

According to the bestselling book "BIG THINGS," in large-scale system development:

• Budget or deadline exceeded: 91.5%
• Of those, budget exceeded by more than 50%: 18%
• Average overrun rate when the budget exceeds 50%: 447%

The reason management remains viable despite such massive estimation failures is that large companies can earn back losses from development through operations, similar to a "printer and toner" business model. Alternatively, there are cases where the enormous operational profits generated by core systems built long ago for local governments or society are invested into new projects for tax savings or to suppress dividends.

However, with changes in the era such as cloud computing and AI, profit margins from operations are decreasing. I'm sure you've noticed that major SIers are increasingly being required to implement high-ROI management that generates profit starting from the development phase. As the person chosen to be the PM, you likely want to avoid budget overruns, deadline extensions, and quality issues in your project if at all possible.

The first hurdle is creating an estimate at the time of order. In the past, every project seemed to have a department that produced thick, detailed design documents and created precise estimates. However, my analysis suggests that because the number of projects has exploded with the advancement of the Web, and because of the rise of "chimera-type waterfalls" that incorporate only the bad parts of agile development, regular employees (propers) with no design or development experience are forced to handle requirements definition, design, and estimation with just a few people.

Let's break down the reasons why project failure is often determined at the point of order.

Cause #1: Reusing Inaccurate Estimates as Precedents

Are you looking for documents from past internal projects and using them as templates? And are those past documents still in their original state from when the order was placed, without any corrections based on actual results? If you use an estimate from a project that failed to meet its targets as a template, it’s only natural that you’ll fail again. However, actual values are buried in deep, fragmented hierarchies for each project in the company's shared storage, making them nearly impossible to aggregate.

Cause #2: Total Budget is Fixed Regardless of System Complexity

The seemingly natural flow—defining requirements, designing, submitting an estimate to the client, negotiating, and then determining the order amount—almost certainly does not happen in projects where buzzwords like "PoC" or "We'll do it with Agile this time" appear. The order amount is decided first by factors unrelated to the system, such as the approval authority of the client's representative or municipal budgets. Ultra-massive projects worth hundreds of billions of yen or mission-critical projects might be different, but I haven't seen them directly, so I wouldn't know.

Estimates tend to be sloppy when the budget is decided beforehand. After subtracting fixed costs like the cloud from the total budget based on precedent, you simply determine the difficulty ratio of the functions to be implemented and allocate man-hours. It’s just a matter of assigning coefficients—like 15 for "Payment" because it's the hardest, and 2 for "Login" because the internal framework can be used as-is—and distributing the remaining budget. If you divide it by, say, 1 million yen per month, you get the number of man-months.

Cause #3: Lack of Involvement from Engineers Capable of Building It Alone Given Time

Even for regular employees who can't write code, the typical "golden path" is that they usually have at least Applied Information Technology Engineer certification and bring in one external consultant to handle everything from requirements definition to creating estimates. Nowadays, you can use AI, and you can get help from the outsourced companies (correctly called "partner companies") that have already been decided internally.

The reason estimates still miss the mark is that no one, including the consultants or the engineers from the partner companies, can build the system themselves, which means they can't imagine the communication costs and coupling complexity that arise with every added feature. Clients and sales reps casually add multi-language support even for systems used only by Japanese people, and the estimation team cannot offer high-resolution counterarguments. Even if they ask AI, they can't frame the right questions, so only generalities are output.

To see through the future in a chimera-type waterfall—where thick detailed designs and estimates are no longer made and specifications change by the minute—you need an engineer with the resolve to think, "If worst comes to worst, I'll just build it all myself." However, such talent is not in your hand.

The Solufa "Actual Personnel Area" Estimation Method: Improving Accuracy with a 5-Minute Chat with Experienced Members

The method introduced here is based on the "actual number of people on the project" rather than past estimation documents. Formal documents are unreliable because they are either not maintained at all or edited conveniently. In comparison, human memory is much more accurate. To the question "How many people were there at that time?", people give answers closer to reality than the documents do.

Step 1: Find Someone Experienced in a Similar Project

First, identify past internal projects with similar configurations for both the application side (frontend/backend) and the infrastructure side, based roughly on the following perspectives:

• Business domain (e.g., EC, business system, etc.)
• Tech stack (cloud environment, frameworks)
• Number of external integrations (payment, authentication, other system links)
• User scale

Since there won't be a perfectly matching case, a 60–70% subjective similarity is sufficient.

Step 2: Ask "How Many People Were in the Team?" Along a Timeline

Find 2–3 people who were involved in that project from start to finish and interview them in the flow of a casual chat.

"Roughly between which months and how many people were in the team from the start to the end of the project? It's fine to provide what you remember."

If you ask them to research and reply later, they might refer to the documents, which actually decreases accuracy. Information gathered from a 5-minute chat is enough. If possible, asking for the number of people per phase makes it easier to correct during aggregation.

Step 3: Plot on a Graph and Calculate the Area

Plot the information you gathered, with the number of months on the horizontal axis and the number of people on the vertical axis. If you gathered information from multiple people, take the median. About 5 to 10 data points should be sufficient.

Number of People
 12 |
 10 |          ●───●
  8 |        ／      ＼
  6 |      ／          ●───●
  4 |    ●                    ＼
  2 |  ／                        ●
  0 |●────────────────────────────
    0  2  4  6  8  10 12 14 16 18 (Month)

Connect the points with straight lines and calculate the area under the graph. Simply dividing it into rectangles and triangles and summing them up will make the area directly represent the "total man-months."
In the example above, a rough calculation would result in approximately 120 man-months.

Step 4: Sum Up App and Infra Separately

The man-month unit price and the personnel transition curve likely differ between the application side and the infrastructure side.

• Application Side: Numbers tend to increase in the middle, and the peak is likely to extend past the deadline (development and testing often overlap).
• Infrastructure Side: Peaks are likely to occur at the beginning and end (environment setup and production migration).

Conduct interviews and create graphs for each separately, then multiply by the unit price and add them together.

Application Side: 80 man-months × 1,000,000 yen = 80,000,000 yen
Infrastructure Side: 40 man-months × 1,200,000 yen = 48,000,000 yen

Step 5: Add Fixed Costs to Get the Total Amount

Reference fixed costs such as cloud usage fees, license fees, and external service fees from past project documents. These shouldn't differ significantly between the estimate and the actual results.

Personnel Costs: 128,000,000 yen
Fixed Costs: 22,000,000 yen (AWS, SaaS integrations, etc.)
─────────────────
Total: 150,000,000 yen

Why Does This Method Improve Accuracy?

Using Actual Results Instead of Estimate Documents

Past estimate documents are merely "wishes" of how things were supposed to go. In contrast, the "actual number of people" is the result. It reflects everything: the fact that people were added because a project was in trouble, or that it required fewer people than expected.

Memory Reflects "Actual Work"

In formal man-hour management, someone might be listed as a "0.5 man-month assignment" but was actually fully committed, or vice versa. What remains in people's memory is not the numbers on paper, but the number of people they were actually working with.

Asking Multiple People Reduces Bias

One person's memory can be biased. Developers remember the development phase in detail, while PMs remember the big picture. By layering testimonies from multiple people, a figure closer to the actual state emerges.

How to Use This Estimate

The numbers produced by this method cannot be used for formal estimates submitted to clients because you cannot explain the basis. However, as a PM, it serves as a yardstick to judge whether the project will truly finish within budget before taking the order.

• Formal Estimate: 120 million yen
• Solufa Method Estimate: 150 million yen
• Difference: 30 million yen (Potential 25% overrun)

If you can see this difference, you can adjust the scope or propose a risk buffer during the negotiation stage. Even so, the world is full of projects that cannot avoid trouble, but since you can see the end result, you should be able to make up your mind early and reduce the total damage.

Summary

• Use "actual number of people" as a precedent instead of past "estimates."
• Just ask experienced members, "Roughly how many people were there and when?"
• Plot it on a graph and calculate the area to get total man-months.

For estimates submitted to clients or bosses, follow precedents and handle them safely, and use the Solufa method for documents you use as your own guide. In a world where 91.5% fail, this is the first step toward your project being in the remaining 8.5%.