~ by Randy Wagner

The Chasm Between the IT World and the Business Side

All of us have worked on project efforts where business identifies a need, Business Analysts (BAs) document the functionality, and QA tests precisely to spec, only to have the business say that doesn’t work the way I need it to.  Often, that’s not a single point of failure.  Everyone in the chain is doing their best to identify and configure the requested workflow but that’s often not enough.  There is a chasm between the IT world and the business side which can be summed up in a single word – context.

Why Asking “Why” a User Requirement is Needed Drives More Efficient Solutions

Context matters in so much of our lives.  Understanding why someone makes a choice is often as important as knowing what choice they made. My wife is in the Army, and she always requests a kosher MRE, the field meals for soldiers.  She’s not doing it for any religious reason.  Most of the MREs are tough to digest but the kosher meals come with tuna, which she finds much more palatable. In the case of user requirements, the “why” drives solutions far more efficiently than the “what.”

Context Helps IT Design a Better System and QA to Test it Appropriately

One of the great challenges projects face is finding technically capable staff who also understand the industry.  For example, a policy holder may have multiple vehicles on a single policy, but not multiple polices on a single vehicle.  That’s an insight that’s so obvious to a business user that it does not require statement and probably will never make it into a requirement. That context is valuable to everyone in the sequence.  The BA needs it to document properly. The Dev needs it to better design a system that’s rigid and flexible in the right places.  QA needs it to test appropriately.

Context Helps Determine the Importance and Relevance of a Requirement

In another example of context, if a client only writes a given coverage a handful of times a year, depth of testing on it may not be as valuable as on another coverage that’s selected thousands of times.  Many is the time I’ve heard, “Well, yes, that’s technically a possibility, but we just don’t write policies that way.”  Which brings us to the fact that context is company specific as well.  One shop may get seven workers’ comp claims a year while another does that in a minute.

Question Why a User Needs a Particular Feature in the New System vs Why It Was Needed in the Existing System

Per the MRE example above, the BA not only has to ferret out what a user wants but why they want it.  It may be a historical pain that won’t even exist in the new or updated system.  There is also the greater challenge of understanding context as business uses the system now vs how the system will be used with the proposed changes in effect.  This affects both business and IT resources.  Many a production defect is written because a given function is used differently than it was built for.

Educate Technical Staff with Basic Business Context

Context isn’t free. It’s too often hard-won. Years and projects go into understanding why logic is written a certain way.  But it doesn’t have to be that way.  Basic business education for your technical staff is incredibly valuable.  They may not remember all the details, but it may ring a bell that they have to look twice at something before blindly following a requirement.  Having members of the technical team shadowing various business users provides a wealth of insight on how a system is used and why changes are needed.

Reduce Rework and Improve UAT Experiences with Context

Context speaks not just to getting to the best solution. It’s also about efficiency on multiple levels.  Less rework for requirements and development saves money.  More accurate testing finds more relevant defects.  User experiences in UAT are likely to be better in a system where the team understood the issues that are important to the business, which then translates into better user acceptance companywide.  Context fills the chasm.

Randy Wagner is Director of Quality Assurance for CastleBay Companies. He has 20 years of consulting experience across private and public sectors, Guidewire InsuranceSuite, InsuranceNow, and Duck Creek, with specializations in quality assurance, configuration management, and automation.