Avoid common pitfalls during Java EE project estimation

Consider often-ignored factors to estimate your software project more accurately

By Chandan, JavaWorld.com, 04/03/06

Print
Email
Feedback
Resources
Discuss

Digg
Reddit
SlashDot
Stumble
del.icio.us
Technorati
dzone

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.