Create a budget and set an ROI target goal
Estimating Cost vs. Actual Cost
Two common executive questions I hear are: (1) what will be the software project’s cost? And, (2) how quickly will there be a return on the investment? These are very specific questions. To provide specific and accurate answers, these questions require an in-depth review. And, there will likely be a considerable time investment to discover and to uncover specific needs, to establish and prioritize goals, and to set project budgets.
However, for some software project discussions, this level of work detail may be like putting the cart before the horse. A potential software project may first need to navigate through an internal vetting process before it can be included in a formal budgeting discussion; and, perhaps, for vetting purposes, only a general idea of project costs may be necessary.
Based upon my experiences, what executives may be really seeking is the answer to this general type of business planning scenario: What might be the “typical” cost range and time required for a similar sized project to ours, so we can plan for its impact on the rest of our company’s budget; help estimate the required resources needed; and, to project IT staffing needs? And, then, based upon these general estimates, maybe we can determine if the project is affordable, or cost justifiable so it can move forward to a formal budget process. Whew! Does this broad scenario seem familiar? I hear it often.
There is an inherent difficulty with trying to address “what if” planning scenarios like the one above. Questions can be really awkward to answer, and often answers are inaccurate because, as noted earlier, no two projects have the same blueprint or the exact same complexity. In reality, there is no such thing as a “typical” project. Each one is unique.
Complexity and Project Duration
I can definitively say that a project’s complexity will correlate directly to both time requirements and to budget costs. For planning and vetting discussions, one can make a few educated assumptions by using the chart below to guesstimate a project.
To visually illustrate complexity, the graph shows three different ERP software project types: an upgrade, a migration, and a new implementation. Note that each project type offers different examples of complexity: low, medium, and high. At a glance, as one might expect, an ERP version upgrade in an existing environment should take considerably less time and cost less than a completely new and highly complex ERP implementation.
* Other commonly included modules may be Human Capital Management (HCM), Customer Relationship Management (CRM), Payroll, Supply Chain Management (SCM), and Business Analytics (BI)
† Additional time may be required for specific third-party program integrations, personalization, data migration, and custom software development
‡ Project cost range examples are conservative; and, actual results may vary due to other factors
Chart Usage Assumptions and Directions
If one’s project only pertains to financials, then use just the purple portion of a bar as a reference point. If one’s project has financials and distribution, then add the purple and dark blue bars together, and so forth to approximate a project’s duration. Then, align the project to its estimated low, medium, or high complexity bars. By combining or subtracting the colored software application segment bars on a line, one may be able to build an approximate idea for a software project timeline and a budget cost range estimate.
Actual cost results may vary significantly due to unknown factors. Please realize that true project costs and ROI cannot be fully identified without an in-depth discovery effort.
The justification for a software project may be measured with tangible metrics with easily identifiable savings generated by a reduction in errors, or in improvements to labor efficiency. However, the justification could also be measured with intangible savings like reductions in customer service calls, or fewer warranty repairs. And, there are times when the justification may be measured by reducing corporate risk and legal exposure due to previous product recall liabilities. Finally, sometimes justification reflects various degrees of all of the above for one’s own business reasons. All cost justification techniques may be equally valid.
Every company has their own financial preferences and formulas used for cost justifying a project. Companies can utilize an internal rate of return (IRR) formula, a project’s net present value (NPV) formula, or calculate the payback in terms of time (it will take “x” number of business months/days in savings to pay back the investment spent).
Additionally, one’s accounting department may have their own return-on-investment (ROI) measurement standards for projects, such as if the project expenditure is less than $500K, then the ROI goal should be within 24 months; or, if the project’s expenditure is less than $1M, then the ROI goal should be within 36 months. Or, it may be that an IRR goal should be 20%; or, that an NPV goal should be 15%. Every company sets their own financial ROI goals and targets to be attained.
A budgeted software project and its ROI are often viewed as two sides of the same coin. For ERP projects, there is nearly always a positive operational payback, and a financial ROI that will be attained. The variable may be in how quickly the ROI will be reached and surpassed.