How to Understand SAP’s Exaggeration of HANA’s Strengths in Analytics

What This Article Covers

  • What is the Real Story of HANA’s Analytics Performance?
  • Long Versus Short SQL Queries
  • What Happened to SAP’s Row Store Performance?

Introduction

For some time we have been saying that HANA’s only beneficial area of performance is for analytics, which is called a read operation in database speak.

However, there is a level below this in detail. HANA’s primary beneficial area is for short SQL queries. A good example of a short SQL query would be a query for BW.

Long Versus Short SQL Queries

HANA’s performance degrades for longer queries.

A good example of a longer query is within ECC or S/4HANA. This is where the data is less prepared.

However, in SAP’s marketing material, they propose that HANA is excellent for reporting on ERP systems. There is no evidence of this up to this point. In fact, the evidence points in the opposite direction quite strongly as we cover in the article Why HANA is a Mismatch for S/4HANA and ERP.

Ironically, we have had many people tell us that once reports can be run from the ERP system, there will be no reason to have a centralized BI system. But the performance of HANA does not support this vision.

What Happened to SAP’s Row Store Performance?

This following quotation can be found in Oracle’s “Analysis of HANA HA” document.

“The SAP HANA database consists of two database engines:

The column-based store, storing relational data in columns, optimized for holding data mart tables with large amounts of data, which are aggregated and used in analytical operations.

The row-based store, storing relational data in rows.

This row store is optimized for write operations and  has a lower compression rate, and its query performance is much lower compared to the column-based store”

Apparently, not all row-based stores are created equal, as HANA’s performance for ECC is worse for transactions than ECC on Oracle or IBM’s pre-column store databasesThis explained the performance differences between Oracle DB, DB2, SQL server, MaxDB and Sybase ASE even though all are row based by default. 

One thing to remember is that HANA is still a relatively new database. When discussing this with a very experience database resource, the pointed out the following observation.

“That’s is no way a brand new row based DB can beat all these databases above which are optimised over so many years especially Oracle DB.”

Conclusion

HANA’s performance benefit is more narrow than anyone would have imagined from the SAP marketing material. The statement that HANA is better for analytics is not entirely accurate. HANA is better for one type of SQL processing. It is slower for every other type of database processing.

At this point, HANA has proven that it is better at supporting an analytics system, such as SAP BW. But not that it is better than competing offerings at doing this.

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

How Enlarged are the HANA Implementation Numbers?

What This Article Covers

  • The HANA Value
  • Project Examples with HANA
  • The Asian Airlines that Lost on HANA
  • Companies that Bought HANA, With No Intention of Using It

Introduction

SAP presents HANA as a successful product. However, details have been coming to Brightwork that calls into question how successful HANA is.

In this article, we will review the HANA numbers and how they have been inflated.

The HANA Value

We have covered this topic from many dimensions at Brightwork, but after hundreds of hours analyzing HANA, the value to HANA is not particularly evident. One of the central premises of HANA is that speed or performance is a major limitation of analytics projects. However, after seeing many projects ourselves, this is not at all evident.

What appears to have happened is that Hasso Plattner has projected what they thought was a major issue, that wasn’t.

Project Examples with HANA

We have it from a reliable source that SAP won a head to head project that had no HANA in it. The reason for this was that the SAP management had substantial compensation incentives for HANA the put it into the already confirmed and priced BOM. At zero discount and discounted everything else so HANA, a product not used or needed, was 30% of the total cost.

The sales person did not achieve his targets when HANA was not included. Due to this, the salesperson told the customer price stays the same, and they threw in a new product at no cost.

SAP management made their HANA number, but the customer now pays a support fee (which is based on the list price, not the discounted price) for a product that they do not use. SAP counts this as a customer, even through HANA was not implemented. The following is a quote from a person with intimate knowledge of the HANA deals made by SAP.

“Nearly all orders we filled were BS and customer didn’t need. Even on BW – the implementations were so complex and so much fine tuning as soon as the experts left, or the scope changed – problem.”

The Asian Airlines that Lost on HANA

“An Asian airline was implementing a new sap ERP a few years back and did not choose HANA. After buying SAP had another go and brought in their top people. It still didn’t make business sense and airline couldn’t justify the price. There was simply no ROI. Finally SAP played the “no future new functionality” card and said the module the Asian airline wanted (flight planning) was only available on HANA. At that point the airline felt they were essentially forced to buy.”

