Contents tagged with CFO Perspectives

  • What not upgrading enterprise software could cost you

    Tags: CFO Perspectives

    Given the rapid rate of innovation in the software field, the costs of obsolete systems are usually much higher than most people realize. The only way to know for sure is to estimate that cost.

    Some things in life are inevitable: death, taxes, and obsolete software. For extreme examples of obsolete software see this article by Kenneth Corbin: U.S. CIO aims to cut legacy spending, proposes IT modernization. While technologies fall out of favor, companies change, their markets grow, they are familiar with their software and may hang onto it long past its prime. Though there are many reasons not to change enterprise software, possibly the biggest is inertia. If it isn’t broken, why fix it?

    The cost of not replacing old software must be estimated to answer the above question, especially for systems that have been in place for more than ten years. This cost is often much higher than expected and is incurred every year. Start the process by estimating the common costs of obsolete software listed below:


  • Why value trumps price when buying enterprise software

    Tags: CFO Perspectives

    When it comes to enterprise software, value is far more important than price.

    The corporate procurement process traditionally focuses on achieving the best purchase price. While this may be the right approach when buying commodity items, when it comes to buying enterprise software it is completely wrong. A far better approach is to focus on the value provided by the software rather than its price.

    To paraphrase Benjamin Franklin “The bitterness of poor functional fit remains long after the sweetness of a low price is forgotten.” If you pay too much for software, all you lose is a little money. If you buy on price, you risk losing everything, because software that does not adequately meet requirements will eventually be replaced.


  • Calculating the total cost of ownership for enterprise software

    Tags: White Papers, CFO Perspectives

    The TCO is a vital part of the ROI calculation for enterprise software, yet too often it is ignored or underestimated. See what should be in the TCO estimate, and use that to make better software selection decisions based on the ROI.

    The Total Cost of Ownership (TCO) for enterprise software is the sum of all direct and indirect costs incurred by that software, and is a critical part of the ROI calculation. However, it is often ignored or woefully underestimated. In this article, we look at the lifetime costs incurred by the three main types of enterprise software, namely:


  • How to select enterprise software to maximize value

    Tags: CFO Perspectives

    Ultimately, enterprise software is bought to deliver value, and that value flows from how well the software meets requirements. To maximize returns on software investments you need to complete a value analysis before making the purchase.

    Buying enterprise software is not like buying a car or a house where there is pride of ownership. Nobody buys software for the sheer joy of owning it. Rather it is bought for the value of the benefits that flow from using it.

    Market leading software is often seen as delivering this value, but without a detailed value analysis, there is no way to know this before making the purchase. Too often, software is bought only to find that it does not deliver the expected value because it is not a good match for the particular requirements. However, once the purchase has been made it is too late to do anything about it. Invariably organizations buying software because it is the market leader tend to be near the bottom of the Software Selection Maturity Scale.


  • How to select enterprise software to maximize ROI & minimize buyer's remorse

    Tags: CFO Perspectives

    Selecting best-fit enterprise software is a difficult task, and you can’t please all the people all the time. This article outlines a data driven and auditable process to pick the software that maximizes ROI and minimizes buyer’s remorse.

    Over the last few months, articles in this column have focused on detailed aspects of evaluating and selecting enterprise software. This article draws many of those ideas together in a high-level overview of the software evaluation and selection process and includes links to the more detailed articles.

    The primary goal of an evaluation and selection project is to identify the software that best meets the needs of the organization. By definition, this has the greatest ROI. Also, the evaluation should provide the information necessary to drive down risks in the software implementation phase of the project.

    The opportunity for new enterprise software doesn’t happen too often, and yet it presents a real chance for an organization to make significant improvements. With so much at stake, how do you find the cloud or off-the-shelf software most closely aligned with your particular needs? This article answers that question.


  • Why spreadsheets don't cut it for enterprise software evaluations

    Tags: CFO Perspectives

    Is your evaluation spreadsheet tying you up in knots? See why spreadsheets don’t deliver when evaluating enterprise software.

    Enterprise software evaluations often start out as spreadsheets but soon run into problems. Why does this happen? For the same reason that accounting systems don’t run on spreadsheets: spreadsheets are too manual. They don’t scale up to handle the many hundreds or thousands of requirements found in a typical enterprise software evaluation.

    The scaling problem is familiar to people in growing companies. Systems that originally worked well begin to fail as they are scaled up. Likewise, spreadsheets that worked well when starting an evaluation struggle as the number of requirements grows.

    Evaluating enterprise software is a lot of work. Managing this work in a spreadsheet seems the obvious choice, but that is deceptive. What many people don’t realize is that at the enterprise level, they will end up building a complete evaluation system in a spreadsheet, which is always far more work than expected. In this article, we look at the limitations of using spreadsheets to evaluate enterprise software and conclude with suggestions.


  • Why you should always estimate ROI before buying enterprise software

    Tags: White Papers, CFO Perspectives

    Don’t gamble when prioritizing enterprise software projects. See why you should prioritize by ROI, and how to do it using the risk-adjusted value method.

    Erik Nelson, an accomplished IT professional, once said in the course of a conversation with me that when it comes to prioritizing IT projects there are really only two things to consider: 1) Should a project be done at all? and 2) In what order will selected projects be done? Nothing else matters. Erik offered very sage advice because all complicated prioritizing schemes eventually reduce to this.

    When managing a portfolio of enterprise software projects, you can use the ROI to eliminate those projects with a poor return. They are the ones that should not be done. For the projects that should be done, prioritize them by ROI for maximum value to the organization.


  • Don’t skip vendor due diligence when buying enterprise software

    Tags: CFO Perspectives

    It’s all too easy to skip vendor due diligence when buying enterprise software. This is an important part of the evaluation and selection process that can help avoid starting a business relationship with a vendor that just will not work in the long term.

    When making an enterprise software purchase, even a relatively small one, you want a long-term relationship with a software vendor. You really want them to be a reliable and productive part of your team. When considering a long-term relationship, what signs might suggest there are storm clouds on the horizon?

    It is too easy for organizations to be caught up in the excitement of a new purchase and not perform due diligence on the vendor. This can be a big mistake, especially when buying business critical software from smaller enterprise vendors. Due diligence is investigating vendors before the purchase so comments like this are not made: “If I had known that about this vendor, we would not have bought their product!”


  • 8 reasons why committees fail when selecting enterprise software

    Tags: CFO Perspectives

    While organizations use committees to select business-critical software, real world experience shows this doesn’t work as expected. Here's a look at why committees struggle with software decisions and what path leads to more successful enterprise software projects.

    Enterprise software is always purchased to solve business problems. For example, vendors no longer support the current software, new functionality is wanted, new compliance regulations must be met and so on. In all cases, business needs drive the decision to move forward with acquiring new software. Unfortunately, as the horror stories that so regularly appear in the technical press attest, buying enterprise software is inherently risky.

    Finding the best-fit software for the organization’s particular needs and budget will minimize that risk and deliver the greatest ROI. The question that arises is this: What process should be used to identify that best-fit software?

    Organizations often make major decisions by committee. However, when it comes to selecting enterprise software, this decision-making process is flawed. This article examines eight areas where committee decision making fails and suggests a better way to select enterprise software.

    1) Underestimating complexity

    Most organizations underestimate the complexity of enterprise software products that literally have thousands of features. The organization must examine how well those features meet their requirements because most of those features will affect their business. If there is too great a mismatch between requirements and features, the software will fail. Typically, committees lack the time, resources, tools and methodologies to deal with this level of complexity. They take shortcuts that usually lead to problems or disasters.

    2) Inadequate experience

    A committee based software selection decision assumes members adequately understand organizational needs and have a good enough understanding of that particular software market, but this is seldom if ever true. Organizations also need “out of the box thinking”, i.e. perspectives from outside the organization that can challenge assumptions people don’t realize they have. As many organizations find out from bitter experience, assuming committee members have the required background is a flawed assumption.

    3) Underestimating time required

    The total cost of ownership for enterprise software is in the multi-millions, and a thorough software evaluation and selection process requires hundreds or thousands of hours of work. Even though much of the work will be delegated, committees are never prepared for this. Shortcuts are inevitably taken leading to the wrong software being selected.

    4) Inadequate requirements discovery

    An enterprise software selection project is a journey of discovery where an organization uncovers their real requirements. Committee decisions attempt to substitute experience for this requirements discovery process. This fails because there are too many requirements when selecting enterprise software and committees neglect going into a great enough level of requirements detail. Committees don't realize that front loading requirements development significantly reduces overall project risks.

    5) Inadequate implementation estimates

    To be cost competitive software implementation vendors tend to understate costs and make up the difference with change orders. Software selected by a committee lacks the analysis that is so essential for an accurate implementation estimate. However, when software is selected based on a thorough evaluation process, there is a detailed analysis of the winning product, which is used for accurate estimations of the implementation work required.

    6) Implementation delays & cost increases

    When a software selection process starts, there are always unknown requirements. A detailed analysis that includes the reverse engineering of features will uncover these requirements. However, if that detailed analysis is not done, these requirements are discovered during implementation where satisfying them introduces delays and increases costs. Some people call this scope creep, but it isn’t. Those requirements should have been uncovered in the analysis phase of the project, and then built into the plan.

    7) Voting process logically flawed

    Using a committee to select software only masks the real problem, which is a faulty decision-making process. If you start with a software product selected by vote or consensus and work back towards the requirements, you arrive at a “black box”, namely the voting decision made by committee members. There is no logical way to trace the decision back to the requirements, which means there is no way to verify the correctness of that voting decision.

    Compare this to a deterministic decision driven by weighted requirements and where the features of software products are scored against those requirements. There is a logical path between the software selected and the organization's requirements (the traceability matrix) and the selection decision can be verified from the requirements.

    8) General committee decision problems

    Examples of general decision-making problems that software selection committees can suffer from are:

    • Committee Leadership that is either too strong or too weak. Strong leadership can lead to authority deference. Weak leadership can result in one person dominating the process.
    • Groupthink. Here a desire for group conformity leads to flawed decision making.
    • Group decision fatigue. The selection project seems to drag on forever, and the committee members just want to make the decision and move on.

    The solution

    Some organizations rely on committees to select software but, as shown above, committees lack the process needed to minimize software selection risks and maximize ROI. They end up paying the price of poor software selection decisions.

    Don't waste the opportunity you have when selecting new enterprise software. Use a data-driven and deterministic process to remove subjectivity from the selection decision so you identify the software that best meets your particular needs. Use the information generated by the evaluation to reduce software implementation risks. For a real world example, see the Wayferry process, which is a refinement of the Kepner-Tregoe process adapted for software selection.


    Article by Chad Stewart of SmartThoughts: Do Groups Make Better Software Decisions?

    This article was originally published on on June 23, 2015


  • What a bad enterprise software purchase will cost you

    Tags: CFO Perspectives

    If you fail to do the work upfront to select the best-fit enterprise software, you will pay the price.

    A successful enterprise software deployment can be defined as one that meets or exceeds planned ROI. A previous article examined the ROI benefits that accrue from selecting best-fit enterprise software. This article considers the flip side of the coin, namely the costs incurred when an organization purchases software that is not best-fit for their particular needs, i.e. they purchase the wrong software. Under these circumstances, one of the following things happens: