Beware bad blood between project managers and users If you look up professionalism in the dictionary, you’ll find my picture right next to the definition. That being said, there are still situations that push patience and professionalism to the limit.I work as a business process analyst, and I’ve been with the same company for several years. Not long after I started, I found myself caught in a tough situation. I’d just been transferred to a new department — one that had been supported by another BPA named Steve. Steve was overtasked; well, we were all overtasked, but he seemed unable to handle the pool of users he was responsible for supporting.My first project was to implement a simple application for a group of users who needed specialized reporting capabilities. Due to resource constraints (read: Steve’s lack of time management skills), this project had been on a back burner for more than six months. The requirements were still undefined and undocumented; Steve hadn’t even assigned development resources. The first time I walked into a meeting with the project stakeholders, I saw right away that they were totally out of patience with IT — and as far as they were concerned, IT was me. Even though I made it clear that I would be moving forward at full throttle on their project, they remained demanding, difficult, and uncompromising. In addition to dropping the names of various honchos in upper management who were their personal pals, they were constantly reminding me, “If this project isn’t done fast, heads will roll.” I had to bite my tongue the time someone told me, “We did IT a favor by not just hiring an outside consultant to implement this system for us.” On several occasions I found myself struggling to keep from snapping back that threatening my job was no way to boost productivity and that in no way did I consider this project a plum assignment.Nevertheless, I knew why they were angry, so I tried to listen to their concerns and get them what they needed. I even went out of my way to “overcommunicate” (if there is such a thing) and I provided plenty of documentation. During the course of the project, I felt that I was earning back their trust.As our working relationship improved, my “clients” let me know that they would not have been nearly as frustrated had there been any previous communication regarding the status of their project. As far as they were concerned, it had been sitting in an “IT black hole” for six months. This story does not have a fairy-tale ending. Although I finally did get these users what they needed, my dealings with them are still essentially adversarial. They walk into every request meeting in full offensive mode. The bad experience with Steve virtually destroyed the possibility of my creating a partnership approach to projects for this group. What took six months to ruin could take a lifetime to repair.I sometimes wonder why people, especially the customer-facing ones, in the IT profession forget that they belong to a service organization. Users are customers, and as much as they frustrate and confound us, good customer service must find its way into daily support activities. The lesson: Communicate, communicate, communicate. Then communicate some more. Software DevelopmentTechnology Industry