I was in a meeting recently in which some great ideas were presented. The ideas would result in a number of improvements which would benefit the company and the users, and they were all pretty easy to implement. However, the ideas weren’t product features … they were changes to behavior. While I wholeheartedly agreed with what was being proposed, I didn’t LIKE the ideas because they meant that I’d have to change.

I’m a creature of habit. I get into a routine and like to stay there. So, even though I could see the benefits these changes would bring, I felt myself digging my heels in to argue against the ideas. My reaction was emotional, not rational … but it was also typical. I could feel myself resisting the changes even while I thought they were the right thing to do. Based on that recognition of the benefits to the changes (along with the obvious frustration my boss was feeling with my comments), I knew that I needed to find a way to embrace the ideas. But how?

I realized that I knew the “what” of the situation, but not the “why”. It was easy to understand what the changes were and how they would be helpful. What I didn’t know was why we needed to make a change. I didn’t understand the background, the context, or the situation that had led to the need for the change. So I asked. And, as is most often the case, there was a good reason for the changes. They HAD been well thought out, and they WERE good solutions to the problem. And once I understood the need, my attitude changed.

I talked with my boss about my reaction after the meeting. She suggested a great way to understand my reaction. She said that I was the developer, and the presenter was the Requirements Engineer. I understood what was being asked for, but I didn’t understand why. The RE didn’t set the context, and I didn’t ask for it (at first). The RE knew why the ideas he presented were good ones (they met the business objectives), but I didn’t. It was only after I knew the business objectives and how the requirements supported them that I felt good about the changes. I also felt like a part of the team which was solving the overall problem, not just an interchangeable resource performing a task.

Remember that any change, whether it’s to an existing system or to someone’s behavior, is difficult. Use your RE skills and experience to help yourself and others accept and support changes by providing them with the right information. When you do, you’ll make the change easier and more effective for everyone involved … and you may even come to love change, too!