One of the saddest parts of my job is when I hear from clients about #BPMS implementation disasters. Why? Because in almost every case it could have been avoided.  As consultants, we’ve all seen it… The client brings you in to help fight the fire left behind by an already in-progress, or already delivered application that was designed poorly and nobody bothered to tell the client that before they eventually figured it out the hard (and expensive!) way.  It’s just plain sad. While yes, it’s good for me, because I’m getting paid to help, I much prefer to get paid to help prevent such disasters and ensure success in the first place.

While I think this applies to every implementation, it is even more critical on the first or other early implementations while the client is still building their internal skillsets in the BPMS product.

I’ve noticed some commonalities I’d like to share with you:

  1. The clients hired outside consultants for expertise (usually from a single firm)
  2. If design reviews were done, it was by the same group of people who did the design in the first place
  3. Cost played a large factor in choosing which outside firm to bring in
  4. Implementation schedule was often rushed/aggressive (aren’t they all?)
  5. Vendor/Product guardrails weren’t properly followed
  6. Client employees may bring concerns/risks/issues to light, but backed down easily when the consultants reassured them

The above list may not be an exhaustive list of the warning signs for a potential disaster in the making, and may even all hold true for even very successful implementations, but the first key to prevention is awareness!

Let’s take a closer look at each one of these points.

The clients hired outside consultants for expertise (generally from a single firm)

The good news is: Clients are generally pretty good at understanding their own weaknesses, and know when they need to turn to outside help. This is when RFPs fly around, sales teams with polished presentations come in, and their best and brightest pre-sales technical teams come right along with them to amaze you with the speed and power of their skills. For the very first implementation, perhaps they turn to the software vendor itself even. There’s absolutely nothing wrong with turning to outside consultants for help, when needed. Perhaps the company has a standing list of approved contract partners they work off of to bring teams in. But generally, at the end of that process, a single firm is picked to help get the job done.

The bad news is: Clients don’t have the internal expertise in the first place, which also means they may not have the expertise to know if the people they are bringing in are true experts or not.  That same bright pre-sales tech team might not be the same team that shows up for the first day onsite. That’s not to say the team that does show up won’t be bright as well, it just means they are unknown. The client is trusting their chosen vendor to bring in experts, and guide the implementation in the very best way possible.

While being able to trust your vendors and contracting firms is important, until you’ve seen them succeed in your enterprise with the particular kind of task being asked of them, hope and blind faith is not a business strategy! To mitigate the risk of relying on a single outside firm for expertise contributing to a horrible BPMS design, consider using consultants outside from at least two firms. Like going, getting second opinions can be very valuable!

If design reviews were done, it was by the same group of people who did the design in the first place

Design reviews are an important part of your the BPMS governance process, and the Center of Excellence should be involved to some extent. This is critical early on as the team is maturing, because anything designed and built early on, will become the foundation for everything built in the future.  The issue with these problem design reviews were that the same people who did the design were the ones reviewing it, and obviously, no glaring deficiencies are likely to come to light during this process. Unless you are absolutely confident in your teams ability to produce excellent designs, I recommend having them reviewed by a separate team. Perhaps consider bringing in a 3rd party team specifically for these reviews. The cost of a second opinion is a small price of insurance to pay to protect against the implementation of a horrible design.

Cost played a large factor in choosing which outside firm to bring in

Business units & the IT teams that support them are under constant pressure to spend money wisely, and reduce expenses where they can. After spending potentially very large sums on money an a BPMS product, the thought of spending more piles of money on external consultants can be a hard pill to swallow. Sometimes these pressures cause staffing decisions to be a matter of cost. This can be fatal. Cheaper hourly rates do not necessarily mean cheaper long-term costs, especially in the scenario where you end up paying high-priced experts to come in and fight the fires in the event of a disaster. I’m not saying lower costs resources cannot be found that can do a good job, I’m just saying that it’s less likely, especially in a market such as BPMS implementations right now, and that the old magnums “You get what you pay for” and “Let the Buyer Beware” are in full effect. If you are choosing to go with lower cost service providers, ensure you do your due diligence to understand what the full expertise level of what you are buying is — and everyone you ask will tell you they are experts — you need to find this answer out externally, or via carefully designed interview processes and/or POCs

Implementation schedule was often rushed/aggressive

I’m not sure this needs much explanation, because so often this is the norm rather than the exception. The biggest problem I have with this is that it just amplifies potential issues. There’s less time to review for quality, less time to ensure the right solution is being implemented for long term success, less time to take a step back and see that something doesn’t look right, and — even if you do notice something is wrong, I’ve heard of project managers moving forward with the poor design anyway because they refuse to jeopardize the dates that were previously promised. This only exacerbates the problems in the long run. Agile and iterative methodologies are great when done correctly, but speed means nothing if you don’t do it right!

Vendor/Product guardrails weren’t properly followed

They’re called guardrails for a reason! If your consultants are actively advocating for designs that downplay or break the guardrails, that’s a warning sign. I’ve yet to come across an application that I needed to design a solution that significantly broke guardrails. Even in the instances when I did need to design outside of or bend the guardrails it was done in a very surgically targeted fashion, for a very specific purpose.

Client employees may bring concerns/risks/issues to light, but backed down easily when the consultants reassured them

Again, clients are pretty good at knowing what they don’t know, and knowing what they know pretty well too. If it feels funny and just doesn’t seem right, it probably isn’t. I’ve had clients who brought their concerns up to the previous consultants on multiple occasions and let themselves be satisfied with lengthy elaborate explanations that just confused them, so they let it go. Consultants hone their communication skills and messaging framing mechanisms to a fine art. Communication is a necessary skill for consultants, however, some become great bullshit artists! Remember: consultants are there to serve you, the client, and if something doesn’t feel right to you, don’t just give up at the first sign of resistance.

Recap on helpful practices to avoid this sort of disaster:

  • Like with doctors, sometimes a second expert opinion can be a lifesaver. Bring in multiple firms to work together if you can.
  • Design reviews should be done by someone(s) other than who did the design. That’s why it’s a review! These people should be your top experts in the product.
  • You get what you pay for, and design is not a place to skimp. Production support, small enhancements maybe, but please not on your whole design!
  • Take the time to do it right where you can. Lesser experienced teams sometimes take disastrous shortcuts when under pressure.
  • Follow the guardrails given by the product vendor, deviate from them only as rare exceptions, not for the basis of your design!
  • If it walks, talks, and looks like a duck. It’s a duck. Don’t let someone convince you it’s a swan!

If you or your team might be in need of a second opinion for a BPMS design review, or other services, let’s talk and see if I can be of any assistance!