by Kent McDonald

I recently caught up with a friend of mine who I had not talked to in quite a while. While we were catching up, he told me that he had recently changed jobs and that while he really liked his new one, the switch was not his choice. I asked him what happened, and he proceeded to tell me quite a tale of the impact of leadership (or its lack) on a project and a team.

My friend had been working on a project to deliver new functionality for his former employer's customer service system. The new functionality had been a big selling point for a couple of new customers that were scheduled to implement the software in the fourth quarter of last year. My friend's team had worked out a realistic plan to deliver the new update a couple of weeks before the scheduled implementation date.

Two months before the scheduled delivery date, two of the functionality team's most experienced team members were reassigned to work on revising the company's CRM product, which had been losing market share in a shrinking market. My friend pointed out to his manager that losing access to those two team members and their skills would set back the project by about two months. As a result, the new functionality promised to their customers would not be available until a month and a half after the scheduled implementation date. His manager's response was the equivalent of a shrug: her boss said the other project was a higher priority and there wasn't much she could do.

Undaunted, my friend pulled the team together and they talked about their options. When they had originally planned the project they had worked with the Product Manager to prioritize the features involved in the upgrade, with the features most important to the new clients assigned a higher priority. The team had originally planned to release all of the functionality at the same time, to reduce the impact to their customers, but they worked out a way to do two releases instead. The first one, containing the functionality desired by the new customers, would be available three weeks after the original delivery date, just a week after the scheduled implementation date. The remaining functionality would come in a second release three weeks later. So far, so good.

Early on, my friend had established an agreement with the Product Manager that he could communicate directly with the key customers to get feedback on features and to keep them apprised of progress. So, in accordance with that agreement, he notified the key customers that staffing delays had impacted the project schedule, but that they had worked out a plan that would impact their implementation time by only a week. Naturally, he copied the product manager and his own manager on the message, just to make sure everyone was in the loop.

The next day, my friend's manager stopped by his desk to talk about the project. At the end of their conversation, she remarked, "Oh, and about that update you sent out about the customer service system yesterday? I would not have sent that email." She left his office without any further explanation. My friend puzzled over that comment for a few minutes, then brushed it off and got back to working with his team to meet their new schedule.

Over the next few weeks, my friend noticed that his manager seemed to be ignoring him, except when she would stop by his desk to ask for progress reports and berate him to speed up the pace.

This continued until about two weeks before the planned delivery date, at which point my friend's manager called him into a conference room. He was a little concerned about the abrupt scheduling of the meeting, and his concerns were realized when his manager told him that he was being fired. When my friend asked why, his manager simply said he "had not been displaying the type of judgment expected of project managers at the company."

My friend was stunned. He hadn't received any feedback that his manager was unhappy with the job he was doing, and the only feedback that neared any sort of "coaching" was the offhanded comment about not sending the update about the Customer Service System project. He ended up taking a couple of weeks off, and then found a great job at another company.

As he told his story, it became apparent that my friend had in fact been fired because a lack of judgment; not his own, but his manager's. First, there was the removal of team members from a project that was contributing to increased business for the company to one that was best described as throwing good money after bad. A more appropriate response would have been to weigh the relative impact of the two projects on the overall outcome of the organization and make a resource allocation decision accordingly. An even better decision would have been to keep the team members focused on the customer service system upgrade and either pull additional team members from other projects, or bring in consultants to work on the CRM project -- or ask whether the CRM project should be continued at all.

Next, the manager's reluctance to provide my friend any help or support in dealing with the removal of two key team members is also a sign of poor leadership. Project managers should not go to their leader with a problem and expect a solution, but they should at least be able to identify problems and potential solutions and expect some assistance, support, or actionable feedback. My friend ended up coming up with a solution, but it is remarkable to me that he had the fortitude to do it given his manager's defeatist attitude.

Finally, the lack of feedback my friend received leading up to the end of his job is a final sign of poor leadership. It is difficult to know for sure if you are doing a good job if the only feedback you ever receive is "I wouldn't have done that" followed a couple of weeks later by a pink slip. This is the ultimate example of ignoring problems in the hope that they will go away, rather than coaching people so that they could improve their performance.

