Appendix A: Bonus Skill: Managing Wafflers
This appendix considers one of the most difficult challenges that Business Analysts will encounter during the process of delivering software development projects. It is those moments when project actors, more specifically end users and stakeholders, cannot make up their minds as to what to expect from a software product whose development a Business Analyst has been assigned to oversee. Let’s consider the waffle in a little more detail.
One of the most insidious aspects of the Business Analyst line of work is encountering what I refer to as the waffle or waffling. In the world of business, it is known as indecision.
Simply put, to waffle is to “fail to make up one’s mind.” To flip-flop, vacillate, and equivocate are fancier ways of saying you are waffling. While I have heard waffling also referred to as “stalling,” the two are different though related activities.
Going forward I will refer to those who waffle as wafflers. The idea is not to apply the word “wafflers” as a derogatory term but to illustrate the dynamics of the waffle. For our purposes, the waffling referred to here is the type indulged in by end users, stakeholders, and a host of other project actors.
Waffling or
indecision
is one of those aspects of the Business Analyst practice that stymies even the most battle-hardened Business Analysts mainly because of the haphazard way it manifests. Your assignment may be on schedule, but for some reason, critical decisions don’t come in time or they come late, or you need to wrangle them out of people. There are information gaps or decision gaps, and you are unsure whether you are dealing with just minor operational gaps or black holes. In extreme cases the critical decisions do not come at all, eventually leading to the assignment or project being pulled.
This is what makes waffling so dangerous to assignments or projects. As a modus operandi, waffling is largely impervious to technical skills or jargon and to effectively nullify the waffle, a Business Analyst requires more people smarts than technical gifts.
Essentially the waffler makes a decision one moment and then just as quickly reverses it the next. Like a pendulum the waffler will swing between different positions at any given time. Grantedsome
sort of decisions are being made, but they are constantly in flux. It’s apt to refer to them aspseudo
-decisions. They are decisions when the waffler wants them to be decisions. They eventually become decisions when the issue is forced by an external factor like a looming hard stop or nonnegotiable deadline.
Having encountered wafflers on multiple software development projects, I can now tell inside a few meetings that I have a waffler “situation” on my hands. Obviously, being a waffler is not a capital offense, but waffling on a time-boxed project or assignment ought to be legislated as a crime of sorts. This is because a resource who cannot make up their mind is stealing your time and everyone else’s time, not to mention the project’s time. There is also a more critical reason why you should be concerned with the waffler’s antics that are freezing your progress: they are stalling the project delivery process.
But first, the anatomy of a typical waffle.
User A determines that they need changes made to an application, process, or system. You, the Business Analyst, and User A agree on the changes—which is referred to as the scope of work. You and another actor we shall refer to as Actor A deliver the changes initially requested by User A. This is usually done by showing User A the prototype that represents the changes that have been made. User A partially approves the prototype and requests you to make more changes to some aspects of the prototype.
Just to be clear, I am not against such changes, and a few changes here and there are acceptable; that is the point of using iterative software development methodologies like Agile. Urgent changes can be made to software, processes, or systems in real time to reflect current marketplace conditions. To repeat, it’s perfectly acceptable for end users like User A to request urgent changes to prototypes before they are launched.
But what happens if User A is in the habit of requesting changes every time you demonstrate the prototype? I have been on software development projects where User A types literally request changesevery time
you engage them. What they requested last week is unimportant, and they have a new fad today that they would like you to work on right now. They have a bucket list of never-ending change requests that they spring on you every time you present the previous phase’s work.
Shockingly sometimes the requested changes are the changes that were initially made, initially rejected, and are now back in vogue again. This is the essence of the waffler and the act of waffling. Countless times, with frustration getting the better of me, I have wanted to tell stakeholders, “please make up your mind!” The changes range from the subtle to the minor to the major, but ultimately, they still hold up progress and impede closure of the project or assignment. Not to mention how adversely these antics impact project financials and timelines with none other than you having to answer for the unsightly mess that the project will soon become.
The
tinkering waffler
is merely one type. Another type of waffler is a stakeholder who will not commit toany
one decision. They are always consulting, or they are “busy.” When you do get a decision, there is a caveat: the team or their manager may change that same decision anytime. This is an especially painful type of waffling for Business Analysts because they rely on this input from stakeholders to do their work. Without this input, they might as well stay home. I clearly recall the times when I was “waiting for a decision” for the umpteenth time, and I have never felt as inept as I did in those moments.
Did I mention project financials and timelines? Wafflers act like these things are for lesser mortals to worry about. Wafflers inhabit a parallel universe where the impacts arising from unlimited change requests do not concern them.
This may sound like fiction, but wafflers are real, and they are out there wrecking projects even as I write this. In times of raging angst brought on by wafflers, I always wondered why anyone or wafflers for that matter would work this way. It stresses out everyone involved with the project, and in the very short term, nobody looks forward to working with the waffler. The waffler’s credibility and reputation—if they have one—take a serious beating.
Reasons for Waffling
Different wafflers have different reasons for waffling, but there are some general reasons why people choose to waffle should the opportunity present itself. In no particular order, these are some reasons that give rise to waffling.
Minimal Domain Knowledge
In lay terms, it is the
knowledge
or expertise you possess about a given subject or field. Your expertise about a subject does not have to be advanced, but you should possess enough expertise to logically explain the need and the potential impacts if your request goes unfulfilled.
To my mind this is one of the main drivers of waffling. The waffler does not have adequate knowledge of what they seek to change. Due to knowledge gaps (which the waffler dares not to admit to), anybody working with a waffler will be stuck in an endless loop of back and forth. A painful guessing game whose objective is to figure out an end point or destination. In reality, the waffle is merely a smokescreen for existing knowledge gaps on the waffler’s part.
If the waffler worked smarter, this would be a non-issue. I have seen other folks who had the same knowledge gaps but simply brought along a more knowledgeable sidekick to do the heavy
lifting
.
Managerial Vacuums
In an ideal
world
, our managers would want to know why we are still chasing the same assignment three months after we committed to close it.
More importantly they would want to know what we are doing to correct this messy state of affairs. That’s why they are managers, and that’s what they are paid to do. This ideal world does not apply to the waffler as they can chase the same assignment—making a tweak here and there—with no serious repercussions from their manager. From the outside it appears the waffler has minimal managerial direction, guidance, leadership, or all three.
It need not be mentioned that in the absence of managerial guidance, this vacuum will be quickly supplanted by the waffler and his/her waffling ways. And while we are not always privy to managerial supervision of subordinates, the presence of waffling and the chasing of regurgitated, fluffy, never-ending assignments are usually signs of ineffective managerial
oversight
.
Managerial Incoherence
Does your
manager
inspire such confidence in you that you go over and above to get stuff done for them? Ditto the process and systems you work with. Conversely, does your manager induce murderous thoughts just by thinking about them? I know that feeling. I have been there in a previous life.
A manager or process or system that is stultifying, that is an absolute kill joy; who wants to stake a reputation on them? Think of the last time your manager asked you to do something at 9:09am and changed it at 9:22am without any reason or they provided a fudgy reason at best (of the dog ate my homework type).
What if those types of changes were being made every week or with such regularity that you were left dazed by the changes? How would you respond the next time your manager or whoever makes these changes asked you to defend them before a review board? There is no certainty that the position you just defended will still be in place by the time you made your closing pitch. I know how I would feel. I would want to donothing
.
I would vacillate between different positions until I knew where my manager stood. That is of course until his/her next flip-flop. If the decision came down to either saving my abused reputation or saving project financials, I think you know who would get thrown under the bus. Project financials be damned.
A waffler in this situation is in a catch-22 situation. They are in an unwinnable situation and just trying to do the best that will save their hide. This is one of those instances where I fully root for the
waffler
.
Buying Time
Sometimes the waffle exists because the waffler is
buying time
. They understand they have a knowledge gap, so they jam the wheels of progress as they get a handle on the material they ought to be articulating to other project actors like Business Analysts.
Is it an expensive way to learn anything? You bet. But it works for the waffler. While I understand this type of waffler, for at least there is an admission that they have knowledge gaps that need to be closed, I find waffling as a remedy distasteful.
Motivations for Change
Wafflers in this situation come in two
flavors
. The first type loathes and distrusts the process and systems so intensely that they will doanything
to change them or eradicate them. Anything. If that means making multiple requests in 30 days, so be it. They couldn’t care less who dies in the process much less care for project financials.
In reality this type of constant tinkering and tweaking if focused will likely produce positive outcomes. It’s just that it’s a massive headache if you are on the receiving end of all those never-ending change requests. The second type stopped caring last year and does not really care what happens to the assignment. They change things on a whim confident that they will not have to handle the future fallout from their shabby decisions today.
How Business Analysts Can Manage Wafflers
But how do you inoculate yourself against wafflers and their mayhem? It depends on your situation, but there are a few surefire ways to manage wafflers. These items have worked wonders for me in the past, and you may want to give them a test drive.
Create and Use Guardrails
Guardrails
on roads and car seatbelts are put in place to save us from ourselves, like when we drive above the speed limit while simultaneously texting and having breakfast.
In the same vein, you need guardrails to keep you away from the worst impulses of wafflers and their handlers. Here’s what guardrails would look like:
- 1.
An iterative software development methodology like Agile can mitigate this mayhem if you stick to it the way it was designed. Essentially the waffler cannot change the scope of work at will.
There has to be a time and process to review and process new work requests. Lock down this process and follow it to the letter. Even better, let the wafflers know that this is how it will work. If they stray, beat them into line (not literally).
- 2.
Tolerate the waffler once and they will be back for more. Just like schoolyard bullies. Let it be known that while you are willing to be flexible, there will be limits. And that flexibility has to bend to the law of the land—see point 1 above. This mitigation strategy is largely down to you and what principles you are willing to espouse and defend.
- 3.
Don’t play this game solo. Anytime you are up against a waffler, expect progress challenges of some sort at some point. Mitigate this by drawing in other stakeholders to this slow-motion train wreck. The stakeholders do not have to do the chasing for you; you are only making them aware of the likely consequences based on the current trajectory. For example, critical deadlines will be missed if this waffling continues
unchecked
.
Motivations for Waffling
When you
understand
where the waffler is coming from and more importantly why they are waffling, then there is no need to pull out clumps of your hair. Take the time to understand what type of waffler you are dealing with.
This knowledge is critical in devising remedies for the waffler. For instance, if it is knowledge gaps and assuming you know which knowledge gaps they have, you can tactfully fill in those gaps. Is that how they run their shop? Then it’s time to inform both the shop attendant and manager that their actions (or lack of) are sure to end in failure if they don’t change their ways.
