Practical Software Estimation Measurement

Introducing an Estimating Tool to your Process Isn’t all that Scary

Software Estimation Tool

Many organizations have a need and interest in introducing tools for estimating their IT development efforts, but are reticent due to the perceived disruption, or all out difficulty of execution.  Estimating touches many parts and processes of the organization, so implementation can seem daunting. However, many organizations I work with are surprised by the relative ease of the integration and how the results pay off in spades.

While a process may have been in place for years, or merely months, any good estimating tool should be able to adapt and be woven into that process.  This includes aligning the estimating tool to the nomenclature of the environment and customizing the tool to an organization’s project types such as Cloud, Agile, ERP, Waterfall etc.  Even a seemingly small step of branding the tool itself to the corporate identity, via company logo placement, can help.  Once a tool has your environmental language and “feel” embedded, it starts to belong.  Initially, all of this can be accomplished at a very centralized level – one or two projects with no need for disrupting the work of the project staff.   

In addition to making the look and feel of the tool align with your organization, another step is to understand where and when the tool's functionality should be enacted in your process.  Often there are established decision gates for estimating throughout the development process in which an organization has the opportunity to enlist a tool.  In the very early concept stage of a project, we are usually asked to create an estimate with little to no concrete information.  At this point in time, we can leverage historical data for calibration, which is better than a guess.  Then, as we learn more about the projects intended functionality and attributes, we can create a refined estimate with a better grip on sizing, staffing and other metrics. 

From singular releases/projects, we can scale estimating to the enterprise level.  Aggregating multiple releases into a portfolio view allows us to better gauge the portfolio resource demand vs. the available capacity. Some organizations will employ a Project Portfolio Management (PPM) tool into which cost and schedule data are entered in the PPM, but typically as a plan, not an estimate (there’s a difference).  And the source of the planned cost and schedule are typically someone’s best guess, leaving the portfolio vulnerable to compounding errors in both metrics.  By integrating your estimating tool into your PPM, your portfolio of project/release estimates will now be based on sound, empirically-based data, providing confidence in the overall portfolio budget and schedule.  The aggregation of estimates into the PPM can be happening in concurrence with the individual release estimating to streamline the process.

The last thing we want is to double the effort of anyone involved in a project lifecycle through more process. Integrating and automating parametric estimation into an existing process paves the way for ROI through more efficiency and greater accuracy.   

Blog Post Categories