At the end of each testing period, we need to step back and assess our progress. Are the issues that are being raised related to the underlying process or to the web console user interface? The two types of issues would probably be worked on by different parts of the application team, so it would be good to make responsibility for each issue clear in the list.
It is also worthwhile looking at the results on a fundamental level: are the issues that are coming up ones that can be fixed, or is jBPM simply not the right kind of solution for our problem? We should not feel bad if indeed, we do have to reject jBPM, as there is no point flogging a dead horse, and sometimes, it is better to admit defeat than carry on regardless.