I saw Elise Olding speak at the September conference together with Bill Rosser, and I wasn’t completely impressed, but I think that she was fairly new to Gartner so wanted to take a second look. She’s focusing on three issues in this presentation:
- How should users assess organizational readiness?
- How should you initiate BPM and what does a plan for getting started look like?
- What are the critical success factors to long-term success with BPM?
She breezed pretty quickly past the business process maturity model — again, I thought that Gartner would be focusing more on this — but covered some great points on the importance of corporate culture and change management when implementing BPM: exactly the things that many companies ignore, especially if BPM is being pushed by IT rather than pulled by the business. She makes the point that many factors required for BPM success don’t come naturally to many organizations, and discussed three enterprise personality profiles that determine the approach and goals:
- Aggressives have an imperative to stay ahead of the pack; they’re trying to seize advantage.
- Moderates have an imperative to get leverage over their direct competitors; they’re seeking parity in the marketplace.
- Conservatives have an imperative to catch up with the bulk of the competitive pack; they’re trying to reduce pain and (although she didn’t state this explicitly) probably just stay alive.
She went through the different project roles and the skills associated with those roles: executive sponsor, business process improvement director, business process improvement project lead, design team, subject matter experts, and business process analyst. She drilled in specifically on the executive sponsor role and how important it is to have the right fit: an involved decision-maker with the right motivation and influence across the enterprise.
Next up were the steps for initiating a BPM project: determining objectives (e.g., agility, compliance), understanding and defining critical processes (e.g., delivering products and services), determining the initial organizational model (e.g., reporting structure for process-specific functions), implementing a “getting started” checklist (14 key project activities that she identifies, e.g., develop business case), and documenting and using the BPM plan (actually just normal project plan/management). She spent quite a bit of time on these five points, and provided a lot of valuable detail and examples; this isn’t rocket science, but it’s good planning strategy that doesn’t add a lot of overhead.
She stressed some key points that apply to any type of IT project, not just BPM:
- Focus on the right methodology first before selecting even the technology class, much less a particular vendor or tool
- Projects must be compelling and tied to business strategy, and be prepared to go back at the end and see if the promised benefits were actually achieved
- Pick the first project carefully: a success here will pave the way for later projects
- Assign the right resources at the right time, including maintaining continuity of key resources throughout the project
- Establish governance, but start out with a light touch and add more rigor later
As I mentioned in my review of her previous presentation, her background seems to be focused on strategic IT planning, so that many of her comments are applicable to other technologies, but she’s done a good job of moving from a generic IT strategy to a mostly BPM-focused strategy. She’s really talking about business architecture in this presentation, where BPM is just one of the methodologies and tools that might be used as part of business architecture — she stated explicitly that enterprise architecture is the context for BPM, a view that I’ve been discussing with my clients for some time. Unfortunately, many EA efforts are really more information architecture groups within IT, and they mostly ignore business architecture and other “soft” parts of the architecture.
There was a question about how to reconcile business analysts in both business and IT reporting areas; unfortunately, I think that she misunderstood this as how to reconcile business analysts in business and system analysts in IT, which is a communication issue rather than an organizational issue. I often see the business analyst title used for people in both IT and business, and my feeling is that business analysts belong in the business, although business process analysts should have at least dotted-line reporting to a BPM center of excellence if one exists. I’d love to hear any comments from readers on what they’ve experienced here with where business (process) analysts report and what works best.
Another question was about the role of the executive sponsor, and she had some good comments on how to manage your executive sponsor: establish a service level agreement with them, where they agree to four hours each week of effort, and agree to a specific timeline for responding to requests for decisions. A recommendation of hers, which would be difficult for a lot of people, is to document in the project reports if the executive sponsor is not meeting their obligations.