Here’s a scenario you might face as a business analyst. The head of the customer service team, we’ll call her Joy, has submitted a project proposal to get a new field added to the contract form in your customer management application. The new field is “number of units sold.” Joy has been criticized for the number of open contracts in the system and her reps aren’t sure if they should close the contracts or not, because there is no defined number of units to fill.
Being the insightful business analyst you are, you realize that this new field does not just impact the customer service team. You get Bob from accounting involved, as well as Samantha, the head of sales.
Bob is excited about the new field and wants it also included in a few of the reports the accounting team uses. Samantha is ambivalent, but insists it be optional and would prefer two fields instead of one. Joy absolutely insists on a single field and says it is required.
As you facilitate the requirements discussion, Samantha and Joy clash regarding what the feature should look like while Bob provides a slew of new feature ideas assuming one or the other version of the field exists. You don’t see any end to the back-and-forth debate, let alone the rabbit hole Bob is leading you down.
These types of conflicts are common, even in the smallest of business analysis projects. Typically the root cause goes back to any combination of the following three issues:
Process
The debate about the field (or feature) has ignored the process (or how and when data for the field will be collected and used). Joy most likely assumes the sales person will fill in this field. Samantha may have concerns about her salespeople providing accurate information. Looking at the end-to-end process for closing and fulfilling a contract could help everyone understand who collects this information, when it is finalized, and if and when it might change.
Terminology
The term contract may be deceptively simple and doesn’t necessarily have one defined meaning. Samantha’s perspective on a contract might be during the pre-sales negotiation period. Joy is probably thinking about a finalized contract her team needs to fulfill. Bob might be thinking about a contract that’s ready for invoicing. Asking everyone to share their interpretation of the term could lead to a more fruitful discussion.
Organizational Issues
Technology changes are almost always tied back to larger organizational issues, otherwise known as politics. Instead of going directly to sales and asking for the information her team needs to do its job, Joy proposes a required field. Samantha’s resistance is actually a very positive response. A less direct stakeholder would allow the field to be required and let their sales people put a ballpark number into the field, which might pacify Joy in the short-term but not solve the underlying problem.
Feature battles are rarely so much about the features themselves as they are about process, terminology, and politics. When you find your stakeholders disagreeing about features, drive the conversation backward to the underlying cause and you’ll be able to guide a much more productive and effective discussion.
