We started analyzing which tool we should use for the future a few years ago, and we started digging into Octane very early. 

Options we considered included JIRA, which is used by a lot of small teams. There is a standard toolchain around but with the amount of data and information we need to run, JIRA was very easy to strike from the list. We dug into IBM and PTC Integrity. We looked into ALM Octane vs codeBeamer ALM from Intland. We did some comparisons but ended up with Octane.

With JIRA and the toolchain, you cannot run a business like ours, doing car development, using a lot of plugins to get the needed functionality in one tool. You have so many small companies providing those plugins. What if the company providing one of the tools or plugins you're using collapses or doesn't support a new JIRA version? So this was not an option.

PTC is also using different tools to support the full functionality of requirements, test cases, team management, the backlogs, tests and defects, and so on.

codeBeamer was on the short-list and was the biggest competitor to Octane. But from our perspective, Octane did much better in performance. Octane is not able to do as many relations between the data objects as codeBeamer, but performance was the key factor for us. When you compare Octane to codeBeamer ALM, the UX concept is very good. What's also very important is to have good capabilities for getting reports about the system out of Octane in real time. The reporting engine, the widgets, and the dashboards are a huge plus.

This is still an area where we have lots of feature requests at OpenText to enhance things even further. We would like it to be more flexible for the users. We have lots of user-defined fields and lists so users are requesting more capabilities for enhancing this area or would like the possibility of filtering their work items.

We were setting the foundation for the next eight to ten years. We had to have that in mind, as well as the increase in data, the increase in users, the increase in data objects and rules, and the complexity of development which is divided into different pieces. To cover all this in one single tool led us to Octane. Cost and license fees were also a big issue. The two solutions, codeBeamer and Octane, weren't that far apart but, here as well, Octane was first.

I've had my customers look at ServiceNow, DevOps AddOn as well as Jira, and Zephyr.

I don't want to limit our sales. However, my clients were ALM customers and they said the best choice coming from ALM was to migrate their projects to Octane instead of moving over to a new platform.

We compared Zephyr Enterprise with ALM and decided to go with ALM because we have another provider that already had integration with ALM. If we'd gone with Zephyr, it would have required some technical integrations with their APIs and some of our testing tools. From a capability perspective, the two solutions are pretty on par with one another. If an organization is evaluating capabilities versus investment, then they might prefer Zephyr.

We looked at six tools as part of our evaluation, when we were looking for an Agile ALM tool. We looked at CA Agile Central, VersionOne, JIRA, TFS, Agile Manager, and Octane.

We did have very extensive requirements and they scored very closely. JIRA was our number two, Agile Central was number three, and VersionOne was our number four. Agile Central scored more, the highest, but Micro Focus allowed us to share licensing between HPE Quality Center and Octane. That was the primary reason it was a no-brainer for us to get started with Octane. Apart from our hardware and implementation costs, there were zero costs to begin with.

Most of the other tools that we evaluated were very comparable. You could pick any of those tools on any day. But for our use cases, for our specific needs, and the costs and scoring, we zeroed in on Octane.

We already had ALM Quality Center. So, it was a natural move to Octane. It was easier for migration purposes, and the users knew some of the main functionalities. So, we did not evaluate other tools.

I don't recall the names of the products my company had evaluated against OpenText ALM Octane in the past. The reason why my company chose OpenText ALM Octane is because we were using Micro Focus in our environment.

It went through official procurement process where we went out to tender with seven different suppliers. We had responses from five of those suppliers. We had demos from five of those suppliers. We followed three more through, then we eventually selected Micro Focus ALM Octane. At which point, we started demoing Octane and ran it through 2018 whilst we were doing contract negotiations and signing contracts, which was probably the single hardest part of the entire thing. 

Four of the seven vendors that we looked at were Micro Focus, CA Agile (incumbent), VersionOne, and Jama. 

We went with ALM Octane because of its functionality and it is presented very cleanly and simply. You are never more than three clicks away from where you need to be in Octane. Another reason that we went for ALM Octane as a tool is because of our relationship with Micro Focus as a company.

ALM Octane has a cleaner version than VersionOne, which is a little busier.

When you compare ALM Octane vs JIRA, it's different than JIRA where you have the core product and then you have to buy all of the add-ons to do what you need to do. Octane tends to have everything you need.

