Here’s 8 tips I’ve assembled over the years of implementing Pegasystems PRPC BPMS, but I think they  apply to virtually any BPMS. While some/all of these seem like pretty standard best-practices – experience and discussions with industry peers has proven to me they aren’t well implemented in practice. I think it’s important to be thinking about each one of these things, and the earlier the better!

Tip #1: Use Out-of-the-Box capabilities for your first development iteration, then demo result to clients (and by clients I mean the business unit/leaders/users NOT IT), only customize or “improve” upon it after you’ve given them a chance to see it and make suggestions, and in-turn provide options. Too often, teams are to eager to dive in and start customizing before showing what the tool can do OOB. Additionally, keep in mind there’s a difference between “customization” of OOB features, and butchering of code. If you must customize, take the time to do it right!

Tip #2: Don’t rush your first implementation. Yes, quick builds can be done. Yes, I know the sales guys told you all kinds of cool stuff and you can do everything you need to do in 6 weeks, etc… However – what you build today will be the foundation of what you build tomorrow. Take the time to pour the concrete and reinforce it correctly before you build the house on top of it, so to speak.

Tip #3: “Later” is not a good time to implement a Center of Excellence, Design/Development guidelines, or to begin thinking about governance and reusable assets. In fact, I’d argue that BEFORE you start development is a great time to put some of this in place. Your ROI will be returned in magnitude down the road by getting this right…

Tip #4: The BPM space is growing, hiring is growing. Also growing: the number of people hired and rushed through poor enablement programs and then sold to clients as experts.  Companies don’t just grow their practice expertise by the thousands by hiring experts who are already experienced – there’s just not that many people with serious experience out there, yet. You hire outside for expertise (I hope), be aware if you’re getting it or not.

Tip #5: Don’t forget standard BPM practice of continuous process improvement for both the application, and your processes that support it. If you don’t have a strategy for this you won’t fully benefit from BPM. In order to do this correctly, you need proper metrics, and proactive measurements. You can’t know where you are if you don’t know where you were, nor can you judge if your changes are truly successful if you’re not measuring the correct criteria.

Tip #6: If you want your BPMS implementation to be successful, get the business highly engaged early in the process and design to let the business really manage their rules from within the application. Too often IT focuses on just delivering the application without thinking about how to truly give the power back to the business users. IT should enable this as a value-add from good design, not dictate a bureaucracy around how and when business can react to market changes.

Tip #7: When designing, be thinking about situational execution, that is, how can you inject flexibility into the design so unpredictable scenarios can be handled by the application you deliver? You can still control the end-to-end process and be flexible where needed, your process is incomplete if it doesn’t handle exceptions well. See my earlier post for a great case study on this. Users ultimately want flexibility, give it to them where you can/should!

Tip #8: Implement automated governance to watch code quality. A good automated governance solution will match code against design/development guidelines and prevent it from being checked into the rulebase if it doesn’t meet those guidelines. In addition, creation of reports and an easy-to-use dashboard/portal can host a wide variety of reports to help ensure quality code is being delivered within your tool. Evolve this over time as design/code reviews, and multiple iterations begin to show you where there are gaps.