I have to admit, I hate horror movies. I’m the person who covers her eyes and waits until the scary parts have passed before I can watch again. If you’re hosting a Halloween party featuring a “Friday the 13th”movie marathon, don’t bother to invite me. Not gonna happen. Nuh-uh, no way, no how.
Being a BA on a project can sometimes feel like you’re caught in a horror movie. Everything is going along just fine, and then, suddenly…NO! NO! DON’T GO IN THE SHOWER!!! RUN!!! HIDE!!!
Unfortunately, on projects we don’t have the option to cover our eyes and wait for things to get better. And there are no teams of superheroes waiting to swoop in and save the day for us. Here are some things I’ve heard that can strike fear into the heart of the most intrepid BA. In honor of the Halloween season, I call them “Phrases to Fear”.
"That'll Never Happen."
You’re being stalked by: A risk that may need to be identified and analyzed.
Vanquish this demon by engaging in some “What If” analysis. It can be challenging to get stakeholders to identify risks, particularly if the likelihood is low. It’s not likely that our VOIP system will go down…. but what if it does? How will we respond? What can we do, and how will we recover?
"While you’re in there…”
Circling closer and closer in the dark is: Scope creep!
Take this monster out with a one-two punch.
The first way to defend against scope creep is to have a clear, well-understood scope definition. If you’ve taken Essential Skills you can review your materials for some great techniques that will help you clarify the scope of your project.
The second line of defense against scope creep is a solid procedure for managing change requests. Have a procedure, and stick to it like glue. I have always maintained that if someone doesn’t want a change badly enough to document their request and submit it for review, then they don’t want it badly enough. A few small changes here and there can add up to large amounts of additional effort, potentially without much additional benefit to the business.
"We know exactly what you need to do.” And its evil twin,
“We already bought the software, we just need you to implement it.”
You’re about to be ambushed by: A solution that may or may not solve your problem.
Turn around and confront this attacker. It’s time to proactively go after some objectives and a solid set of business requirements. Once you understand why the request has been made and what is needed to address it, you can evaluate the proposed solution.
Even if the solution is set in stone, you can develop objectives and stakeholder requirements to do gap analysis. Once you’ve identified the gaps that will be left by the solution, you can develop a plan of attack for plugging the holes.
"Oh, by the way…”
Sneaking up on you from behind is: An undocumented assumption.
“By the way…I’m sure you know this…but when we’re done implementing this at the facility in New York, we want to expand it to our other plants…”
Wait…what? Where did that one come from?
There are obviously some assumptions hiding in the dark corners of your project. It’s important to elicit assumptions, because if our assumptions turn out to be wrong, we may need to revisit the decisions we’ve made on our project.
"It’s just a small change….how hard can it be?"
This innocent-looking creature is about to turn into: Way more work than anyone expected!
It starts out as a simple little change….and the next thing you know, this tiny little change has shape-shifted into a monstrous, multi-limbed demon that has invaded every corner of your requirements. That extra field your users want to add to a screen – who knew that it was going to require so many other changes, and impact so many downstream systems?
Arm yourself with traceability matrices or other tools for tracing requirements. These support better impact analysis, which in turn helps us understand the true size of the request.
Once you understand the true nature of this beast, it’s important to re-examine your priorities. Make sure that the value of the request is being considered as the team thinks about where this change fits in.
"I trust you."
A seemingly friendly monster but hiding behind this mask is: A disengaged stakeholder.
A student shared this phrase with me. Her stakeholders said, “You understand our business. Just go write up some requirements for us – we don’t need to look at them or review them, because we trust you.”
What her stakeholders were really saying was, “We don’t want to take the time to work with you. So go off and do the best you can, but don’t bother us because we’re busy.” If this happens to you, it’s time to work on engaging your stakeholders. Check out our Quick Tips for Improving Stakeholder Engagement for ideas.
"They’re all high priority."
Zombie apocalypse!
Many stakeholders believe that requirements have to be identified as “high” priority in order to be included in a solution. They’ve learned the hard way that anything listed as “medium” or “low” will often end up getting cut out as the project moves forward.
You may have to try different approaches to prioritization if this happens to you. You can develop evaluation criteria, and score requirements against them. Collaborative games like “Buy a Feature” or Planning Poker can get reluctant stakeholders to participate in prioritization. Decision Filters can also be used to quickly sift through requirements, eliminating ones that don’t support key objectives.
Keep an eye out for phrases like these that make you shake in your shoes! And remember to leave the light on… just in case…
All the best,
Kathy
Editor’s Note: This blog post was has been previously published by B2T on our previous website. Due to its popularity, Kathy has updated its content to be more comprehensive and accurate for the state of today’s environment.
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
