10.30.07
Moving Targets
We’re glad that the Orlando area is having a temporary break from its drought, because it forced us to stay inside the walls of our faux Italian villa resort complex while attending Pegaworld 2007 to stick around and see how a few Pegasystems customers are actually implementing BPM.
One shouldn’t generalize, but when we look at BPM, customers expect it to either (1) provide a more business-focused approach to integrating applications, or (2) offer a more flexible, reusable framework for developing custom applications that are simply too complex or address requirements beyond the scope of conventional packaged software. Call it a freak of sampling, but at the conference, most of the customers we sat down with were trying to pick up where the ERP folks left off.
Pegasystems provides a rules-driven approach to BPM that it recommends be implemented using iterative, rather than waterfall development. Among those we spoke to today, one customer, Helphire Group plc, took that advice to the extreme with an approach that fused principles of agile development and lean manufacturing called Lean Software Development.
Their presentation raised an interesting riddle: to what extent can you apply agile principles to implementing a technology whose hallmark is agility?
Helphire is a UK business process outsourcing firm that performs various services for auto insurers who are dealing with policyholders who have had accidents. The project was to replace the 15-year old core business system that dated back to the company’s founding. What’s interesting is that the company’s IT managing director, who championed the lean techniques, knew well what he didn’t want. In a previous life in the employ of the UK government, managing IT director Richard Edwards was involved with development of SSADM, a mother of all waterfall development processes.
Helphire benefited from having an entrepreneurial culture, where the CEO and founder remains very hands-on, and business users are encouraged to engage with IT and vice versa. And it benefited from having an IT director who was also a process expert — and knew how to pick his targets. In this case, selecting a bare bones implementation of the core end-to-end process, but without all the branching. OK, you couldn’t use the software, but at least business users could be impressed that the thing could work.
Six months, and four more release cycles later, the system went live.
A hallmark of lean manufacturing and agile development is that you postpone final decisions to the latest possible point so you can stay sync’ed with customer demand — which in this case is software project requirements (or “stories’ in agilespeak). A “master engineer” who is supposed to retain the vision is supposed to play final umpire, so the project doesn’t stray or get weighed down with scope creep as users get greedy.
Not surprisingly, we encountered a wide spectrum of reactions to Helphire’s lean approach. Among them was another attendee that had dabbled with agile, but unfortunately picked the wrong target and failed. Not that his company was the only one vulnerable to failure; in an earlier incarnation of this project, Helphire itself failed with an aborted 18-month ERP implementation.
The skeptic speculated that in an age of SOX and related corporate governance regulation, no CFO in his or her right mind would sign off on a project whose goals are moving targets. What’s interesting is how Edwards compared classic waterfall vs. lean development. In one of his metaphors, he described waterfall as a process where you aim, re-aim, then shoot, while lean is more a process of shoot, then redirect.
Our advice? When shooting first, you’d better know your target.