Shakespeare and Software Bugs : Align Business Consulting

Shakespeare and Software Bugs

By John Lietsch on August 7, 2013 in IT

What’s in a name? It is nor hand, nor foot, nor arm, nor face nor any other part. That which we call a Software Bug by any other name would smell as sweet.

Actually, calling a Software Bug by any other name might actually “smell sweeter.” As with Shakespeare’s Montagues and Capulets, the name Software Bug (“BUG”) carries with it a certain weight and referring to all software implementation issues as “bugs” can create an unnecessary and often dangerous association eroding one of the most delicate but critical success factors of any implementation – user confidence. User confidence must be managed, monitored and even babied from project initiation through post-launch stabilization. In this case, the answer to the question of “what’s in a name” is simple: “EVERYTHING!”

“BUG” invariably leads to “BUGGY” and BUGGY can wreak havoc on the confidence of any user base. Throw in social media to optimize the spread of information, correct or otherwise, and it doesn’t take a rocket scientist to figure out that the impact can be real, immediate, devastating and often unnecessary.

And that’s when a majority of the damage is done. It’s the proverbial “digging yourself into a deeper hole” and the pressure is very real. Teams feel that if they don’t act they will lose credibility; however, the mere act of “doing something” can validate the lack of confidence resulting in a very expensive and destructive cycle. Before long the project team is managing changes at an alarming rate resulting in increased stress, increased costs, timeline delays and, in the worst cases, project abandonment (significant write offs).

The success of software implementation projects revolves around expectations and confidence. Sure, there are hundreds of other things that need to be managed but the loss of confidence in either the software or the implementation team can be absolutely disastrous. In organizational terms, managing this emotional component might be considered part of OCM (Organizational Change Management) and there are proven OCM strategies that can help; however, we’re suggesting a small, mindset change to make pre and post launch expectations management easier. And it boils down to Shakespeare’s, “what’s in a name.”

BUG!

Implementation teams track issues, risks, changes, key decisions and a host of other important bits of information. And more often than not, issues reported during pre and post-launch testing or training activities are reported as bugs simply because the implementation involves software – The Infamous Bug Report! But software is only one component of an implementation and though it may be the primary component, other components are involved – think business process changes, business policy changes, changes in the organizational structure, third party changes, etc. In other words, just because there’s a problem during a software implementation doesn’t mean that it’s a BUG, as in a software error or flaw!

It sounds minor but we strongly urge our clients to use words that do not assign or suggest blame. In the case of software, we’ve always felt comfortable using the term Unexpected Behavior (UB) to acknowledge an issue but to communicate that we don’t know its root cause. Ironically, we have found that in most cases “actual” software bugs don’t account for a majority of the issues, especially post-launch.

Our recommendation: “Deny thy father, and refuse thy name”…alright, don’t do as Juliet suggests to Romeo…just use something other than BUG!!! Feel free to use UB or US (Unexpected Surprise) or UE (Unexpected Event) or, as suggested by one of our clients, UFO (Unidentified Funky Occurrence). Use whatever you want but don’t use BUG for every unexpected behavior reported to your team during a software implementation project. Software implementations are hard enough; don’t make them harder.

And, by the way, a BUG by any other name might be a…

Data Error (Conversion Error)
Reporting Error
Key Decision (Business Policy/Procedure Change)
Testing Error
The Chart Topping WAD Error (Working As Designed)
User Interface Error
Integration Error
Hardware Error (Hardware vs. Software, The War to end all Wars!)
Setup/Configuration Error
Software Bug
You get the point!!!

Success requires doing. We help companies DO.
Continued success…

About the author

John Lietsch

John Lietsch is a Strategy & Operations Executive with a history of successfully bridging the gap between leadership vision and disciplined execution. He has designed, managed or advised on critical, business and IT initiatives for organizations ranging in size from start-ups to global companies with annual sales in excess of five hundred million dollars. John specializes on the needs of growing organizations across a broad range of industries but has spent most of his career in Direct Selling, Information Technology and Professional Services. John has an MBA from the UCLA Anderson School of Management and a Bachelor of Science Degree from California State Polytechnic University Pomona (Cal Poly Pomona).

We transform vision into reality.