Estimate The Upgrade

With a clearly defined scope document in hand, you are now ready to build a reliable effort estimate. This process translates your detailed list of tasks into the person-days required to complete the project, forming the bedrock of your final upgrade plan.

This guide provides a practical, bottom-up estimation process. It should be used alongside the official documentation's guide on Key factors impacting upgrade effort, which provides essential context on what makes an estimate go up or down.

The estimation method you use will depend directly on the Upgrade Approach you selected earlier: Incremental or Reset.

Estimating an Incremental Upgrade

For an incremental upgrade, the most reliable estimate is built from the bottom up. You will estimate each individual line item from your "In Scope Tasks" table, which you created during the "Define Scope" phase.

Action: Build your bottom-up estimate.

For each task, estimate the development and unit testing effort. This detailed breakdown ensures you account for every specific migration and change required.

To help with this process, detailed Work Breakdown Structure (WBS) templates for specific platform version upgrades can be requested from your Quantexa contact.

Action: Validate your estimate with the top-down model.

Now, use the best practice estimation approach from the Documentation Site as a sense-check. Start with the baseline (e.g., 8 days) and adjust it based on the key factors.

Does your detailed, bottom-up total roughly align with the top-down adjusted baseline?

• If they are close, you can have high confidence in your number.
• If they are far apart, it's a crucial signal to review both your detailed estimates and your understanding of the influencing factors:
  • Have you underestimated the complexity of a required migration?
  • Have you overestimated the negative impact of your customizations?

Action: Add contingency and formal testing.

Finally, add a contingency buffer to your sub-total to account for unforeseen issues. Remember, this estimate is for the development and unit testing effort only. The effort for formal testing cycles (SIT, UAT, OAT) must be estimated and added separately.

Estimating a Reset

A "Reset" project is estimated in much the same way as a brand-new Quantexa implementation. The focus is on estimating the effort required to selectively re-implement the desired functionality in a new, clean repository.

Action: Estimate the "re-implementation" effort for each functional block.

For each major component of your current solution (e.g., Entity Resolution, Scoring), estimate the effort to build it in the new target version. When doing so, you must factor in the effort to align with modern best practices and to remove the technical debt you identified in your existing customizations.

As with the incremental approach, a healthy contingency should be added to this sub-total, and formal testing should be estimated as a separate line item.