July 202019MANUFACTURING TECHNOLOGY INSIGHTSRegardless of the nature of the change, there is almost always someone that can benefit from the information. I've yet to see an organization or even a person that "over communicates". I have seen plenty of poorly constructed communication that was so long and verbose it left me wondering what the actual message was. But at the end of the day, that's just poor communication.Good communications shouldn't be restricted to break-fix and other problems. Anything that is changing should prompt a communication of some sort to those impacted by the change. Rolling out a new version of software; let the team that uses it know! Upgrading some systems that will take down some servers for a while; let the team know! Even if you're doing this over a weekend and "no one ever works on the weekends", let them know. This could be the one weekend someone decided to pull some numbers for a new sales presentation and now IT gets a black eye because the systems are never up when they need them! One of the best ways to ensure communication occurs is to make it part of the Change Control process. Who needs to know?The best thing about being in IT and improving your communication is that the expectations aren't really all that high which means the journey to being a much better communicator can be relatively short. So to the question "Who needs to know?" ask yourself the follow up, "What do they need to know?" The message should relatively short and to the point. And most importantly, it should be composed with proper context to the audience. I expect most of your customers or associates in your company do not care about ANY of the technical details or issues that caused the problem or might be changing. For issues and problems, let them know the current state and any next actions. If something is changing, in addition to the "what", let them know what's in it for them. A brief explanation of how will they or the company will benefit is always helpful. And if the situation around the change is new or different, let them know that too. Statements that are direct, simple, and contain as little technical information as possible are always best. We recently had a situation where a ticket came in asking IT to grant system access to an associate who was taking over for someone leaving the company. The ticket was received by the appropriate team, assigned to a technician, and then closed a couple hours later. The next day the manager of that team emailed me asking if I could escalate the ticket. What? The ticket is closed. Upon some investigation I found that the access had indeed been granted, but as the technician closed the ticket, he neglected to contact the impacted party (Who needs to know?). Nor did he inform them that the access he had provided required a system reboot (What do they need to know?). By not answering those two very simple questions, the technician turned a positive into a somewhat negative situation.Good communication doesn't take much time nor does it usually require much effort. In fact, comparing the effort of communicating to that of solving some of the incredibly difficult problems presented to IT, it is probably the easiest thing IT ever gets to do. My advice to you is simple ­ next time you're hip deep in a situation that requires you to change something, take a few seconds to ask yourself "Who needs to know?" Gary UptonGood communication doesn't take much time nor does it usually require much effort. Next time you're hip deep in a situation that requires you to change something, take a few seconds to ask yourself "Who needs to know?
< Page 9 | Page 11 >