I'm a consultant who helps users determine which product they want. I am not a user. I help users evaluate solutions for the implementation of a configuration management tool.
Sr Consultant Project Manager with 10,001+ employees
Consultant
2022-01-04T19:36:00Z
Jan 4, 2022
I would advise two things. First, you must have a technical group of people who understand what you're doing now, where your programs are, how you change them, how you test them, how you promote them. You need to be able to clearly communicate all of that so that the ISPW team can create the steps in ISPW to do the same. Second, I would encourage any company to look at the whole process early on and develop realistic timelines for the whole project. Even the night you go live is a long process. This is not a 45-minute process and you're up and running. It takes time to build all the metadata that ISPW will use for tracking. You also need to think ahead about training. The training is a three-day class and you need all of your developers to sit through these classes. That's a logistics nightmare if you have five different sites and 200 people in different countries. You need to think about how you are going to train people, what you are going to show them, and about when you are going to do it. Are you going to do it with a test system or something else? If you don't look at all of that early on, you can be racing towards the installation deadline and realize, "Oh, I have to get 150 people in a room and get them trained. How am I going to do that?" Look at the whole process, start to finish. Plan for the "Go-live" date, and how you are going to communicate where you are in the process to everyone that needs to know. Your team needs to have a really good understanding of all of those steps and then start to execute. We stumbled a little bit with our first installation but the last 2 were much more organized based on understanding how all of the key events had to happen and how to communicate to the development teams. ISPW is an excellent product. It does everything the developers need it to do. We were able to build it and customize it, very simply, as we became more familiar with how the system works during installation. It doesn't need a lot of care and feeding once it's up and running. Our development teams think it is a great product as well. Installation-wise, I think more detail on the installation decisions you make up front would be very beneficial. But as a product, it's a solid nine out of 10.
Mainframe Architect at a financial services firm with 5,001-10,000 employees
Real User
2018-12-18T07:20:00Z
Dec 18, 2018
Take a longer implementation path than we did. Don't rush it. We were forced to rush it and we would incur a large cost from Serena. My advice is to plan longer and take more time to implement, which we had planned on doing. We were going to do a phased implementation. We just didn't have that luxury. To anyone who is considering moving from an alternative solution to this one, I would say, "Don't hesitate." I've told everyone I've talked to that this is a much better product. They'll be much happier with it. There was a lot of resistance early on but, the more people have used it, the more positive they have become. I think they have really started to like the product. We have about 50 users and all of them are in application development. For deployment and maintenance, it was just me and one of my staff. We maintain the skeletons and CLISTs and troubleshoot if we have a promote/deploy failure. They do happen but probably less frequently than with ChangeMan. It's used every day. It's constantly being used by the application developers. We don't have any explicit plans to increase its use, other than as we add developers. We do plan to make use of Topaz. We've been struggling with coming up with a training date but once that occurs, we hope that people that would use Topaz. We don't have it integrated with anything. There's been some talk of looking into that but I can't say which direction it will go. I would rate this solution a nine out of ten. The two things I mentioned earlier, the ways it could be improved, would make it a ten. If we could get a little better documentation and a little better error reporting from the promote/deploy processes, that would sure make my life easier.
A modern, end-to-end Agile source code management, release automation and deployment automation tool that enables mainframe application developers at all skill levels to fulfill business requirements, optimize code quality, and improve developer productivity through mainframe DevOps. With ISPW, developers can:
Easily perform concurrent development to support Agile Development practices
Leverage Jenkins plugins to manage code throughout the lifecycle
Use REST APIs to automatically connect...
I'm a consultant who helps users determine which product they want. I am not a user. I help users evaluate solutions for the implementation of a configuration management tool.
I would advise two things. First, you must have a technical group of people who understand what you're doing now, where your programs are, how you change them, how you test them, how you promote them. You need to be able to clearly communicate all of that so that the ISPW team can create the steps in ISPW to do the same. Second, I would encourage any company to look at the whole process early on and develop realistic timelines for the whole project. Even the night you go live is a long process. This is not a 45-minute process and you're up and running. It takes time to build all the metadata that ISPW will use for tracking. You also need to think ahead about training. The training is a three-day class and you need all of your developers to sit through these classes. That's a logistics nightmare if you have five different sites and 200 people in different countries. You need to think about how you are going to train people, what you are going to show them, and about when you are going to do it. Are you going to do it with a test system or something else? If you don't look at all of that early on, you can be racing towards the installation deadline and realize, "Oh, I have to get 150 people in a room and get them trained. How am I going to do that?" Look at the whole process, start to finish. Plan for the "Go-live" date, and how you are going to communicate where you are in the process to everyone that needs to know. Your team needs to have a really good understanding of all of those steps and then start to execute. We stumbled a little bit with our first installation but the last 2 were much more organized based on understanding how all of the key events had to happen and how to communicate to the development teams. ISPW is an excellent product. It does everything the developers need it to do. We were able to build it and customize it, very simply, as we became more familiar with how the system works during installation. It doesn't need a lot of care and feeding once it's up and running. Our development teams think it is a great product as well. Installation-wise, I think more detail on the installation decisions you make up front would be very beneficial. But as a product, it's a solid nine out of 10.
Take a longer implementation path than we did. Don't rush it. We were forced to rush it and we would incur a large cost from Serena. My advice is to plan longer and take more time to implement, which we had planned on doing. We were going to do a phased implementation. We just didn't have that luxury. To anyone who is considering moving from an alternative solution to this one, I would say, "Don't hesitate." I've told everyone I've talked to that this is a much better product. They'll be much happier with it. There was a lot of resistance early on but, the more people have used it, the more positive they have become. I think they have really started to like the product. We have about 50 users and all of them are in application development. For deployment and maintenance, it was just me and one of my staff. We maintain the skeletons and CLISTs and troubleshoot if we have a promote/deploy failure. They do happen but probably less frequently than with ChangeMan. It's used every day. It's constantly being used by the application developers. We don't have any explicit plans to increase its use, other than as we add developers. We do plan to make use of Topaz. We've been struggling with coming up with a training date but once that occurs, we hope that people that would use Topaz. We don't have it integrated with anything. There's been some talk of looking into that but I can't say which direction it will go. I would rate this solution a nine out of ten. The two things I mentioned earlier, the ways it could be improved, would make it a ten. If we could get a little better documentation and a little better error reporting from the promote/deploy processes, that would sure make my life easier.