Deploying it is a complex process, but BMC did a great job of supporting that process and working with us. They answered our questions and tried to understand our environment so that all process were support in the ISPW installation. You should definitely engage the professional services group to help you with the installation. While it was very complex, it was also very thoroughly understood by the teams that we worked with. They did a great job, evidenced by the fact that we were able to convert to  ISPW from two different Endeavor sites and one CA-Panvalet sites,  with between 30,000 and 50,000 programs a-piece, and be up and running at those sites in nine months.

I would certainly encourage everyone to engage their professional services and have a company team available to work with the professional services team. You need both sides. You need somebody within your company who understands what your company does, how all the processes work, and how each process will work using ISPW.  It's your responsibility, as a company, to own that process, and it's  BMC Compuware's responsibility to help you. It is not a case where you do nothing and they come and install it. You have to be engaged. And how you're going to train people should be talked about early in the process as well.

It is a complex process, but as long as both sides, your company and BMC Compuware work together, the result will be a very positive experience. Our project was very successful and was completed on time and within budget. 

When it comes to the actual installation, when you're setting up the parameters for how ISPW will work in your shop, there are a lot of questions that have to be answered. That's pretty normal with any software that you have to install, but because ISPW is a new animal and not very many people have a lot of experience with it, BMC Compuware should have more in-depth explanations about what the installation parameters mean and how each choice will impact your set-up.  I shared this feedback with BMC Compuware.

For example, one of the questions was, "Do you want to have a brand new load library that ISPW promotes the programs into for Production?" Depending on the answer to that question you could cause a lot of additional work to be done. The installation steps should contain some pros and cons about the options you can pick.

In terms of a deployment strategy, we picked some programs from several applications when we began the installation at each of our affiliates and we put up a test version of ISPW. Because we had a test area set aside for this work, we didn't interfere with anything else the development and production support teams were doing. We pulled real programs into the test version of ISPW and had our test team compile the programs, link-edit the programs, and test the programs using ISPW. We also used this test ISPW environment with real application code in it for training, so that when we had the developers sit down for those training sessions, they saw their real programs. 

In terms of maintaining the solution, there doesn't seem to be a lot involved, although you will need an administrator. The first few months there are certainly bumps that have to be worked out, but they were always there to answer our questions. After that, on a day-to-day basis, once you get the primary functions covered ISPW is very stable. There isn't a lot of breakage. The care and feeding have been very minimal since we went live with ISPW. 

The setup was pretty complex. Compuware came in and did it as part of the purchase, and then they did some training.

A lot of it was conversion from ChangeMan. That was something that we could not have done, just to state it simply. We don't often come across a product that we can't convert to and implement. We've done a large number of them. This one, in particular, after seeing what they had to do - we couldn't have done it.

It was a rushed deployment because we had a licensing misunderstanding with Serena/Micro Focus. We pretty much had to convert in a month. There were actually a couple weeks where we went without a change-control product, and we were doing manual compiles. It took a month to convert it and implement it, and then we were making changes and still implementing, to be honest. That propagation issue is one of them; the planned binds is another. There are still a couple things that are not implemented. But it's net new functionality that we never had before.

Because it was so rushed, our implementation strategy was "cross our fingers and hope for the best." We actually had a longer-duration plan, but when we found out from our purchasing department that our licensing was about to expire, we had to rush things. We're not a good example to use for the right implementation approach, because it was so hurried.

I would rate the initial setup of this solution an eight, on a scale from one to 10, with one being the worst and 10 being the best. The deployment took a couple of months.

The solution requires an intensive planning process to deployment. Also, deployment is not immediate. We're not talking about the deployment of an app like Windows, which can be done in five minutes. We're talking about months. In some cases, it can even take a year. With this solution, deployment is an ongoing process; it is not something that you do once and you are done with it. 

To deploy this solution correctly, you first need to carry out an analysis of the current situation. After that, you need to decide what to do with it. This product is, generally speaking, for organizations that have problems in the development cycle. This tool automates the development cycle and makes it more efficient.

After the solution is deployed, it can be maintained by a single person.