I finally got to do a follow up on the PMI event where I presented BPM to project managers. While the content was designed for a general audience, the discussion was very interactive and touched on some very good questions:
- How intertwined are BPM projects and agile methodologies?
- What techniques exist to manage the significant number of stakeholders of an end-to-end process?
- What is the impact of BPM if taken outside of a single project?
I’ll consider the first here, while we dedicate separate posts to the others. So, is BPM a necessary and sufficient condition for agile projects? In my presentation I must have used the A word profusely, as someone commented afterwards that this was the message that came out.
It is certainly true that one of the key benefits of managing one’s processes using sophisticated techniques and tools is the agility afforded in conducting one’s business. A favourite example from my personal experience was created for a client in the insurance industry that had to react to external events, such as hurricanes, which could significantly affect the workload of the organization. To deal with such variation, significant numbers of the process rules controlling task routing and quality assurance were delegated to business managers, who could modify the live process, without involving IT, and thus be more agile than if these rules were engrained in legacy applications or, worse, in legacy workers.
This sort of business agility is somewhat different from the agile methodologies that have been gaining ground in the world of project management. Indeed, they specifically target the processes used to deliver new capabilities, irrespective of what these capabilities are. An agile project that results in a custom-built system may not create much business agility if it was designed as a point solution.
Using this understanding to reframe the relationship between BPM and agile, I would argue that controlling one’s processes is indeed necessary to be agile in today’s customer-centric business world. It is too risky to empower your staff to do whatever it takes to create positive outcomes without enforcing accountability and compliance standards. It is riskier yet to leave them helpless and at the mercy of the obsolete policies hard-coded in your legacy systems. Striking the right balance is one of the key advantages of BPM, where managed processes can be designed for flexibility and control at the same time.
But what about BPM and agile methodologies? Should all agile projects use BPM tools & techniques? During my presentation I mentioned the reduced time-to-market of BPM solutions compared to their bespoke counterparts. This stems from the out-of-the-box functionalities available on some BPM platforms, as well as the model-driven approach which reduces rework when stakeholders can capture their requirements and directly validate that the results match their expectations. The former can be achieved with any number of toolkits, whereas the latter is still a rarity, although BPM suites usually afford such capabilities. In any case, however, there is no minimum velocity that an agile team must achieve under all circumstances, and thus, the lack of BPM tools & techniques may affect the efficiency of the team, but not necessarily their effectiveness.
In summary, whether you seek business agility to meet your customer’s expectations or plan to use an agile methodology in the delivery of a new business capability, including a BPM component into your solution should bring significant value to your initiative.