Lombardi Driven: Lessons Learned

Toby Cappello, Lombardi’s VP of Professional Services, led a breakout session on lessons learned in implementing BPM. He breaks them down into three categories: project/delivery, training/mentoring and program/enterprise.


  • BPM is about productivity and visibility
    • Metrics, KPIs and SLAs should be part of the define phase
    • Don’t scope out metrics [i.e., don’t remove metrics from the scope]
    • Remember visibility drives improvement
  • Integrations, integrations, integrations
    • Don’t underestimate and start early
    • Don’t forget the focus should be on business value
    • Be willing to make a trade-off for the first release
  • “One and Done”
    • Iterative approach…continuous process improvement
    • Phase is NOT a 4-letter word
    • Trade-offs, but don’t always trade-off the reports
  • Requirements documents are not process analysis
    • Consider all options for capturing requirements
    • Don’t over-do the requirements (define) phase
    • Include process analysis skills on your team early
  • A project longer than 90 days is not a failure
    • Self-sufficiency can extend project timelines
    • Some projects are more complex
    • Timelines can be dependent upon the sophistication of the process


  • Java (.Net) developers aren’t all you need
    • Have the right mix of resources on the team
    • Understand the value of face-to-face engagement
    • Identify good pools of talent for developers (BPMC’s)
  • Self-sufficiency requires dedication and commitment
    • Don’t allocate partial FTE’s to the core project team
    • Make sure all of the right skills are represented
    • Don’t mix self-sufficiency with tight deadlines


  • Fund to value, not first release
    • BPM is about CPI
    • BPM should be programmatic
    • Funding model should contemplate projects and the program
  • Collaboration between business and IT is critical
    • Consider carefully for the first project
    • Do not maintain the “wall”, i.e., the physical and/or cultural separation between business and IT team members
    • Leverage the playbacks
  • Ownership (BPM BPMS, process)
    • Processes are business-owned
    • BPM is the discipline/program
    • BPMS is the enabling technology

Cappello had lots of great anecdotes and examples of how these lessons have been applied at their customers, but they’re all generic enough for any BPM project; in fact, most can be applied to any sort of business-IT project.

Some audience discussion raised the point that integration is the single biggest point of risk in any BPM initiative; I’ve seen this a lot, especially in cases when you could trade off by continuing to do part of a process manually for a while instead of undertaking a time-consuming and expensive integration in the first phase. “Broad, then deep” is the way to go in terms of implementing processes.

That’s my last session for Driven, and my last conference (I hope) until September. Now I’ll have a chance to catch up on my real work (the stuff that pays the bills) as well as the partially-written product reviews that I have sitting in Live Writer.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.