We are doing a lot of other evaluations; for example, the possibility of using direct JIRA backends for testing. In addition, but not in the same magnitude as our evaluation of ALM Octane, we're still looking at the possibility of holding on to ALM.NET longer.

I compared Octane with Jira, which is better-priced and more user-friendly than Octane.

We already had Jira in-house, but its testing capabilities were insufficient and not scalable enough for our needs.

We did not evaluate other options before choosing Octane. At that point, we were in pretty deep with HPE. But before we chose HPE as our vendor for the bulk of our enterprise tools, we did an evaluation of different vendors, different suites of enterprise tools that we could possibly host, before we made that decision to go with ALM and AGM and UFT.

We evaluated solutions from ServiceNow, VersionOne, Jira, and multiple in-house solutions.

I have some experience with Jira and Micro Focus ALM Octane, but I am mostly reviewing them to give a recommendation for a client.

We did not really evaluate other options. We were introduced to Octane and found it to be a good idea.

We have used more of a requirement-driven tool, where it will help you to identify which requirement already exists. Then, you don't capture duplicates and it directs you to the project that is linked to that particular requirement. 

We also use Jira at a high level for projects.

We looked at a few. One we're still having look at is Xray but doesn't fit with our BDD approach. We also looked at ServiceNow. That's mainly for ticketing systems but they also showed us something about test management. It was very close to ALM, to the old way, so it was also not very useful for our process. Our support is working with ServiceNow but it doesn't fit with our project.

No, just HPE, Micro Focus. It's our standard.

Getting something new approved is a nightmare. It also makes our job easier. We tell them, "This is the standard," and we can move on. We're not deluded by looking at bunch of other options.

We only looked at Jira. We had some concerns about its reporting capabilities and its task management capabilities, as well as managing Waterfall and Agile in parallel.

When Octane came to us it was a beta program. They said, "This not prime time yet." We evaluated a couple of other tools, like JIRA, which is one of the other tools that we have in our organization right now.

But the integration between JIRA and ALM wasn't there. JIRA is not our standard, actually. But we do use JIRA because developers really like it. What we wanted to have is the integration between tools. Right now we are using AGM in our organization, which is integrated with ALM.

So that's where we thought that Octane - even though it was a beta version at that time - we would take it and do a PoC and see if it works. And we thought it's really good because there is a lot of investment being done on the tool from Micro Focus.

We like how simple it is. It's easy for people to understand. Self-taught and they can work on it. A lot of our internal customers are using the tool even without formal training. They are self-teaching by going through all the resources. So we evaluated it and finally decided that it would be good to use Octane. We made that our strategy.

Comparing Octane and JIRA, I don't really know what the advantages are from JIRA. For Octane, it is primarily the integration with all the other tools that we have right now. And, as I was saying, it's simple to use.

And the changes - the way they are building the tool - we are part of the team which is building the tool. So we can always provide our input and make changes. We don't have that with JIRA. JIRA is there, but it's not used as a lifecycle management tool at all. We wanted to have a lifecycle management tool. So that's the reason.

We evaluated several solutions. One is called the Tuleap, which is open-source. Globally, it's a software development forge. The problem with that solution is that it's lacking test management, primarily. Then we tested another open-source solution made by a company named Henix, called Squash, which is a good solution, especially for open-source. It's just missing an integrated Agile management system. We also looked at JIRA but it does not have a test solution system and I don't like Atlassian politics very much.

We are not using this solution for operations. We are using the Octane tool for purely project solution delivery. For operations, we use Remedy tools, not Octane.

Jira has its own limitations, so we thought Octane would be better.

We looked at JIRA with Zephyr. We built our own internal one in ServiceNow. We also looked at something called TestRail. We went with Octane, just because of the reputation of HPE. It looked like everything they were doing was going the right way. We did an evaluation between Zephyr and Octane, and we really liked the interface in Octane. We just weren't really happy with JIRA, we were already using our own storyboard that we built in ServiceNow, so it really didn't make sense, and Octane just seemed like a much better choice.

We work with Microsoft TFS. We also use JIRA, but I don't consider JIRA a competing component, rather we integrate it. One of the pros of TFS is definitely its integration and supportability if you are a Microsoft development environment, using .NET and the like. There's a lot of seamless integration there. Also, from a pricing perspective, usually Microsoft can provide you with very cheap packaging options. Those are the two main pros for Microsoft TFS.