[Part 4 of a 5-part series of posts about ways of being while being a Business Analyst]
Oftentimes, we talk about issues related to software requirements as if the problem is technology-related. But given the time, money and priority to work on something, we can make technology do anything. Our problems stem from people more than they stem from technology.
We have a client with a process that is documented one way, but in the wild is never done like that. The systems supporting that documented process aren’t working for the ad hoc process, and thus, the system is blamed for being buggy, or lacking in functionality.
The problem was most likely that we accepted the first thing we got when we asked about the process (the documented version) and didn’t dig deeper. The management-level people were disconnected from the worker-bee-level realities, and didn’t have those worker bees at the table to tell them otherwise.
Which is not to say we were lied to — although sometimes that happens! — but instead to say we needed to hear from more voices. We needed to validate the information about How Things Are or How Things Need to Be with the people who are “living the pain” right now.
Change resistance isn’t typically because something is not technically feasible, it’s because of fear. Inflexibility isn’t typically about how a business works, it’s about distrust.
The more we listen to the people, the more likely we are to get closer to the primary source of the problem.