This quote paints another picture of SAP pushing HANA for SAP rather for any reason that the customer needs.

This story gets even stranger because there is no product in SAP’s product list that has the word “flight” on the list. It is a secret product or perhaps vaporware?

Secondly, a planning module like that will be processor intensive, but it is not going to be read access intensive. So this is another example of SAP overgeneralizing the benefits of HANA. I have never run into flight planning before, but there is going to be best of breed solutions that are developed by people with years of flight planning experience that SAP won’t be able to compete with. Sabre has a solution. So SAP is going to compete with Sabre?

Furthermore, there are a series of free flight planning websites that are easily available online. Upon investigation, the number of flights that are planned on HANA globally is very close to zero.

Companies that Bought HANA, With No Intention of Using It

“The customer said they had no plans to use HANA, so I asked why, then, had they bought it. They explained that their procurement had negotiated all the SAP modules they wanted and the price. The final order docs came back from SAP with HANA added to the product list as the last line, the entire order price allocated to HANA, and the word “Included” next to all the products that they were actually buying – as if the ERP modules were components of some sort of HANA “suite”.

So SAP found a way to book millions in revenue to Hana even though their customer had no use for it and didn’t want it. This customer didn’t object as they were told by SAP that they were getting a free product that they might use/need one day and would mature over time. So they let it go.”

And why was this done? So that SAP could report to Wall Street that HANA is growing, much more than it is.

Conclusion

SAP has been crowing about HANA’s growth, but much of this growth is a castle made of sand.

HANA has far fewer customers that use it because the numbers were manufactured to meet sales and management incentives. There are many implementations of HANA that have not gotten past the demo stage. These issues explain why HANA has declined in popularity for eight months. The value and use of HANA is simply nothing like SAP projects to customers, to consulting companies and the IT media.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

