Take business systems, for example. Among the most overused analogies in the world of business systems analysis is the one comparing the visibility of system requirements to that of the proverbial iceberg. Like icebergs tips, system requirements are only 10% visible, look benign on the surface and yet can spell doom for the unprepared that approach them. Inevitably, further comparisons between designing a system based on those requirements and the fate of the Titanic follow, but then again, clichés are clichés for a reason. Allow me to take the analogy a step further: like icebergs, complex business systems are held together by an internal arrangement of stresses in dynamic equilibrium and the slightest pressure, incorrectly applied, on any one side can fracture the entire system. Workplace relationships, part of the organizational culture, play the part of these stresses in a business process.
An often ignored side-effect of system automation is how it influences these relationships. Automation eliminates some jobs by way of consolidation of business functions, and other users have to take up some of the resultant slack. Sometimes, entire levels of functionality are consolidated into higher levels. Not all additional responsibilities are accompanied by corresponding increases in compensation, especially during economic downturns. Consequently, levels of employee satisfaction and relationships are affected.
At the workplace, relationships build up over time and establish hierarchies among users who may otherwise be equal in rank or pay, and users with greater decision making power may be loath to give it up because it no longer lets them be in a position of relative power. Technological challenges, especially for older workers who were too used to doing things a certain way, influence relationships too. Eventually these relationships, over time, extend to outside the workspace. It is easier for people with similar functions or responsibilities to socialize and form friendships, and when we alter job functions, or worse, remove responsibilities and/or decision making capabilities, it further affects how users react to change.
The better you can maintain existing relationships, or provide acceptable substitutes, the greater your system's chances of being adopted. Over the years, extensive research has demonstrated the effect workplace relationships have on productivity and employee satisfaction, both crucial factors in organizational performance.
No user will ever tell a BA the real reason for resisting change. Some users resist change if they see no immediate personal benefit they also tend to discourage others and long entrenched relationships determined their influence. Others welcome it and then they work to encourage. As analysts, when we seek to automate a system, we unwittingly apply pressures to such long entrenched relationships. That is one of the toughest jobs for a good analyst, how do you maintain the relationships between the users of the system, outside of the system, while changing the system itself? I mean changing, not automation, it would be naive to assume that simply automating the system does not affect it otherwise.
This is not an argument for designing automation to maintain the status quo in most systems, I am trying to emphasize that most systems consist of subsystems disturbing one disturbs all. Consequently users' are reluctant to adopt new systems, with familiar results. So, recognizing that your shiny new system's chances of survival depend a lot on the users still liking each other, here are 5 things to keep in mind.
- Earn your users' trust. Ensure that every user believes in your commitment for them to keep or improve their station in the system's hierarchy. Recognize that relationships are not really unique; like systems are, to organizations. Even standard office systems will differ ever so slightly among organizations but people, generally, are the same. They tend to be protective of their turf, resistant to change and may not always see the big picture. Consequently, addressing these issues head-on and showing that you are doing so, goes a long way toward resolving them. Resistance to change is more from uncertainty over the future than from satisfaction with existing systems. Part of that uncertainly comes from not knowing if they will still be what they were, besides doing what they did, in the new system.
- Use tradeoffs. Try to never take anything away without giving something in return. This is a particularly difficult objective to achieve. More often than not, you will not have anything to offer in return for what you are taking away. The best you can do is to focus on the effect that change has on the entire system and the ultimate benefit from accepting it. Being seen as having management support is crucial. If required, consult with their superior to see if anything can be done. Sometimes, even lateral movement for marginal users will work.
- Be careful while shadowing. Shadowing leads to people telling you how they should be doing things and not how they really do them. That leads to automating a system that should have existed, instead of one that does. Instead, observe, and try to be unobtrusive. In addition, try to get perspective from other users. Asking 3 users "how the system works" gives you a better idea of how it does instead of asking each user what they do. That is one of the best ways to understand relationships.
- Take opinions and read between the lines. Both during requirements gathering and while getting validating system design, ask the users what they think. Many users see these interchanges as a way to express their personal ideas about what is going on but have to be careful of how they say it. Also, if they like what they see in your system, it is very important that they hear themselves say it, your system's chances of survival have just increased. When they say they like the new system, they are really saying that they like their position within it. This means that you are doing something right to maintain relationships.
- Observe, Observe and Observe. At workshops, observe interplay between the participants. Observe everything, from where each chooses to sit, who takes a lead in the conversation, who is deferred to for making decisions, and get an idea of the hierarchy that exists. Pay as much attention to how people talk as you do to what they say.
Remember, a system is only as good enough as the users who use it. How they use it is defined to a large extent by how they feel using it. How they feel is influenced by where they see themselves in the system and part of that depends on their relationships with their coworkers. A good business analyst is part creative thinker, part visionary. Creating the least disruption to existing relationships between users while designing a system goes a long way toward success.
Berman, West and Richter. March/April 2002. Workplace Relations: Friendship patterns and consequences (According to Managers). Public Administration Review.
Don't forget to leave your comments below
Vardhan Mulik is a software consultant living in Virginia Beach, VA. He has served as President on the Hampton Roads Chapter of PMI and is currently involved as a volunteer in establishing the DC chapter of IIBA. He is actively looking to establish a local chapter of the IIBA, in the Hampton Roads area.