I have always felt that when you are assigned a project as the project manager, you stop being an employee. Yes, you still look out for your company’s interests, but you take on the client’s interests as well.
Table of Contents
- Tough Conversation 1
- Tough Conversation 2
After all the client came to your company as one that not only could deliver the objective expectation but to generally take care of the client company, for example anticipating potential problems and alerting the appropriate people and developing actions that can protect the client from loss.
Taking project ownership leads to tough talks where the PM may have to forget management titles and organizational hierarchy in order to deliver a project. Not only must the project manager be eagerly willing to take on these challenges, having these potentially unpleasant discussions, but they should have well-established conflict resolution skills. I once told a client that it was my job to protect him from himself. It easy for a customer to make a decision that may ruin contrary to the project objective or otherwise increase the risk or difficulty in achieving that objective. I take this work on, this is “MY” project.
That brings me to the first tough talk. On occasion the PM and management, either at their company or the client, will disagree on some aspect, business or project related. Management’s response may be to add scope, change direction, or executed at the executive (or sponsor) level, and the PM is unaware of this behind the scenes discussions and actions.
Ideally, this event happens to the project manager only once in a project. Upon the PM becoming aware of these backroom discussions and decisions that impact the project, they should take action to insert themselves into these discussions now and in the future. let’s just call them changes, the PM needs to address the issue with the initiator. Not in an aggressive manner; but directly and with persistence, and record the results, especially if the response is not sufficient to address the potential problems.
Such a conversation might go as follows:
PM: Manager, you assigned me to deliver this project and now there are some issues that have come to my attention. There are some changes that are occurring that I was not aware of and have not approved. My understanding of my role as PM is that I am responsible for the project budget. Therefore, I need to be aware of potential expenses that will hit that budget, to understand how this expense fits into the overall project budget. You want this project to come in at or under budget, right? Did I misunderstand my role?
Manager: These are business decisions based upon our company internals as well as discussions with this customer and other potential clients.
PM: So, how do we resolve the current issues? I would like to know the scope of the issues and be involved in any future discussions that impact my project and product as well as be a part of any corrective actions or root cause analysis event the company undertakes in this regard.
Manager: Are your challenging me? You do know you work for me.
PM: Not challenging you. Again, as the PM I understand I own the project at this moment. Or do you want someone else, such as yourself to be responsible for the project, the cost, schedule, and delivering to the expectations of the customer?
(A PM has to be ready for being replaced. In addition, the PM is putting their reputation on the line and if continues as PM on this particular project, needs to deliver. Also, the PM should not be thinking beyond this project. Taking a stand of ownership may cost a promotion or possibly the job once the project is delivered.)
Manager: No, you are the PM.
This next example has many variations and many failure modes when it comes to estimates. A recent discussion with a colleague about project estimates could be an interesting example. In this case, a project manager provides an estimate generated from the team. The estimate is presented and management pushes back, why are the estimates too high? This in spite of the fact that the estimate is born from the lowest of a collection of the previous set of similar projects, with a further percentage reduction. These types of interactions are one example of why some people push for no estimates.
Manager: The testing estimate is too long. It has to be cut by 75%.
PM: Okay, I will discuss the estimate with the Quality/Testing Department. I will discuss the estimate with the department manager and work with them to clarify any opportunities to shorten. I will get back to you in two days. To be clear though, is there the possibility of scope change to make this possible? What sort of risks are you or the customer willing to take to get such a reduction of the estimates? What are you willing to sacrifice to reduce the cost?
A discussion with the project team and it is deemed the Testing Estimate is appropriate based on scope and assumptions.
PM to Manager: The Testing department is pretty firm on their numbers and does not feel comfortable with reducing their number. Are their items in the scope you wish to remove?
Manager: No, I don’t want to remove anything, just get the estimate down by 75%!
PM: The Testing department is firm and you are likewise firm, how do you want this resolved? Can the estimate be reduced by 75%, and the project actually is delivered to the full cost as presented at the moment? In other words, the estimates will not match the actual, and the actual significantly exceeding the estimated budget for the project?
(This may take several discussions to resolve and a new Testing Execution plan may need to be developed, or a contingency budget may need to be set up.)
Having to initiate and in some cases forcing tough conversations may result in a PM being labeled ‘hard to work with’ or ‘bull-in-a-china-shop’ or ‘bossy’.
All project managers at one time or another, maybe not on every project, has to take a stand about owning a project and challenging those in power that are taking actions contrary to the successful conclusion of the project.
Owning is a big responsibility, one that can lead to frustration. The PM has to be ready to know when to assert themselves and decide how to approach the cause of the risk and subsequent frustration. The reason this was titled Tough Conversations is not that the PM has to be tough. It is because it can be overwhelming and “tough” to have to engage a company president, vice president, or the boss for what is best for the project, the client, and the company. The inability to have these conversations will lead to the illusion that things are running smoothly, but it is only an illusion. Considering a different perspective, if a project team member is not engaged in the project and able to deliver, every PM would quickly address the deficiency.
This is no different just because the team member is an executive. People with titles are stakeholders/team members of the project and as with other stakeholders/team members should accept the PM’s leadership.