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.