Let me pause here to acknowledge two things: 1) yes, I might be stating the obvious, 2) who am I to tell you that you need to be nice? I do assume you are nice, to get that out of the way.
However, I have noticed that as we do our thing in the corporate world, we are expected to radiate confidence, to act like we know what we're doing (particularly when we don't), to exude a feeling that we are the best damn thing since sliced bread, or at least Orange Julius. This, in theory, supposedly inspires trust in our customers and helps improve interactions with the truly arrogant. While that may be partially true, I think it also comes with the danger that we can inadvertently lapse into seeming arrogance or even apparent indifference to people's thoughts and feelings. (Note my qualifiers to indicate that this is appearance and not intent.)
How can I make such a claim? I believe I've been guilty of this.
After successfully implementing a robust requirements standards and processes at two companies, I felt as though I had this requirements thing 'sussed' out. In my next position, I picked up where I left off, assuming the new group would just naturally see the inherent value in the processes and definitions that had worked well elsewhere.
Instead, they wanted a requirements process that drew the line between requirements (the what) and design (the how) in a much different place, which I felt ventured too far into design and feared would preclude flexibility in design choices.
So, I did the wrong thing: the first set of requirements I delivered adhered to what I felt was the better balance, in alignment with what I had done at the previous two companies. Their predictable response was I didn't do what they had asked me to do, and I'd wasted their time.
They were my customers, too, and I should've operated from that perspective rather than what I chose, which lead me to directly contradicting their expressed wishes. I now wonder how much wasted time and energy I could've saved, for myself and everyone had I known then what I know now.
Yes, I ended up having to update requirements sets way more often than I would have otherwise (when a design choice was made that differed from the requirements), and that had the effect of cutting into my preparation for upcoming projects. But once I got past my stance that we "were doing it wrong," we worked together better. The efficiencies I traded off in process I largely gained back through smoother collaboration.
We can fall into these same traps with our customers for whom we create software. We often have experience with software packages and development projects that they do not.
We should strive to find that fine line between providing the benefit of our experience, yet allowing the customer to state their peace, if you will. If it is truly the wrong way to go, it will most likely bear itself out. In doing this, sometimes you have to re-walk a few paths you feel you've explored ad nauseum. Persevere with aplomb and a smile. You will almost always benefit if you can observe the advice from the (in) famous poem "Desiderata" - "listen to others, even the dull and the ignorant; they too have their story."
I have worked in a multitude of IT environments, from joyous start-ups where a fridge full of organic vitamin-packed juice blends is just one of the perks, to prim and professional monstrous cube hives churning out massive application suites, to bereft little teams on the edge of dissolution. (True story: as one company was shutting down, I heard someone return to their desk and lament to a customer: "I'm going to have to mail it to you. Apparently they laid off the fax machine, too.")
From these experiences, I feel it's safe to point out that while all organizations and departments within them have a few people who are not exactly warm, fluffy examples of humanity (I refer you to Robert Sutton's wonderful work for a more precise moniker for those people), Information Technology tends to have a higher percentage of those people, and occasionally I've encountered groups where that number approaches the majority. If you work with a socially-challenged group enough (whether it's just situational, like a company that's closing, or personality based, where the group just happens to include a lot of jerks), you can be "gas-lighted" into NOT perceiving their behavior as abhorrent, and, horrors, find you're doing it, too.
Try to ensure that all conversations you have leave everyone's dignity intact. Happy customers will go the extra distance to help everyone succeed. Conversely, if a customer leaves a meeting angry with IT, the Project Manager may as well slip the project at least a week.
In addition to the minefield of difficult personalities, other factors to keep in mind are customer's attitudes toward and experiences with software itself.
A lot of non-IT people are afraid of computers to some extent, particularly older customers who may at one point had to work on a glorious green-screen application where pressing a single key could create a cascade of catastrophe. Modern systems are usually much more forgiving, but they've also grown more complex, and they often haul off and do things you haven't asked them to do. (How many of you have had a software "Wizard" pop up for seemingly no reason with a bad guess about what you're trying to do?) Even my eldest daughter, who like most teens embraces and masters new technology like she was genetically engineered to do so, will occasionally call me over to her computer to ask me what in the heck is going on. Because of these experiences, some of our customers are ambivalent about computers and software, or worse.
A group that requests order fulfillment and billing software with an accounting package option isn't looking forward to using that software like the person who just downloaded "Angry Birds" or someone who has a Tweet they're just dying to share. You need to be especially sensitive to those customers for whom you're building a spinach application.
Do what you can to make their experience easy, intuitive, straightforward, and (heaven forbid) fun. One way I handled this was I used a hapless Wile E. Coyote-type user for a string of use cases delineating refund scenarios. Every one who read them made a personal trip to my desk to thank me for infusing some humor into what's typically a pretty dry read.
The ability to be kind, patient, attentive, respectful, and yes fun!, can make all the difference on a project. The only person you can force to do this is you. If the customer can at least look to you for a friendly face, it can mitigate much of the difficulty brought about by bad behavior that you have no influence over, or the drudgery of defining the business rules for returning broken merchandise without a receipt that requires a managerial override and three signed copies of a return verification during the graveyard shift, on a holiday.
I believe you'll find that over the long run, you'll be generally more content, too. Lauren Frey Daisley recently embarked on a personal experiment where she said nothing snarky for an entire month ("My Month of No Snark," Salon.com, 03/28/2011), and here's her conclusion:
"Kindness doesn't have to imply repression. It doesn't rein in humor or impede the fight for justice. But it does require discipline and substantive engagement with others.
"If you disagree, feel free to say so in a considerate manner. Or just keep it to yourself."
Don't forget to leave your comments below.
Timothy Hanson has been a Business Analyst, A.K.A. Software Requirements Analyst, for nearly two decades. His experience encompasses both the private and public sectors. He received his CBAP certification in 2008. He currently resides in Colorado, USA.
Comments