[VfrFlight – free VFR flight planner](https://vfrflight.org/en/tutorials.html)

https://www.iflightplanner.com/

https://www.sabreairlinesolutions.com/home/software_solutions/product/flight_planning/

When Articles Exaggerate SAP HANA Benefits

Executive Summary

  • SAP HANA has an enormous number of exaggerated articles.
  • We cover the accuracy of the proposals contained in these articles.

Introduction to SAP HANA Exaggerations

Recently I spent time analyzing quite a few articles on SAP HANA benefits. What I have noticed that SAP HANA articles tend to have a high “aspirational content” ratio. I think any potential software buyer needs to be concerned with this tendency of SAP HANA articles to take on a playful and exaggerated nature. Once you research to understand what supports these statements, it often turns out to be often be nothing at all.

A large number of these articles seem to propose benefits that are supposed to be uncritically accepted by the reader. In this article, we will cover the exaggeration undertaken by SAP.

Aspiration for SAP HANA Benefits!

For example, one of the common issues that I find is that while the benefits are listed, the costs are not. How costs are addressed is through asserting that SAP HANA reduces TCO. How much seems to depend on the entity proposing. According to SAP, the TCO reduction is “dramatic.” According to Capgemini, the TCO reduction is “huge.”

What are these things based upon?

The only study I could find on this was a SAP commissioned study from Forrester Research back in 2014. In How Accurate Was Forrester’s TCO Study for SAP HANA? I critiqued the Forrester study. Long story short, it is so filled with holes that I believe the study lacks any validity whatsoever. SAP got what they wanted out of Forrester, but no one should consider this seriously.

Interestingly, what is left out of all references to the study is that the cost savings are entirely projected.

A lot of other articles seem to be confused as to distinctions cost and benefits analysis as they commingled ROI with TCO. Sufficient to say, if you cannot keep ROI separate from TCO, then it is difficult to take that author and that article seriously.

How Many Extra Costs to Properly Maintain HANA?

SAP HANA dramatically changes a company’s approach and skills it needs for SAP and has all types of associated extra costs. SAP emphasizes the dramatic changes, but it positions them entirely as cost and effort reduction.

That is incorrect and misleading.

It makes no sense to continually transition so quickly from the costs to the benefits side of the equation. Moreover, now that we are on the subject, the benefits that are attributed to SAP HANA, at least by many authors, are another big problem with the information published on SAP HANA.

Focusing on the Declared SAP HANA Benefits

To illuminate this point, I will provide a list of SAP HANA benefits. This is a direct quotation from an article produced by a senior member of one of the major SAP consulting companies.

After reviewing this list, let us perform a little test to see how many of the items relate to SAP HANA benefits.

“Some focus on the details of the technology. But why should business leaders care? Those who have recognized that in-memory computing allows them to do things differently have realized these benefits:

  1. Ease of integrating data from multiple sources
  2. Increased speed to deployment and speed to value
  3. Flexibility to meet changing business needs
  4. Enhanced mobile analytics
  5. The power to turn data into action.”

Now let us go through each item to see if these are true:

Total Integration with S/4HANA?

SuccessFactors, Fieldglass, Concur, Ariba, are not all integrated to S/4HANA. SAP states that they all sit on the same database! That is untrue. However, again, with how SAP treats time when it makes statements, SAP may be saying this will be true 5-10 years from now. If the projections can be unlimited across the timeline, then anything can be said to be true.

Secondly, outside of S/4HANA Finance, S/4HANA does not exist as it is not released. (I have a future article on this as some consulting companies are proposing to clients that version 1511 is a completed product) An ancient Chinese proverb says that “You cannot be integrated into an application which does not exist — grasshopper.”

*One commenter stated that by using a slide from S/4HANA I appeared to confuse S/4HANA with HANA. This slide, while about S/4HANA is also about HANA itself as it proposes that all these applications are integrated on SAP HANA. That is incorrect. It is the exact opposite of what this slide presents in real life.

Integration as One of the SAP HANA Benefits?

Ease of integrating data from multiple sources.– SAP

I do not recall in-memory computing being referenced before as improving integration. Readers can check the Wikipedia entry on In-Memory Computing and In-Memory Database, and the word “integration” does not appear a single time. Isn’t that a bit concerning?

This brings up a logical and factual problem that undermines the credibility of so many SAP HANA benefits articles. The items tend to morph the benefits from area to another field. Specifically, this is a major weakness in the articles by Hasso Plattner, who shows a pattern of writing disjointed articles that commingle multiple topics — often in a single sentence. The strategy seems to be to combine so many proposals that they overwhelm the reader into agreeing. Alternatively, as my friend likes to say “it is all about the Big Data now.

Let the competition between simplistic platitudes begin.

Back to the specific statements. SAP HANA does not provide any extra ease of integrating data from multiple sources as it is not an ETL (extraction, transformation, and load) tool. SAP’s ETL tool is called SAP PI/PO. The background idea here may be that everything will run on one giant SAP HANA instance so data can be moved between the applications. However, we are far away from that state. Moreover, also, why would every application want to sit on the same SAP HANA database? SAP HANA is only optimized for reporting processing. This gets into the question of HANA performance, which does not, as SAP has stated work equally well for either analytics or transaction processing. 

Before we make projections reducing ETL, let us acknowledge what is currently proven and what is conjecture. SAP HANA proponents continuously transmute time.

Conveniently Switching Between Doing Now and Doing in the Future

If you want to climb Mount Everest than that is in the future. You cannot logically describe your experiences of climbing a mountain you have never climbed.

  • HANA is the database, and the more quickly we can move away from referring to it as a platform, the more we can make progress in understanding what HANA does versus what it does not do.
  • We have to decide where we are going to “live mentally” when understanding SAP HANA. If we want to live in the land of marketing hyperbole, then we can call SAP HANA a platform and transmute time and ascribe benefits to SAP HANA which have never been proven. However, unless one works in SAP marketing, it makes little sense to accept any of their proposals without independent verification that they are true.

Is “Faster to Deploy” One of the SAP HANA Benefits?

In most cases, HANA will not provide an…

“increased speed to deployment and to value.” – SAP

First, you cannot be faster to deploy than something that is already installed. HANA is replacing databases that are already deployed. I would very much like to see HANA implemented quicker than an already deployed database.

Do you see a pattern here?

We seem to get back into the topic of time transmutation repeatedly. Luckily the Dr. Strange movie is coming out soon, so I will be able to get on the same page with all the time alterations that are so familiar with HANA proponents.

However, that is just a beginning point, even if we start from two new systems being compared, HANA will take longer to implement because it is more sophisticated and less tested than previous SAP products. Aside from the speed of implementation question, it also means higher risk. Anyone who thinks that new products implement faster than older products with many implementations behind them does not work in software and does not know SAP.

Now, there may be a higher payoff although that is not proven in any of the articles on HANA. However, the risk and project duration should account for the relative newness of HANA.

A Good Idea to Migrate BW to HANA?

The one case where this may not be the case is with a BI/BW implementation. When BW is implemented on top of HANA, it means time saved through less time spent configuring the Data Workbench. However, that is only for a fresh installation. For companies that already configured the data structures, it will mean there is now less of a need for those structures. Moreover, of course, HANA is as pure analytics database design, so it will always work best for analytics applications like BW. However, no other SAP application should be expected to receive this implementation benefit.

So this quotation should be changed to

“May be faster to deploy under some limited circumstances.” 

Flexibility to Meet Changing Business Needs one of the SAP HANA Benefits?

“Provide flexibility to meet changing business needs.” – SAP

HANA will not provide flexibility to meet changing business needs unless that changing business need is processing something faster….and something processed faster for analytics. Moreover, secondly, SAP has provided no evidence that HANA performs analytics processing faster than alternatives — as is covered the article What is the Actual Performance of HANA.

It sure seems like I have to keep pointing out this fact to authors on HANA. HANA is a database; it is not application functionality.

  • Application functionality is where addressing changing business needs are typically met.
  • The database layer is where data from the application is stored.

This issue has arisen from SAP itself when it tells clients that things like HANA will replace APO, which again is like saying Oracle 12C will replace APO or replace CRM. It is both incorrect and confusing to say that a database returns an application.

So let us establish and important feature of the software.

Databases do not replace applications. What SAP meant was that IBP, which is APO’s potential replacement would replace APO, and IBP runs on HANA. However, that is a much different statement.

HANA for Mobility one of the SAP HANA Benefits?

“Enhanced mobile analytics” – SAP

You seriously don’t need HANA for mobile analytics; check what the emphasis point are in mobility from any of the other analytics vendors. They do not emphasize the backend.

It is hard to see why this would be claimed as a benefit for mobile computing. This is because the bottleneck on mobile computing has far more to do with the bandwidth than the database. Also, SAP has in effect no mobility business, and won’t for the foreseeable future. SAP fought that battle and could not compete with low-cost and high-quality iOS development. So is SAP proposing that its database will speed mobility applications that are not SAP?

The uptake on Fiori will have something to with this as Fiori, although not admitted to by SAP, is primarily a mobile application. However, Fiori’s future is unknown at this point. (not good, not bad, just unknown) However, there is no evidence to support the contentions by SAP and their partners that Fiori is the future.

Right now, almost no one uses Fiori. See my articles on Fiori for why this is the case.

Convert Data Into Action as one of the SAP HANA Benefits?

“HANA allows companies to convert data into action.” – SAP

This is true, but it seems like someone’s catchphrase or something to be put on a bumper sticker. So it is not false, it is irrelevant as a differentiator.

Any application converts data into action (or technically the potential for action).

If one thinks about it, data has been translated into action by devices since before computers were invented, as the counting boards (the earliest known counting device) used by the Babylonians also could convert data into action.

One Example of A Correct Statement? 

The one example from the list of something that sort of can be considered to apply to HANA can also apply to counting boards…and that cannot be a good thing.

Conclusion

These types of articles/promotional material on HANA are all too familiar. The information in them is completely unreliable. They are designed to get prospects bubbly and to reach out to them. This misinform the reader and give the reader nothing in return for their attention. They are published by Accenture/IBM/Capgemini/Infosys…(fill in the blank) all of whom have shown a willingness to make any statement that they think will increase their revenues. None of them have any independence from SAP.

Believing them increases the risk of software implementation.

What is possibly most interesting is that many of the supposed improvements that are listed in these types of articles are not improvements that can be traced back to HANA.

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk

When Articles Exaggerate SAP S/4HANA Benefits

Executive Summary

  • Most articles on S/4HANA exaggerate the benefits customers can expect to receive because of financial biases.
  • We review common exaggerated claims about S/4HANA to determine which are true.

Introduction

Recently I spent some time analyzing some articles on SAP S/4HANA. What I have noticed that SAP S/4HANA articles tend to have a high “aspirational content” ratio, and a significant number of them seem to propose benefits that are supposed to be uncritically accepted by the reader.

The Aspiration Quotient to SAP S/4HANA

In the article …….. I covered the issues related to the accuracy of some of the SAP S/4HANA marketing documentation.

For example, one of the common problems that I find is that while the benefits are listed, the costs are not. However, with something like HANA, which dramatically changes a company’s approach to SAP and has all types of associated extra costs, it makes little sense to only look at the benefits side of the equation. However, the benefits that are attributed to HANA, at least by many authors, are another problem.

Focusing on Declared SAP S/4HANA Benefits

To illuminate this point, I will provide a list of SAP S/4HANA benefits. This is a direct quotation from an article produced by a senior member of one of the major SAP consulting companies.

After reviewing this list, let us perform a little test to see how many of the items relate to SAP S/4HANA.

“Some focus on the details of the technology. But why should business leaders care? Those who have recognized that in-memory computing allows them to do things differently have realized these benefits:

  1. Ease of integrating data from multiple sources

  2. Increased speed to deployment and speed to value

  3. Flexibility to meet changing business needs

  4. Enhanced mobile analytics

  5. The power to turn data into action”

Now let us go through each item:

Integration Benefit of SAP S/4HANA?

I don’t recall in-memory computing being referenced before as improving integration. Readers can check the Wikipedia entry on In-Memory Computing and In-Memory Database, and the word integration does not appear a single time. So many HANA articles morph the benefits from area to another area. The reason that HANA does not provide any extra ease of integrating data from multiple sources as that it is not an ETL (extraction, transformation, and load) tool. SAP’s ETL tool is called SAP PI. HANA is the database.

Faster to Deploy?

In most cases, SAP HANA will not provide an “increased speed to deployment and value.” Quite the contrary, it takes longer to implement because it is more complex and less tested than previous SAP products. Aside from the speed of implementation question, it also means higher risk. There may be a higher payoff, but the risk and project duration should account for the relative newness of SAP HANA. The one case where this may not be the case is with a BI/BW implementation. When BW is implemented on top of SAP HANA, it means time saved through less time spent configuring the Data Workbench. However, most SAP applications would not receive this implementation benefit. So this quotation should be changed to “Maybe faster to deploy under certain circumstances.” 

Flexibility to Meet Changing Business Needs?

SAP HANA will not provide flexibility to meet changing business needs, unless that changing business need is processing something faster. SAP HANA is a database, its not application functionality. Application functionality is where addressing changing business needs is typically met. This issue has arisen from SAP itself when it tells clients that things like SAP HANA will replace APO, which again is like saying Oracle 11i will replace APO or replace CRM. It is both incorrect and confusing to say that a database replaces an application.

SAP HANA for Mobility?

You seriously don’t need SAP HANA for mobile analytics; check what the emphasis point are in mobility from any of the other analytics vendors. It’s hard to see why this would be claimed as a benefit for mobile computing. This is because the bottleneck on mobile computing has far more to do with the bandwidth than the database.  For instance, Tableau has snapshots for when you are not connected to the Internet.

Convert Data Into Action?

This is true, but it seems like someone’s catchphrase or something to be put on a bumper sticker. So it is not false, it is simply irrelevant as a differentiator. Any application converts data into action (or technically the potential for action), and if we think about it, data has been translated into action by devices since before computers were invented,  as the counting boards (the earliest known counting device) used by the Babylonians also had the ability to convert data into action.

One Example?

The one example from the list of something that sort of can be considered to apply to HANA can also apply to counting boards…and that can’t be a good thing.

Conclusion

These types of articles are all too common, and the information in them is unreliable and gives the reader nothing in return for their attention. What is possibly most interesting is that many of the supposed improvements that are listed in these types of articles are not improvements that can be traced back to HANA.

If a prospect reaches out to the member of this consulting company, does the member continue to propose that HANA with smooth integration and deploy faster, etc.? That would be a problem.

Curious about the reality of S/4HANA implementations? See our The S/4HANA Implementation Study, for real story and details on actual S/4HANA implementations.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk