 |
| Image courtesy of sheelamohan at FreeDigitalPhotos.net |
One of the key components of Change Management is Effective Communication. As with many leadership examples, without Effective Communication in a project, the chances of failure increase exponentially. After all, you can have the most fantastic plan in the world, however, if you don't let the team know about it, then the whole project will fail.
During the presentation, I shared an event that nearly cost me a project (and probably my job). I was working as a Subject Matter Expert (SME) for a Package associated with a new software implementation. My job included the initial Map/Gap interviews, output planning, system settings/configuration, and then training of the personnel in the newly configured system.
I arrived at the facility and began the process. I interviewed the middle managers and some of the more experienced team members. I went through reports, inputs and outputs, defined the issues that they wanted resolved, and tried to identify areas that could make things easier. I even organized several presentations with the middle managers and their teams to ensure I was heading in the right direction.
However, there was 1 key player missing: the Director. An accomplished professional, whose been with the company for decades, and had a very abrasive personality. The plan was to win over the middle managers and then use their support to win him over for the transition. Here's the hang-up: I never got him into the room until just before go live.
The Director constantly pushed me off to his middle managers, and I made two assumptions:
1. They were keeping him in the loop.
2. Because he was in the loop (see assumption 1) he would approve the decisions made by the middle managers.
Now, in a previous post, I provided an answer to Assumptions.
 |
| http://www.motivationals.org/demotivational-posters-17270 |
He walked into the room 10 minutes after training started, and sat in the back of the room. He asked three questions, which I answered with what the middle managers had approved. He stood up and left the room, showing some aggravation. This began the downhill slide.
Instead of receiving support from the middle managers, they took the Director's lead and started telling him that I had arbitrarily made the decisions and defined the system. They insisted that they were never kept in the loop, and that I never asked if he was being informed.
Now, when the Director left, he went straight back to his office and called the CIO, who called the Program Manager (two levels up from me). The training was cancelled (before I even left the building that was holding the training) and I was called back to the main office in order to determine a path forward.
Thankfully, I kept meticulous minutes of meetings, as well as extensive email traffic backing up my side of the story. I could show where the middle managers agreed to requirements and lay-outs, and how they stated that the Director was in the loop. I also had emails showing the Director telling me to go with what the middle managers wanted. I wasn't out of a job.
However, I was still in trouble, because this Director had extensive connections in the company and is somebody you don't walk up to and say: "You're Wrong!", at least not if you still want to work with the company. I was told to step aside and provide a supporting role, as the Program Manager and CIO met with the Director in an effort to calm things down and establish a path forward, as the software implementation still needed to happen.
After a tense week, a path forward was established, with a different SME taking the lead. My minutes of meeting and email traffic saved my job, but were not used in the meetings with the Director or the middle managers. The Program Manager decided I could take the hit in order to keep the Direector and his team happy. A new schedule was established and dedicated progress meetings with the Director were established. My reputation took a hit, as well as my ability to work with that team; but the process moved forward.
Now for the lessons:
1. The assumptions listed above. I had counted on the support of middle management, but instead they ran wherever the Director stated as soon as his (potential) opinion was known. I couldn't count on them to be champions for the cause, nor to keep the Director in the loop.
How often have you worked with someone who you expect to work with you, but instead is only there to please his/her boss, regardless of what is agreed upon? Now, I had the minutes of meeting and email traffic, but that wasn't enough because:
2. I sent the minutes of meeting to the people that were involved in the meeting, as well as to my boss, and several other people involved in the project; but not to the Director. I knew he would be a difficult point, and instead of coaxing him along through the process I decided it would be easier to present him with a finished product, championed by the middle managers (see lesson 1). If I had sent the minutes, email chains, etc. to him, then he would have less chance to argue that everything we prepared was wrong or a surprise to him.
3. I didn't inform my boss about the lack of commitment with the Director. I thought that with the middle-managers buy-in and the process nearly complete (again see assumptions and lesson 1), that he would be happy that he didn't waste time worrying about the implementation (especially since he sent several emails telling me to do what the middle-mangers wanted). The impact to him was minimal, as he would barely touch the system. The key (in my mind) was to interact with the people actually using the system. That was a mistake.
Secondly, If I had told my boss or the Program Manager that I was being blown-off, they may have supported me and helped organize meetings with the Director, rather than letting me take a hit... but that brings me to the third point:
3. Don't hang your people out to dry. In a previous entry, I discussed Fixing The Problem, Not The Blame.
 |
| Image courtesy of Ambro at FreeDigitalPhotos.net |
I had the notes, minutes, emails, and a well thought-out plan, with the features requested by the actual end-users. The system was in End-User Trials and ready to be released. We could have kept the original go-live date and then used an iterative cycle to adjust any systems that were causing problems. Instead, we almost scrapped several months of work to avoid conflict, and pushed back the schedule. Sometimes you shouldn't avoid conflict. Avoiding conflict can slow down schedules and cost money, if not handled quickly and resolved.
The vindication was after re-doing the map-gap and getting buy-in from the Director, the decisions made by the middle managers (which I implemented) were left largely alone. We didn't have to start from scratch. Of course, the new SME was the hero, as far as anyone was concerned.
Overall, this was a giant learning experience from me. Effective Communication is key to completing a project. Communication with all the stakeholders, especially ones that have enough clout to cause significant headaches (i.e. the Director), as well as with your boss/client, in order to avoid the moments that can cause you to take a hit. Worse, my mistake could have taken out the project. In addition, it taught me a lot about reading people, and ensuring that they are doing what they say they are. I also re-learned about the importance of documenting everything, because without that I may have been out of a job. Not one of my brighter points in life, but one worth having, if for no other reason than the lessons learned.
So, what conflicts are you avoiding? Are there key players in your project who are out of the loop? Finally, do you touch base with your people often enough to ensure that they don't fall into this trap either? Avoid my pitfall, and use EFFECTIVE COMMUNICATION.
No comments:
Post a Comment