BPM - Building for Everyone, Failing Constantly

Over the past 19 years I have been involved in hundreds of automation projects.  Whether it was automating a small department application or creating a huge enterprise wide application used by thousands of users, the problems are always the same.  In this blog I would like to discuss how to make your business process automation projects a success while avoiding the common pitfalls that normally lead to massive failures and over budget solutions.

TALK PROCESS NOT TECHNOLOGY

One common theme when building an automation solution is the idea that it needs to be implemented with a certain technology or vendor.  Many people start out by saying "We need to fix the problem using 'X' technology!".  What they really need to be saying is "What is the business problem?  How would we tackle fixing this in an ideal world, without the limitations of a preferred technology?".  

The technical solution is irrelevant if you do not understand the business problem.  Avoid talking technology and start talking business problems and solutions.  In the end, select the technology that best aligns with the solution to the business problem, not the technology you like or already own.

INVOLVE STAKEHOLDERS

One of the common mistakes is letting the IT department make 100% of the decisions regarding an automation project.  Although IT is always necessary in the evaluation and implementation phases, they normally lack the business knowledge and experience of the people who will ultimately use the software daily.  Remember, you are not trying to get IT onboard (they are already onboard and want you to be automated and paperless!), you are trying to get the business onboard.  Getting the business onboard means the business will have a voice in the process and that you respect their experience and opinion.  Listening to the business users and having them be an active contributor means higher success rates and greater user adoption. 

LISTEN THEN REPEAT

There is one formula that I have developed over the years that is key to nailing down the key requirements.  It is the ability to listen, document, and repeat.  I listen to the business users and document what they say in a bulleted list in Microsoft Word.  As items are added to the list, I verbally go back over and repeat the entire list from top to bottom.  Every time an item is added to the list, I repeat the entire list.  I do this over and over and over again!  As new items are discovered simply insert them in the list where it belongs, then repeat.  You’ll be surprised how new items will pop into your list even after the business user has said that area was done.  There is always more to the story then what meets the eye. 

ASK WHY

As I define a process I like to ask why almost as much as I like Sour Patch Kids. I like to challenge every step of a process with a “why do you need this?”.  If there is no reason to justify the requirement, we drop it off the list.  You’ll be surprised that many steps in a process are simply there because they have always been there, even if nobody knows why or cares.  As an outsider (Consultant) it makes it much easier for me to challenge the authority because I could care less about politics or people’s feelings.  If you can’t justify why you do something, maybe, just maybe ... you shouldn’t be doing it at all.

WE ARE NOT TRYING TO AUTOMATE YOU!

If you leave it up to the business users, the new solution will do everything including make them coffee and babysit for their kids on Friday nights.  The entertaining aspect about automation is that everyone is afraid they are going to get automated out of their job, yet they want the solution to do EVERYTHING.  In my 19 years in IT, I have never seen a single employee lose a job to a solution I have developed.  I have, however, seen employee’s roles change to be more valuable to the organization as the small stuff can now be taken care of automatically and the hard stuff can be prepared in a way to make them more efficient.  Ultimately, I am not trying to automate you out of a job, I’m just trying to make it easier for YOU to do YOUR job.  My solution shouldn’t do YOUR job for YOU. 

EVALUATE ROI BEFORE YOU BUILD

One of the advantages of being a consultant is that there is a cost associated with every hour of my work.  When you’re an internal employee it’s another story altogether.  The actual cost of your time is often overlooked as just being an “overhead” cost.  When evaluating job functions to automate, you need to take your overhead rate into consideration.  This is a crucial step when calculating the cost of the solution v. the ROI.  If you do this for every feature you will suddenly decide certain items should not be automated as part of your project. 

As an example, if your new application does 10,000 transactions a year and a special use case only accounts for 10 of those transactions yet costs 10% of the project budget, well, maybe you should not include that functionality.  That 10% could be a hot button item!  Consider the added cost to automate those few transactions: Is worth the cost versus just continuing to have those transactions done manually?  It will get political, but when it comes down to dollars and cents, smethings just don’t make sense to automate. 

BUILD FOR THE 80%

Projects often get out of control because you want the solution to do everything.  Recently I was evaluating an RFP for a permitting solution.  In the middle of the RFP there was a requirement to have the solution manage assets like desks and computers.  What the hell does asset management have to do with permitting?  I’ll answer that for you… it doesn’t!  When I am designing a solution, I’m not trying to create a solution that does a 100% of every possible business case.  I look for the solution that meets 80% of what is required.  Realistically that 80% accounts for about 95% of the transactions while that last 20% is only 5% of the total transactions.  Would you pay 20% of your project budget for a 5% return?  What if I told you that last 20% rarely has any ROI and typically drives up the cost of the project by 50-80%?  If it was money out of your own bank account, what would you do?  I guarantee you would find another way to work that 5% without spending a dime.  Automation doesn’t always make sense, so make sure there is an aggressive ROI…otherwise do it the old fashion way.

KISS PRINCIPLE

I remember the first time I ever heard somebody refer to the KISS Principle (Keep it simple, stupid.)  It really resonated with me.  Most processes are way over-engineered (see above Build for 80% and Evaluate ROI before you build).  In almost every case where I’m called into a “disaster” situation with a new client, the problem is that the solution has been over-engineered to accommodate every possible situation because nobody asked “why” or told them “no”.   If you want a solution that will work and stand up to the test of time, you need to make it simple.  Evaluate ROI and cost vs. reward for every use case.  If there is no ROI or if the cost exceeds the benefit, then cut it.  Keep it simple, keep your sanity! 

EVALUATING COTS SOLUTIONS

When you are looking to build a solution you should also consider a COTS, Commercial Off the Shelf, solution.  But not all COTS software is created the same.  Since coming out with our first product, CivicXpress, I have had hundreds of conversations with potential customers.  Our competitors in this space have more experience and more features than our product, but that doesn’t make them a better solution.  If your goal is to get down a river quickly, do you want a speedboat or the Queen Mary II?  Sure, the Queen Mary II is luxurious and has great food, a pool, bars, etc … but your objective was to get down the river fast, not be treated like the Queen of England.  When evaluating a COTS (Commercial off the Shelf) solution you need to ask, what is the base functionality we need to complete our job?  I bet the speed boat that cost $12,000 will get you down river much quicker than the $500M QM2.  Pick the right tool for the job and don’t overcompensate. 

PARTING THOUGHTS FOR YOUR NEXT BUSINESS PROCESS AUTOMATION PROJECT

I hope these tips will help you in your next automation or software selection process.  Remember to keep it simple, mind your budget and justify every feature.  There is always another way or another solution that will be better.  I remember hearing somebody from my youth tell me, no matter how smart and good looking you are there is always somebody smarter and better looking.  I don’t know how that relates, but just thought I would pass it along.

Jason