Even after many decades of the IT industry being around, there still seems to be a huge impedance mismatch between non technical people and technical people. I am not even talking about the split between the business and the IT department. Those are worlds apart. What I am referring to is the impedance mismatch between business analysts and system architects. Technically a business analyst is not necessarily a technology person, however business analysts working with software development teams are technology people - they need to be otherwise they cannot bridge the gap between the two worlds. They are called Technical Business Analysts or System Analysts.

So when a requirement from the business is analysed by the business analyst, and handed over to the system architect for estimation, even when it is just a high level estimate, sufficient details are required to enable such an estimate. The problem here is that the business analyst needs to understand enough of technology to provide sufficient information and to understand a very, very important aspect of system engineering. Many times the bulk of time and cost on a project is not spent on the easy, straight forward aspects. Many times the cost (and hence the reason so many projects overrun their budgets) are due to the exceptional conditions, the border cases that are extremely hard to work around and requires a huge amount of effort to implement.

So when a request is made for certain system changes, especially when those system changes consist of a myriad of potholes that will need to be navigated around, before an estimate of cost can be delivered at least some depth of analysis is required to understand the extent of these exceptions. I have built systems where the code for performing 98% of the system's operations were written in 30% of the time/budget, the final 2% took 70% to complete. Sometimes this is called the Pareto principle.

In my experience very few business analysts understand this, hence the ongoing struggle to provide seamless support to the business without appearing to be unnecessarily stubborn. I am sure the client would not be happy with an estimate that could be incorrect by as much as 99%. So spend 1 day more analysing requirements and the inaccuracy in such an estimate might go down to 20%.