One Formula for Successful "Workflow" Software Implementation
(Shakespeare ÷ Pareto − Nirvana) + Oil × People = Success

As firms look to make operational improvements, they are (sensibly) investigating various workflow solutions as part of a wider business process review or a transformation initiative. The problem with the word “workflow” is that it means different things to different people.

Workflow software can be complicated. But then so too are the business processes it aims to streamline. Once the decision is made that workflow is the solution, what often then gets forgotten is the specific business objective for wanting it initially. And the reason this happens is there is an overwhelming (and totally understandable) desire to get a one-size-fits-all piece of tech that will solve all of the firm’s BPM or workflow needs. This can be dangerous in reality.

Don’t Sacrifice “Good” for “Perfect” (Shakespeare)

This is a phrase that has been around in many guises for many centuries. Shakespeare offered what sounds today like a slightly impenetrable version in at least two of his works: striving to better, oft we mar what’s well. The widely accepted interpretation of a more modern version (that perfect is the enemy of good) is that you might never actually complete a task [workflow IT project] if you’ve decided not to stop (or even start) until it is perfect.

There are countless examples of firms where, in a quest for achieving “workflow perfection,” the opposite has unfolded—money and time has been spent but it has not been truly adopted to anywhere near the levels originally planned (or hoped).

Consider the following quote:

“Please don’t tell my team it’s entirely configurable. All we’ll do is spend six months debating it, then ultimately we’ll build our politics into a very complicated workflow and then never use it...”

- Director of IT, Top 50 law firm

While only achieving “good” might sound unappealing initially, if “perfect” is unachievable, then good is definitely better than failure.

The 80:20 Principle (÷ Pareto)

This principle (Pareto Principle) has been twisted a few times over the years, but the central premise is helpful here. 80% of results will be achieved from 20% of effort. In this context, getting something operational that satisfies 80% of your requirements is eminently achievable.

Trying to then get something that truly satisfies the remaining 20% of your needs will then consume the entire remaining 80% of your collective efforts (and budget).

In today’s world where maintaining genuine momentum for any transformational IT project is already tough (and is getting tougher), the question is whether it is a good use of your (and your teams’) time for the balance of 20%. It is much better to focus on what core business problem you are aiming to solve and deploy your energy there for a quicker (and more resounding) win. The disproportionately large amount of energy then needed to satisfy the remaining elements can instead now be ploughed into your next 80:20 project.

This principle gives you critical speed of delivery. A workflow tool that is fit for its purpose will be delivered significantly faster than a generic one that tries to do everything. If you want to demonstrate results quickly, stay focused.

Interestingly the Pareto Principle is often used when talking about which features in any particular product actually get used regularly and deliver value (although in fairness for workflow this might even be 90:10). Have that front of mind when choosing a relevant piece of workflow software.

Be Realistic (- Nirvana)

The nirvana fallacy is the delusion of comparing actual things (reality) with unrealistic (idealised) alternatives. It can also refer to the tendency to assume that there is a perfect solution to a particular problem.

So what does that mean in this context? The nirvana fallacy response to the above would be: “why would we want to implement a solution that only fixes some of our issues, we will still have other issues that will remain broken”. The flip side to that sentiment is that it will fix your more pressing and prioritized issues, and the remainder will never be fixed anyway (for the reasons given above).

And in the Real World?

It all stems back to the initial business reason for wanting software in the first place. It is not technology the firm wants; it’s the benefits that follow. Once you focus on this, you can ensure you can find and deliver a solution that fixes it and is fit for purpose.

• Do you want to improve the process of getting internal technical issues directed in a trackable way to your service desk?
• Do you need to delegate administrative tasks quickly to the right resource for immediate action?
• Do you want to streamline the onboarding process for new starters?
• Do you want to initiate client or matter inception in the timeliest fashion?
• Do you want to prevent phishing emails requesting payments reaching your finance director?

The answer might well be yes to all of the above but prioritize and separate them. Are there technologies out there that will (theoretically) do all of those? Arguably yes.

Will you have (realistically) investigated, piloted, negotiated, procured, configured, implemented, trained, and embedded into working practice in any meaningful timeframe? Probably not.

Is there a way to prioritize and deliver 80% of what you specifically need as a firm immediately (for each one) so you can take on the next project before your entire project team disappears into trying to deliver that remaining 20%? Almost certainly.

Data is Critical (+ Oil)

The other advantage of taking a fit-for purpose solution is that you get out-of-the-box dashboards and reporting benefits. Again, with generic workflow solutions these are difficult to produce.

In today’s world having access to live, real-time operational data is increasingly imperative (data is the new oil).

Spending a huge amount of time and money to implement a solution that does not give you the information you need to make sensible business decisions does not sound like a sensible business decision.

And Anyway, It’s Not All About the Tech (x People)

One thing we already know, and continue to talk to customers about is that, while the technology is critical (stability, usability, reliability), success from workflow projects incorporates a broader set of components: understanding, great communication, proper user engagement, senior sponsorship, and adoption.

The technology has to be seen as the enabler. But it is not the entire solution. So, with one final nod to Pareto, we reckon it’s 80% people and 20% technology. Don’t get stuck on the intricacies of the latter or you will be in danger of sacrificing good in the vain pursuit of perfection…

“Yes we already use other workflow solutions but the decision to use BigHand Now was driven by a few things:

Firstly, our PAs were already using BigHand, and it certainly didn’t make sense to have two systems (which would negate any value from the resource management tool in BigHand).

The second big feature of the decision was the BigHand resource management tool which comes out of the box, unlike our other workflow provider.

The final (but very significant) benefit was that configuring BigHand forms was so easy that our PA management could do it themselves. This meant we could get new forms (and therefore services) up and running very quickly. We didn’t have to recruit IT scripters (which is needed for other workflow tools) nor spend thousands with third parties to create the forms for us.”

Nathan Hayes, IT Director, Osborne Clarke