I would recommend for any BPM implementation - and I have been dedicated to this the last 11 years - that you have a very clear objective, the goal of the BPM implementation. It's not the tool for the tool's sake. The end of the project is not the project itself or the tool itself. The end must be, "Okay this process is from this current condition, has these performance indicators, and I want to obtain this improvement. If the process is taking three days I want it to take one day. If the process is costing $100, I want it to costs $40. If the process requires 10 signatures, I want to apply one." 

So at the beginning, for me, it's three things. One, that you have the goal clearly defined for the process. Second, that you have support from the directors. And third, that you need to work in a non-traditional way.

Regarding the third piece, one of the values of BPM is that the customer should be able to see the benefits and the resources, step by step. In addition to the the sponsor, involve the key users in the process, almost on a weekly basis. That means that each week you need to show them the progress.

If you have those three, usually projects  are successful. 

In terms of Red Hat, I think it is no different from any software really. You need to understand very well what you are you buying, what you get with it, what you need to complement it, and to decide if you put it in the cloud or not, from the beginning.

It is a very technical project, so you need technical people looking very closely with the architect from Red Hat, or from the vendor. Don't forget anything, like the operating system, the database, to have a clear diagram of that.