~ by Randy Wagner
Why Project Assumptions Must be Evaluated
Trying to understand the world we live in is as old as humanity itself, but it is often much too easy to rely on what we think we know rather than to honestly evaluate what is in front of us. Whether you do carpentry, run an automotive assembly line, or deliver insurance software, it is important to begin tasks from a “known good” starting point. In a discussion with a colleague or a spouse, sometimes we don’t just come up with the wrong answer, we started wrong. From requirement gathering to root cause analysis or even a sales pitch to a new client, taking a step back and evaluating what assumptions we are carrying into the situation can significantly influence success.
Bias Can Drive Task Management Down the Wrong Path
Assumptions are the biggest challenge. They are a shortcut to life and we really couldn’t survive without them. When we think about the schedule for the next day, we start with assumptions such as we will be feeling well enough to do things, the car will run, and on and on. However, we are easily blinded to their existence. The simple bias of wanting something to be a certain way can drive how we manage tasks. I want my code to be right so it’s easy to think slowness is coming from the network and not how I wrote my query. I’m short on time so I want my test environment to be solid. The problem is that being wrong can be very costly. It costs time, missed opportunities, and money.
Keys to Ensuring that Your Assumptions are Valid
So how do we get a little perspective? At a project level, setting entry and exit criteria that include minimum thresholds helps set objective hurdles.
Document Expectations Before You Begin
Is the system ready for UAT? Well, do we still have Severity 1 defects? Have we completed a full validation of the code, integrations, and connectivity in the environment? Have the users been trained, and test plans defined? Spelling out these expectations before we get there, helps remove assumptions from the process and build from a known good. Like in carpentry and assembly line production, starting each step with quality will consistently yield better results. In truth, all outputs are the raw materials of another process so start with quality to avoid the garbage in, garbage out model.
Rely on Metrics and Facts
This leads us to metrics. Sometimes the easiest way to blow up preconceived ideas is to look at the numbers. It may feel like the claims system is where all the problems are but reviewing the defect metrics may show that claims have more defects written but they are mostly low severity while the billing system has fewer but much more significant problems.
Leverage Error Logs for Root Cause
Vectors into where the truth lies are often at our fingertips if we look. We usually look at an on-screen error and try to deduce the problem, but it may be much more productive to start with the error logs that would show the warnings or non-visible errors that happen prior steps back that appeared successful. We may not be starting our root cause analysis from a known good position. Error logs also help prevent us from jumping to the conclusion that we fixed a defect just because an error stopped happening this time.
Take Time to Find the “Known Good”
As human beings, it can be difficult to differentiate what is true from what we believe or want to be true. Questionable beginnings can only deliver questionable deliverables. A true known good is something you can build on. Assessing what we know to be accurate often requires questioning our beliefs and finding the known good is a good investment.
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.