BPM in the Real World
Process Improvement Doesn't Care What Language You Speak
By Phil Ayres, Founder, Consected
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'
- 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,
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
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 email@example.comMore by Phil Ayres