Process Improvement Doesn't Care What Language You Speak

Editor's note: What are the best practices in moving data to the clouds? Learn more here!



I have never been shy about taking on a new challenge. So when I was offered the opportunity to be a lead consultant on a BPM implementation project, I jumped at it. I had been out of consulting and project management for a while, but I thought it would be like riding a bicycle, a skill I would never forget. Did it matter that I would be riding that consulting bicycle on the wrong side of the road in Mexico City, with only Spanish language skills picked up during a lengthy stint of tourism? I heard the words "sign me up" escape my mouth while I was still considering these questions.

A few weeks later I found myself in Mexico City, ready for a three month project, with no idea where the client's office was, and a new realization that Google Maps doesn't work well in a city of 21 million inhabitants and about as many different street names. Despite that, my real lessons started about fifteen minutes after eventually finding the office.

Lesson 1: Get engaged early

When I walked through the door of ALICO, Mexico (a part of AIG Foreign Life Division), I was already a little behind on the project. My colleague for the next three months was an extremely smart Argentinian, Gerardo, who had been on-site for the three days prior to my arrival. He had already worked out the lay of the land, and was ready for the challenge of helping me through the obvious language difficulties (even though he spoke less English than I spoke Spanish).

Gerardo's first task was to introduce me to the business analysis team (referred to affectionately as Las Chicas) who had been defining the process best-practices for the underwriting and policy management groups we would be improving. Their welcoming gift to me was a binder containing close to 3 pounds of printed materials, covering every facet of the intended processes: the ACORD standards definitions of the underwriting activities; photocopies of forms and documents used for new business; BPMN standard notation guides; three over-sized Visio diagrams showing the proposed processes, cross referencing the ACORD standards previously mentioned. In other words, it was a gratefully received paper doorstop.

The first real lesson learned was this: business analysts who have never been involved in a BPM project, and seasoned BPM consultants who have done many, view the priorities for requirements analysis very differently.

For a BPM consultant, everything you see and discuss is polarized by the eventual solution and BPM product you are going to implement. Las Chicas had only seen the proposed BPM product once, and did not perform their analysis looking through the same lens. As any process improvement specialist will try to persuade you, a good business analyst starts with an open mind when defining new processes, only constraining herself within the capabilities of a product when it is clear that the chosen tool is the right one. If a BPM product has already been selected, as was the case in our project, it is essential that the BPM consultants and business analysts get engaged early, to ensure that there is enough understanding of the best-practices of the BPM product to balance the detailed definition of the ideal 'to-be' process. In this case, we would have hit the ground running if everybody had a common understanding of what is possible in reality before ever arriving on-site.

Lesson 2: 'Agile' and 'Trust' must go hand in hand

Gerardo, not only smart and adaptable, was an expert in training organizations in the use of agile software development methodologies. This was going to be invaluable (even though we planned on writing little code), as our charter was to deliver two new BPM solutions in under 3 months. It was unlikely we were ever going to hit that goal with a traditional waterfall implementation strategy, since the draft project scope was not yet agreed on. So we took it upon ourselves to rewrite the scope document with an agile methodology in mind. While Gerardo modified a Scrum approach, having us present iterations of the new solution every week (rather than the more common monthly target for Scrum), I rewrote the scope document to be as open and flexible in the defined solution as the client would allow. Our only commitment was that some form of solution would be available to meet every requirement, however shallow that may be.

This approach was probably the biggest gamble of the project. Our extremely agile strategy relied on minimal documentation, just-in-time design, and buy-in from the end-users that they didn't have too many shots at getting their requirements right before we ran out of time. By embarking on this agile strategy we had an implicit agreement from the client that the scope document was a guide, not a contractual specification. For success, we had to make a very quick judgment call -- could we trust our client contacts to remember this agreement when we raced to project sign-off three months down the road?

