BPM Rapid Development Methodology

Today at the IRM BPM conference, I started with a session by Chris Ryan of Jardine Lloyd Thompson on a rapid development methodology with BPMS in their employee benefits products area.

They’ve been a HandySoft customer since 2004, using BizFlow both for internal applications, and for external-facing solutions that their customers use directly; they switched off a Pega project that was going on (and struggling) in one of their acquisitions and replaced it with BizFlow in about 4 months. However, they were starting to become a victim of their own success, with many parts of the organization wanting their process applications developed by the same small development team.

They weren’t doing their BPM solutions in a consistent and efficient fashion, and were using a waterfall methodology; they decided to move to an Agile development methodology, where the requirements, process definition and application/form design are all done pretty much simultaneously with full testing happening near the end but still overlapping with ongoing development. They’ve also starting thinking about their processes in a more service-oriented way that allows them to design (sub)processes for specific discrete functions, so that different people can be working on the subprocesses that will make up part of a higher-level process. This has tracking implications as well: users viewing a process in flight can look at the top level process, or drill down into the individual functions/subprocesses as required.

They’ve established best practices and templates for their user interface design, greatly reducing the time required and improving consistency. They’ve built in a number of usability measures, such as reducing navigation and presenting only the information required at a specific step. I think that this type of standardization is something rarely done in the user interface end of BPMS development, and I can see how it would accelerate their development efforts. It’s also interesting that they moved away from cowboy-style development into a more disciplined approach, even while implementing Agile: the two are definitely not mutually exclusive.

This new methodology and best practices – resulting in a lean BPM team of analysts, PMs, developers, testers and report writers – have  allowed them to complete five large projects incorporating 127 different processes in the past year. Their business analysts actually design the processes, involving the developers only for the technical bindings; this means that the BAs do about 50% of the “development”, which is what all of the BPMS vendors will tell you should be happening, but rarely actually happens in practice.

From an ROI standpoint, they’ve provided the infrastructure that has allowed the company to grow its net profit by 46%, in part through headcount reduction of as much as 50% in some areas, and also in the elimination of redundant systems (e.g., Pega).

They’ve built a business process competency center, and he listed the specific competencies that they’ve been developing in their project managers, analysts, developers and “talent development” (training, best practices and standards). Interestingly, he pointed out that their developers don’t need to have really serious technical skills because the BizFlow developer really doesn’t get that technical.

He finished up with their key success factors: business involvement and user engagement, constant clear communications amongst stakeholders, and good vendor support. They found that remote teams can work well, as long as the communication methods support the user engagement throughout the process, since Agile requires constant review by users and retuning of the application under development throughout the lifecycle, not just during a final testing stage.

Great success story, both for JLT and for HandySoft.

7 thoughts on “BPM Rapid Development Methodology”

  1. Great article- This is great to see and read about.

    I’ve seen a similar agile approaches applied successfully in a few contexts. The biggest pitfall I’ve seen is iterating too much on the “happy path”. Generally this means you end up with a lot of exception flows that are manually driven (e.g. email to a shared mailbox and someone needs to work it out from there).

    This can be appropriate in discrete cases, but it abused it becomes a mess and operational nightmare pretty quickly.

    Manual exceptions are fine, but one of the keys of agile is tackling the “high risk” problems first – so make sure you’re not skipping over the hard pieces.

  2. Jon, great point about attacking the high risk problems early, thanks for commenting. Focusing on the happy path can happen with any development methodology, however.

  3. Sandra, thanks for the post. You wrote:
    “Their business analysts actually design the processes, involving the developers only for the technical bindings; this means that the BAs do about 50% of the “development”, which is what all of the BPMS vendors will tell you should be happening, but rarely actually happens in practice.”
    It confirms that all that analysts can do is the flows. All the rest has to be coded by programmers or engineers, and that includes mostly unmodelled backend interfaces, complex logic that should be done by rules. dynamic, data dependent content and special GUI requirements. A truly adaptive environment performs such setups only once from the perspective of a business architecture.

    It also puts another nail in the coffin of BPM as jobkiller:
    “From an ROI standpoint, they’ve provided the infrastructure that has allowed the company to grow its net profit by 46%, in part through headcount reduction of as much as 50% in some areas, and also in the elimination of redundant systems (e.g., Pega).” That means it reduces the ability to serve the customer and reduces innovation and skilled manpower.

    Software savings are not a valid argument. Pega is one of the high-end BPM systems, meaning that they had invested already a lot into BPM and thu sit has to be added to the overall cost of BPM in this business.

    Adaptive processes (i.e. in ACM) don’t have exceptions. All unexpected events can be handled by assigning them to a goal and its either predefined or ad-hoc created tasks. Users can pick all BA defined components from a library and use them without needing engineers. Certainly it helps to have a process owner/coach who provides guidance that no too many unneccesary variants of processes are created. A CoE ican quickly turn into more added bureaucracy. in ACM flows are mostly used by engineers for standardized, reusable backend orchestration.

  4. Max, re: software savings- since the Pega purchase was made by an acquired firm (and even if it wasn’t) there’s a savings against future software maintenance costs, not to mention other infrastructure maint. The previous cost of Pega was a sunk cost. A bit like buying a company and shutting down one of their factories. The cost of that factory was a real cost. But the savings of maint on that factory are still real, going forward.

    Re: BPM as job killer. It is a datapoint from a company that viewed staff reduction as a goal or benefit from a cost point of view. Without knowing more about their business we can’t say with certainty that ability to serve the customer was impacted. We just don’t have enough data. If you increase the productivity of a team, and the work load does not increase, fewer people are required to do the work. Chip design software reduced the # of electrical engineers required to design chips, but chip design has hardly suffered as a result (in the long run).

    “ACM” may be the holy grail, but that doesn’t mean that even successful BPM projects are failures.

  5. Scott, thanks for the reply. I apologize for disagreeing. Sunk cost is sunk cost, regardless for what reason. They didn’t see BPM as productive and they killed it.

    My main point is that BPM is being sold after all primarily as a cost reduction tool. I keep saying that I am not talkng about manufacturing processes. Chip design software is not about automating human interactions. Clearly, software in general has improved many areas of work and made people more productive and did reduce the ncessary workforce. That in itself is not yet a bad thing for people and the business if it happens as a consequence of other improvements. Agreed, I am idealistic bere but I have yet to see BPM automation having a positive effect on a business in terms of quality of service process outcomes. Once again it all depends as what you call ‘successful’.

    ACM is just a short way of talking about business-architectured, user-adaptive processes. I guess I should stop talking about ACM if is seen as so offensive to BPM proponents. ACM is a BPM approach after all. Pega calls it (DCM) ‘the future of BPM’.

  6. I’d be interested to hear the reasons why Pega was turfed in favour of Bizflow – if you listen to the Gartner Hype, Pega seems to be the poster boy of BPM at the moment. I found it surprising to hear this.

  7. Craig, just because a vendor is in the top right of any analyst quadrant doesn’t mean that it’s a good fit for everyone — if so, those reports would be worth a lot more than they are today.

    My impression from the presentation is that the Pega implementation was overly complex and had gone on for a long time, and wasn’t yet considered complete. This can often happen in large implementations regardless of the technology, since it’s wrapped up in who and how does it as much as what. That being said, older versions of Pega (which is likely what they were using, considering the timing) were certainly difficult to work with, and required a pretty significant skill level to be successful. Even for more structured BPM, reducing the technical skills required to participate in the design and creation, and putting more control in the hands of the business, is critical.

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.