In the long run, my friend is in a much better position now than he was at his former company. He realizes that he ran into a situation where politics and poor leadership combined to lead to some fairly dysfunctional behaviors and to an unplanned two-week vacation without pay. Looking back, he says he wouldn't do anything different, but going forward, he is going to pay a lot closer attention to the politics that may be going on around him and his project, and be a lot more selective about what opportunities he takes and what leaders he works for.

Comments

My first reaction to this was to question why he did not go immediately back to his manager and ask for further clarification on the "I would not have sent that email" comment. It may not have saved him his job but certainly could have shed more light on his manager's perspective.

While I fully agree with all the shortcomings pointed out in respect to the manager in this situation, I hope that this PM eventually realized why that email was inappropriate. Being given approval to communicate directly with customers about features and progress should not be considered permission to air the company's dirty laundry to an important customer. The message that the project was falling behind because another project was considered "more important" should not have been delivered cold to an external client without prior knowledge of the manager, and likely, several others in the organization. I'm sure some VP or Director received a blindside call asking some pretty pointed and uncomfortable questions. Clearly, the manager should have explained this to the PM.

Good story of a pretty common scenario in traditional corporate organizations. There is a broader lesson on the importance of communication both up and down the ladder. Up is more difficult but equally important as pointed out by the story. It was easier and more natural for the project leader to communicate with his team because that's the environment he came from, probably demonstrating his leadership and communication skills as a team member before being promoted to team leader. As team leader, he continued regular, almost peer to peer, communications with the team because it was natural. The Program Manager was excluded from similar regular communications on project status, progress or delay. Her attitude reflected the feeling of exclusion which broke the chain of communication even wider. Without fresh knowledge or involvement in the project, it's difficult to defend or support project resources enthusiastically or effectively with other managers. Business communications are equally important in both directions for any project success. Oh yeah, I learned the lesson the hard way.

I can't agree with Jodie on the e-mail being inappropriate, as it sounds like more was read into the message delivered to the customer than what was stated above.... "he notified the key customers that staffing delays had impacted the project schedule" doesn't sound like he was airing any dirty laundry to me. It seemed "well stated" with a somewhat positive spin to me. I feel that he had fulfilled his PMI Professional Conduct obligations very well by informing all stakeholders (accurately and without delay) of the changing situation, regardless of how well the information would be received, or how poorly it might reflect on his PM skills.

This whole message definitely sounded more to me like a situation of a manager feeling like they were bypassed; that they would have rather waited until the CS project was late and then make some lame excuse (if any) to the customer. Maybe it would have been at that point that your friend would have been let go due to "inability to deliver" - either way he would have been a scapegoat for ineffective management.

Maybe a variation would have improved matters (and maybe this is what Jodie was implying): Communicate the proposed plan to all internal stakeholders before communicating it to the customer.

As PMs we are supposed to be given the authority and responsibility to manage the project within certain limits as defined by the Proj Mgmt Plan and to communicate as defined by our Communications Mgmt Plan therein. Did he violate those plans? We don't really need to know at this point. :)

But, he is definitely better off by getting away from an organization (or manager) which is that incapable of true leadership and ethics.

Worth reading..

As a freshly minted PM this article is a good reminder of potential career limiting minefields you can walk into rather easily if you don't have your radar set on which folks to watch out for.

I agree fully Bob the more open the communication channels are the better for all involved , NO Stakeholder is left in the dark , and leads to everyone knowing what is going on with the Project , which minimizes the risks.

As a customer or the ultimate system owner, depending on the length of a usual project, a one and a half month of delays does not seems too long to me. If all remedies have been exhausted and the genuine and unforeseen project rescheduling must be considered, the next best thing is obviously to bring it to the customer, in the best ever tactful manner of course. These days, no one on earth could really guarantee a plan would definitely arrive at the destination on time. However, I don't see e-mail as a form of most sincere gesture in apologizing a mistake, more so when it has not been endorsed by the company's top or higher leadership.