The lesson learned was to only make a gamble on such an approach if you feel you can trust your client to remain flexible, and they feel they can trust you to deliver what is considered to be most valuable in the time available. In another project, it may be necessary to provide a more formal specification or even abandon an agile approach mid-flow if there is a failure of trust. In our case, the mutual trust was not misplaced.

Lesson 3: Code fills gaps and creates ravines

We bravely embarked on our agile process improvement, BPM and national language learning project. We had a common understanding of high level requirements, a 3 pound paper doorstop, and a scope document that we all agreed on. So we started work where the rubber meets the road, implementing prototype processes, data and document storage in the BPM tool. I remember clearly thinking that weekly iterations ('sprints' in Scrum terminology) would be fine, until I looked at the weekly schedule for the first time:

  • Day 1 (am): Educate users on Scrum and the BPM tool; hear their initial requirements and prioritize them. Sketch the main activities of their 'as-is' process.
  • Day 1 (pm): See if the sketch fits the 'to-be' process Visio in the 3 pound paper doorstop. Adjust as appropriate.
  • Days 2 - 4: Implement as much as possible in the BPM tool, working down the priority list.
  • Day 5: Test the prototype to make sure that its going to work when showing it to users at the start of the next iteration.
  • Day 1 (week 2+): Demonstrate the prototype, gather feedback and draw up a new priority list of deliverables for the coming week.
  • Repeat for weeks 2 through 6...

The reality is that three days per week to implement anything new is not a lot of time, when you only have six weeks develop a solution, so when working with the BPM tool we had to make every second count. Gerardo and I are not true software developers. Our third learning experience came when we arrived at the boundaries of what the tool could do through configuration alone. As soon as a new requirement appeared, for a mashed-up user interface and non-standard data validation, progress became treacherous. A piece of script that should take 10 minutes to put together could consume half a day as we picked at bugs introduced as a result of rapid design, or just not being able to consider all the ramifications in a single human brain.

Our third lesson was simple -- if you can avoid coding (and in my opinion HTML, Javascript and all that proprietary script inside a BPM tool is code) do so. Code makes BPM solutions brittle, and hard for business users to update in the future. From a development standpoint, code adds risk to a tight schedule. Put another way, balance the priorities of your requirements with the risk of implementing them, and use that to schedule your implementation tasks for the next sprint. Because without that approach, one day you, as we did, will walk into a weekly user / stakeholder meeting with very little to show.

The Final Lesson: Business value is all that matters

We were successful! We delivered two BPM solutions to time and to budget, and I improved my ability to communicate with Las Chicas in terms of their business analyst needs. But communication abilities and even 'to time and to budget' are largely irrelevant successes in a BPM project.

The final lesson is this this: BPM is implemented for one reason alone -- business value.

It is the results, such as those I discovered checking-in with the client six months after go-live, which show BPM is valuable when done well. For this client the results are clear; the time it takes from a sales executive requesting a new quote, through to a policy being issued has been reduced -- from twelve days to just two. This is just one indicator of many likely process improvements: the sales executives are providing underwriters with complete requirements first time, leading to less time being wasted re-quoting the same prospect, allowing underwriters bandwidth to work on more new business. Sales executives are not tied up on the same opportunity for days or weeks on end, and can chase more new business (the sales execs love the tool apparently). Policy administrators get the right information first time, every time, making policy rework a non-issue. I have not seen how this really results in cost savings or increased sales at ALICO, though I know of an example at a similar insurer in the US. For them, reducing the turn around time for an initial quote to under 24 hours could lead to a 50% increase in the number of quotes converted to new policies and a 30% reduction in cost per transaction. That is business value, and it is the reason companies run BPM projects.

Process improvement is never complete and the client is sure to look at this success as an opportunity for further improvement. They could enhance the integration with back-end systems; they could repeat the project in another line of business; they could implement a claims process. Business value is all that matters, which makes it easy to identify the next BPM project.

About the Author

Phil Ayres brings 14 years of global experience with BPM and ECM and is the founder of Consected. Contact Phil at phil.ayres@consected.com

More by Phil Ayres