Nov/090
No Decision – May You Forever R.I.P. (Part 4)
This is the last installment in a series that has been discussing a problem plaguing many businesses today, and that is the situation of ERP or IT projects being aborted midstream before they accomplish their stated objectives. In the last issue, we discussed the means by which the project’s financial impacts would be assessed and projected. In this issue, we will summarize those projections with some commonly accepted evaluation formulas accompanied by the closing arguments for the project.
5. Get Out Your Calculator. We have explored the need for completing a thorough justification process and the strategic business imperatives that are driving the initiative. We have also discussed some of the potential benefits and costs to examine when conducting your justification. What remains is to simply tally up the projected value of your benefits and costs in a worksheet. You should then be able to determine the Net Dollar Value of Benefits with the following formula. With today’s extremely cash conscious business environment, I would focus more on the shorter term horizon measurements. In other words, focus on items that will have an immediate positive impact on the cash position.
Net Dollar Value of Benefits = Total Value of Benefits – Costs of Implementation
As the business climate and available credit improves, a longer term horizon measurement such as a simple Return on Investment may be appropriate.
ROI = (Net Dollar Value of Benefits/Costs of Implementation) x100
Different organizations use different perspectives to evaluate potential investments so I can’t tell you whether ROI is an accepted metric in your organization or not. However here are a few other measures you may find used to evaluate an investment.
A) Internal Rate of Return (IRR). This can be useful in comparing one investment opportunity in an organization vs. another. For example comparing an ERP system investment vs. a new factory investment.
B) Payback period. A simple determination as to how many months it will require to earn your investment back,
C) Net Present Value (NPV), this involves a bit of black magic so you may want to leave this to the finance folks
D) Total Cost of Ownership (TCO), simply looks at costs while ignoring value and benefits
6. Wrap it Up. You have now completed a thorough analysis of the strategic elements that are driving the organization to consider this investment. In addition, you have outlined the chain of events, symptoms and potential problems that are occurring in your existing environment. You have evaluated the various categories of value and benefits to be derived by the organization, along with supporting details. On the flip side, you have calculated all the projected costs over a fixed period of time. Assuming the numbers pencil, you have all the numbers to show that this project has been carefully analyzed for a positive business impact.
What remains now is to present your business impact analysis to the appropriate decision makes and stakeholders. When done properly, this process will not only justify the organization’s decision to move forward, but much more importantly provide a solid footing for the project to launch and sustain critical momentum when you get lost in the woods or the occasional storm surfaces on the horizon.
Nov/090
No Decision – May You Forever R.I.P (Part 3)
In our last issue we discussed the rationale and importance of developing a comprehensive business case for your ERP or IT project to ensure that it presses forward to completion and does not fall victim to the countless threats that swamp many projects. We also discussed the methods for determining why change, and in fact the project, is needed. In this issue, we will discuss how to determine the dollars and cents of the analysis.
3. Assess the Value. You should recognize that there are financial benefits and non-financial benefits, as well as tangible savings and intangible savings. Financial benefits and tangible savings are fairly easy to identify. While the Intangible savings will certainly require more digging to be able to quantify, don’t overlook them as they could be more significant than the tangible savings.
Possible benefit categories might include time savings, increased productivity, improved quality, employee quality of life, improved customer service, and reduced inventory. Each of these categories can be further analyzed for specific projections of financial savings. For example, reduced inventory is a tangible financial benefit that should also result in reduced carrying costs (reduced storage, less time handling inventory, reduced inventory obsolescence, reduced insurance expense), reduced freight expense, and improvement in working capital. There are very real financial benefits associated with each of these and you need to project those values.
Improved customer service would likely be considered an intangible financial benefit. However there are several sub elements, including increase in market share, decrease in customer complaints, decrease in returns or warranty claims, decrease in uncollectable AR and write-offs that could be projected to produce tangible savings.
4. Estimate the Costs. Identifying and quantifying the costs is more straight forward than tracking the benefits, but mistakes can still be made if you are not careful. First recognize that there are costs associated with the initial acquisition of the system (hardware and software), as well as installation costs. In addition, there are onetime costs and recurring costs.
An all too common mistake is to underestimate the costs, resulting in an over budget project. Why does this repeatedly happen? There can be a variety of reasons but the primary ones are indicated below.
- Costs are understated at the outset due to looking at projections through an overly optimistic scenario. Rarely do best case scenarios materialize. And when you consider the odds of best case becoming reality when it involves multiple people, processes, and deliverables from multiple organizations – well let’s just leave it at almost never and call it good.
- Costs are understated due to a lack of understanding of complete project requirements. The firm providing the ERP system may not fully understand the scope of requirements and therefore underestimates the costs. Or perhaps they low balled the estimate in order to win the business. Alternatively, the organization purchasing the ERP system may not have fully evaluated their requirements and capabilities, and thus has incorrectly identified the project scope.
- Costs are understated because the organization purchasing the ERP system is anxious to trim implementation costs and thereby takes on responsibility for self-performing much of the work, or simply eliminates what are deemed to be discretionary services such as training or report writing. It is a rare organization that is able to pull off a significant self-perform effort successfully. Consequently this will generally lead to a severely challenged project that is both late and short on deliverables, and ultimately over budget when the tasks are reassigned outside the organization.
- Costs are purposely underestimated in order to get a project approved with the thought that additional funding will be sought later once the project is off the ground. Thankfully we don’t see this approach often but it does surface in certain types of organizations.
- Costs are understated due to ignoring internal labor costs and diminished productivity during the implementation. Productivity suffers merely as a result of having to learn new systems. In addition, organizations will generally look at the wages for existing employees as sunk cost and not fully realize that every moment taken away from their primary duties results in incremental operating costs for the organization. This happens when normal productivity suffers due to spending significant time on non-core tasks, such as implementing an ERP system. The problem can be exacerbated by electing to reduce money spent on expert consultants (obvious incremental cost), and instead assign extra tasks to existing employees (less obvious incremental cost) that might be able to complete the task in a given period of time. Aside from the very real incremental cost of having the employee pick up the extra tasks, is the danger that the task won’t be completed on time or at satisfactory levels and now you may start incurring additional costs as other areas are impacted.
In the next issue, we will discuss the means for pulling all this hard work together into a credible and meaningful set of recommendations that demonstrates thorough analysis and provides the means to launch the project, and most importantly, complete the project.
Nov/090
No Decision – May You Forever R.I.P. (Part 2)
In the last issue, we discussed an extremely costly syndrome that plagues many businesses, namely that of projects that get launched with great intentions and then quietly run out of steam without producing tangible results or meeting stated objectives. I see this frequently with regard to ERP or IT projects.
Fortunately, there is plenty that can be done to avoid this wasted effort. However it requires a significant undertaking, careful analysis, clarity and organizational resolve to see it through. It requires lots of short and long term assumptions, as well as countless questions to be answered. When completed and properly documented, it results in a comprehensive business case for the project. This document is a critical tool used to justify the long term investment of organizational assets (people, time, money) to select and successfully implement an ERP system. It also serves as the foundational rock to guide and encourage the organization to continue pressing forward through the murky process.
Several suggested steps for a successful ERP software selection process are outlined below. Notice I said successful ERP software selection as opposed to successful ERP software review. After all we are focusing on ways to complete the project rather than getting halfway through and aborting it.
1. Determine to Justify. The first thing you’re probably asking yourself is whether the formal business case justification exercise is really necessary. After all, isn’t it common knowledge throughout the organization that the existing system is dysfunctional? If so, then why waste time documenting what is already known? Can’t we just get on with it and begin the shopping process? Sure you can, but in all likelihood you will end up regretting it. The reason is that you do not have a clear business imperative to proceed. What I mean by that is that you must understand the short and long term business reasons for embarking on the project. This will likely include the strategic objectives and vision of the company ownership and stakeholders. You should also consider the organization’s track record on difficult projects, and what other competing short and long term priorities might exist. In addition, you will need to identify the goals and benefits to be achieved, the measures to be used, and the problems to be overcome.
Conversely, if you are simply focused on certain functions that need improvement, you are looking at this more as a computer or IT project, as opposed to a critical business project. If it’s cast primarily as an IT project, your bullets will not be nearly potent enough to slay the dragons that lie on the ERP system path. Those dragons frequently come in the form of undesirable trade –offs, higher than anticipated costs, ambiguity and unclear outcomes.
Having a well organized and clearly documented business case will provide strong support from management and employees when the going gets tough. Without it you are merely relying on hope and faith to carry the day. Based on my experience, I can tell you that faith can go out the window when the challenges start mounting. The difficulty and risk involved in an ERP project is significant, and therefore in order to assume that risk, there must be clear and compelling reason to do so, and more importantly organizational resolve from top to bottom to succeed.
2. Quantify the Need for Change. Now that you have determined the value of a thorough business case justification project, the question is how to do it. At its most fundamental level, you are attempting to quantify the value of the benefits to be gained, versus the cost to attain those benefits. You are examining these benefits and costs over the perceived life of the ERP system, bearing in mind the timing of when specific costs and benefits are likely to occur.
It is admittedly difficult to determine concrete value from a new ERP system implementation. But far better to do it now, rather than after the money is spent. Credibility must be a critical overarching objective in the finished document. This requires soliciting feedback from several key people and departments, while frequently erring on the conservative side in your estimates.
Most organizations can readily identify functions in their existing ERP system that are not working well. However, a deeper inspection will frequently reveal several events occurring in the organization that may be symptoms of a bigger problem. For example, you may discover a chain of events similar to that illustrated below.
profits are down
→ sales are down
→ orders are not being fulfilled
→ excessive stock outs
→ excessive inventory obsolescence
→ poor demand and supply chain visibility
→ wrong inventory items being replenished ↑
You can see from this example that even though there are a variety of problem events taking place, the likely root cause is that the organization has poor insight relative to their demand and supply. So they are essentially operating blind in the replenishment area and ordering too much of what they don’t need and too little of what they do. If they could address that single issue, a number of other issues would disappear or become less of a problem.
Make a list of all your events and then determine which seemingly unrelated events are in fact actions or reactions to another event in your list. Being able to address and manage the root cause event more effectively with a new ERP system should yield a cascade of financial value.
In the next issue we will look at ways to quantify the tangible and intangible financial values and benefits of your project as well as the myriad of costs that will need to be borne.
Oct/090
No Decision – May You Forever R.I.P. (Part 1)
Have you ever worked on a project that started off with boundless exuberance and fan fare, yet failed to deliver the anticipated results? Sometimes it’s a result of a head on crash with completely unforeseen events. More often than not however, it is usually more a matter of the project losing inertia for one reason or another. It might be due to the project running out of money or resources, but frequently it is due to the project not having the foundation of a well documented and well justified business case to fall back upon. Common symptoms that can derail a project are things such as competing corporate goals and objectives, and poorly understood or shifting priorities.
I see evidence of the aborted project all the time in my industry. Predominantly, an organization decides one day to replace their existing business management system (referred to as ERP system) and thus rushes headlong down the path of reviewing various business management software packages and providers only to run out of steam a few months later and ultimately make no decision. This results in much wasted time and money for the organization as well as the ERP system providers. How and why does this happen so often?
First of all, the initial decision to replace their system could be based on any number of factors, but it usually stems from deficiencies in their existing system as it relates to being able to perform certain functions. After some period of awareness and discontent, the decision makers give the go-ahead to someone, usually in the accounting or perhaps IT department, to start looking for a replacement ERP system. You might recognize this as the “let’s just do it” syndrome. The lucky recipient of the edict from above, armed with not much more than a short list of functional capabilities that need to be improved, sets off in search of the perfect solution. It doesn’t take long to discover an array of ERP systems (at last count, approximately 350) and multiple providers of these packages.
If the person leading the ERP software review process is lucky, they will find several offerings that appear to address their functional requirements to a greater or lesser degree. It quickly becomes apparent however that the review and selection of a new ERP system is a daunting task filled with lots of risk and uncertainty. As the review process continues, more questions than answers frequently arise, until at some point the project just stalls out due to lack of clear organizational imperatives and mounting gray areas.
As an organization dedicated to helping companies successfully select and implement ERP systems, when the project is aborted like this, we call it “Losing to No Decision”. The ironic thing is that a conscious decision to abort the project rarely occurs, rather it just flat runs out of gas because there is not enough organizational clarity and determination to grapple with the difficult tasks and overcome the speed bumps. As you can imagine, this is ultra frustrating for everyone involved as it wastes time and resources and results in no progress being made against the initial objective.
Fortunately, there is plenty that can be done to avoid this wasted effort. Stay tuned for the next issue as we lay the ground work including step-by-step instructions for ensuring that your project does not become part of the carnage.