Avoid common pitfalls during Java EE project estimation

You are a project manager of a critical software project. The senior management is on your back to deliver, your budget is running out, the pressure from business is building up, and the CIO is annoyed for continuous slippage in schedules. In addition, your development team is extremely frustrated with the unreasonable project schedule and long working hours. Sound like a familiar situation? This article examines the common problems during project estimation that lead to such situations and offers some suggestions for improvement.

Some of these points are applicable to any software project, irrespective of the technology used. And their commonality is that they all can contribute in their own way to better project estimation.

Identify the right person to do the estimation

Identification of the right estimator is the first and most important step of any estimation process. You should always ensure that the right person—rather than the most available person—is in charge of performing the analysis and estimation. Apart from the knowledge of formal estimation techniques, the person should have a sound knowledge of the business domain and technology proposed in the project. A nontechnical person would never know the implication of any architectural constraints or technological choices on actual development time.

Consider the proposed technology, framework, and tools available for the project

Various frameworks and tools are available for Java EE projects. Each framework has its own capabilities, limitations, and learning curve involved. The impact of these factors comes into focus once the project enters its development phase. When preparing an estimation, one should complete a first-level investigation to find out the suitability and impact of these choices on the project, and the team’s present and future training needs to adapt to them.

Consider integration with the external/third-party systems

External system integration is an extremely volatile and often underestimated section of a software application. More often than not, the requirements document will have a one-liner stating that the system should send/receive data using existing systems and APIs. This section should be carefully verified for the facts. Based on system details and complexity of the communication protocol, adequate effort should be accounted for. If the details of the “how and when” of communication to the external system are not available at the time of estimation, this portion must be included as an assumption in the estimation and should be a candidate for re-estimation after low-level design. Remember, there is no plug and play in the real world.

Consider existing enterprise components

In most organizations with existing IT infrastructure, some reusable enterprise component is available and mandated for new applications. Clients always promote reuse for various reasons like consistency, maintainability, and savings in effort. However, it is important to note that the effort required for understanding the design of these components and verifying the feasibility of their usage in the new system should be included in the estimate.

For example, the client organization may already have a user authentication and authorization framework in place that may need to be integrated with the new application. This situation has the potential for “runtime surprises.” Chances are the new business requirement is not being addressed by the existing framework—and may require some enhancements. Also, if the capability and limitation of the framework is not available at the time of estimation, then it must be documented as an assumption.

Consider existing architectural standards

Consideration of existing standards is another often-neglected area during estimation and can have a significant impact on effort. Much additional work can be avoided if existing standards are available. But on the other hand, standards can impose many constraints on the actual design and implementation. For example, a simple requirement to capture and display a customer’s financial information on the screen could be achieved simply by adding a text area on the screen. However, the scenario could totally differ if the client has a document server that maintains the customer’s financial information across all applications. Now you need to establish the communication protocol with the document server, exception handling, and all other standards. This is a sizable effort. You should give equal importance to the architecture standards along with the business requirements while doing the estimation.

Consider actual testing effort

With the evolution of automated testing tools and frameworks, the actual testing effort can now have a much larger variance as compared to the old-school way of creating and executing the unit test cases. For example, if creating and running JUnit test cases is required, instead of the conventional unit testing methods, additional development time and higher learning curves may result. Hence, the testing approach should be mentioned clearly along with the testing estimate to avoid any issues.

Consider interdependent parallel developments

When multiple, interdependent applications are being developed in parallel, the situation is more dynamic. If the application has any dependency on ongoing developments, then these dependencies must be identified. Each interaction should be verified for feasibility, with attention given to the other development projects’ risk profiles. For example, say the application must show a customer’s credit details, which are retrieved from an external system using enterprise APIs, but the enterprise APIs are still under development by another team. The API should be in ready-to-use state when you are developing your application. Testing the application with dummy API calls and again replacing them with actual calls will require additional time as compared to using the actual APIs in the first place. The estimate should mention the impact of any such dependency in clear and quantifiable terms.

Use part-to-whole approach

The old adage of “divide and conquer” definitely holds well in software estimation. It is always better to divide the work into smaller work packets and identify the list of activities to be done for each smaller unit. The sum of the each activity’s estimate turns out to be a more accurate estimate than that of the entire project as a whole.

Conclusion

In today’s IT industry, where there is tough competition to deliver quality products on time, correct estimation is vital. The collective impacts of all the minor details of a project, which are often ignored, have a significant affect on the estimate. Several such items mentioned in this article should be used along with established estimation techniques to minimize the possibility of error in estimation.