Making emotional conversation unemotional
Project managers are routinely faced with dilemmas, such as sponsors mandating unreachable dates, teams unable to give reliable estimates, changing priorities and scope, and a myriad of other issues. The reactions to these issues generally range from utter frustration to apathy. The reactions then lead to emotional conversations such as “We can’t possibly do this by then!” or “The Sponsor doesn’t understand!” I will show you how, from my personal experience, to take these emotionally charged situations and turn them into unemotional conversations. This will not be the latest fad or psychology, but a simple, time-tested, experience-based method to communicate with the entire project team from the stakeholders to the team members. I will share techniques on how to deal with mandated dates to the extremely tense post negotiation of a project gone very wrong. The techniques will be applicable for internal project managers, consultants, and any level in between. How to turn emotional conversations into unemotional conversations has been what I believe is my personal key to success.
“Projects fail because of context, not content.” (Thomsett, 2002, p 37)
The above quote by Rob Thomsett creates a whole new thought process for project management. The new process focuses on the information delivered in projects versus the product delivered. If projects fail because of context, then the importance of being successful in project management is creating the proper context. The content itself is still always the focus of the project; however, the focus of the project manager should be on managing the expectations of the content.
Although theories are rampant and rapidly changing, a project’s success is still widely based on cost, schedule, and quality. There are many variations in measuring project success, but in almost all cases, the project planning process (or lack thereof) is still responsible for setting the success criteria. If you truly think about what constitutes a project as being late or over budget, it is your own baseline or an arbitrary number picked for you due to the lack of a baseline, which means that you, as a project manager, have more influence over project success than you think. This paper focuses on getting to the data of a situation and presenting them in an unemotional fact-based delivery. Presenting only the facts will allow the project manager to remain unemotional when dealing with the emotion projects can usually generate.
Getting the Data
First: Erase Your Doubts!
The most common reason that theories learned in books, seminars, or other learning opportunities is the lack of conviction to practice and put to use what is learned. Many project managers fail to implement needed changes to an environment because of fear, apathy, or the perception that whatever they are trying will never work. They often feel this way because of the theory or new technique requiring the buy-in of the entire project team or upper management to be successful. The theories discussed in this paper are practicing theories and have been used hundreds of times in many different company sizes, industries, and project management maturity levels. The key in each one of the successes was the focus of the project manager. Erase the doubts. Here is a brief list of the objections heard most often:
- “We don’t do that here.”
- “Our management won’t support that.”
- “We have always done it this way.”
- “That won’t work here.”
These are all common excuses. If you find yourself leaning toward one of these excuses already, then the real question is: Do you want to change? People often visit seminars and read papers to learn new techniques. You may have selected this one because you are searching for new ideas or there is a specific issue you are trying to resolve; however, most techniques are never tried or written off before they become effective. Making Emotional Conversations Unemotional contains proven applications of theory that can effect great change in an organization. It starts with you! If you doubt that you can change or that your culture will never change, you are probably right. Change will never occur if you doubt that it will. This paper is not a cure all or the magic elixir that will cure all corporate illnesses, but it is one that if used properly can bring a dose of reality back into the organization and allow project management practices to be followed.
As stated earlier, most projects are measured by a combination of factors, often consisting of cost, schedule, and quality; however, most of the measurement factors are decided prior to the project ever beginning. Most project managers are given a project that includes scope, budget, and an end date and this is all before the project itself is even planned! What is even more troubling is that the criteria were set with very broad stroke estimates. Let’s look at a typical project initiation cycle in the corporate environment today:
- An executive says, “I think this project can be done for US$100,000 and be completed by June.”
- The project budget is set at US$100,000 and the end date is 30 June.
- The project is assigned to a project manager.
- The project manager begins planning the project by announcing to the team, “The project needs to be complete by 30 June and we have a budget of US$100,000. Now, when do we think this will be done and how much will it cost?”
- The team inevitably chooses US$100,000 and an end date of 30 June.
The Reality of the Fallout
When a project manager announces to a team, “This project needs to be done by 30 June and we have a budget of US$100,000” do they think that their estimates are going to be realistic when they receive them from the team? They will most likely get the same answer in return. In fact, when it is stated like the above quote, it is almost a challenge to the team. Somewhere throughout the project, an estimated figure (US$100,000) became the project’s budget. The estimated timeframe (30 June became the committed date. The worst part of the scenario is: as soon as the project manager publishes a project plan showing 30 June and a budget of US$100,000, he or she is committing to it. If the project exceeds either of those figures, then the project and the project manager are perceived as failures.
As simple and absurd as this may sound, it is the reality of many project managers’ lives. The key to using proper project management techniques is getting back to real reality and ensuring that your plan reflects the same.
Getting Back to Reality
If a project manager is going to manage the context of a project, then it starts in the very beginning of the planning process. The mistake made by the project manager was announcing the date and budget to the team at the beginning of the process. As a project manager, it is very important not to reveal the “desired” date and budget; eventually, you will reveal the date and budget that the sponsor has requested, but it must be treated as a request. We would all like to march into a bank and demand a US$1 million loan at a .01% interest rate, payable over the next 750 months; however, this is not a realistic request. There are many factors to take into consideration: credit rating, current income, purpose of the loan, and so forth. Projects have similar constraints: availability of resources, current workload, other projects, and so forth. The interesting thing is that we often do not consider these factors in the planning process. The list that follows are the suggested steps you should take and there are detailed definitions in the next few sections:
1) After receiving the “desired” date and budget from the project sponsor, assemble the team for the planning meeting. Do not release the “desired” date or budget at this time. The first step is to standardize definitions.
2) Ask for the right information and let the plan “fall” into a date.
3) Compare the planned dates and budget with the “desired” dates and budget.
4) Work with the team to alleviate discrepancies.
5) Work with the sponsor with real information.
6) Publish the plan.
Step 1 – Standard Definitions
The first misinterpretation that comes from project estimation is the sentence, “How long will that take?” If you pose this question to ten different people, you will get ten different answers. A more experienced team member may pad his or her estimate with risk. A more eager team member may give a conservative answer. Some team members may include their current workload, some may not. This is a problem that can plague project estimations. To counter this, use the Program Evaluation and Review Technique (PERT). Even if you do not use the entire formula set, use the Best Case (BC), Most Likely (ML), and Worst Case (WC), which will at least allow you the opportunity to see where in the scale the estimate falls. This will enable you to normalize the estimates provided to you so that you can plan accordingly. Now, if you ask, “How long with that take?” the team member can give you a range of estimates. Then you can use either the formula for PERT (BC + [4*ML] + WC)/6 to help estimate or use your best judgment.
Make sure you define the word, “done.” As simple as this may sound, it is the core of great project management. When a team member announces that he or she is “done,” what does that mean? If it is a software development project, has he or she tested the code? Has he or she deployed it? Can you see it? Or, does it mean that he or she is done with the coding only and has to move on to the next step. Regardless of the meaning, make sure you know what it means, and you must also make sure that when the team member says “I’m done,” he or she knows what that means.
Step 2 – Let the Plan “Fall”
The importance of this step is the crux of the entire system. First, make sure that your team is talking about tasks and durations. You need to know the task, its predecessors, and how long the duration will take. It is acceptable to ask for how many hours and how long. For example, to create the database will take 40 hours, but because of the other constraints it will take three weeks to complete.
You must understand and invest the time to use a proper project planning tool. Whether you have the license for Microsoft Project or you need a free tool such as Open Workbench (downloadable at www.openworkbench.org), make sure you are using the tool properly. There are some simple rules to follow when creating a project plan:
RULE 1: All tasks except for the very first one should have a predecessor assigned.
REASON: You want your plan to be dynamic. If a task is late, how does it affect your plan? If a task is early, what should we work on? If you do not have your plan reacting dynamically, then you are losing the power of a scheduling tool.
ULE 2: Do not enter dates manually.
REASON: You want to use durations and relationships to control the schedule. You want to make sure that the scheduling tool is not setting a constraint type for you.
RULE 3: Define the durations.
REASON: When you enter a task in Microsoft Project, it will place a question mark in the duration column (1 Day?). Define the durations to ensure that you have the plan properly set up.
RULE 4: Always baseline your plan.
REASON: How do you know if you are ahead of or behind schedule? You compare it with the baseline. The baseline is nothing more than a line in the sand to establish a comparison for project statistics.
RULE 5: Update your plan regularly!
REASON: A plan is dynamic. You must update it to truly be managing a plan. Make sure there are no past due start or finish dates in the plan. Let your plan reflect reality. Many project managers are afraid to update their plan because this can “mess it up”; however, you need to make sure that the plan is updated and real. The uses for a real, updated plan are endless and will be discussed later in the paper.
The estimates have been normalized, the definitions of “done” have been decided, and you have let the plan “fall.” The date was not arbitrarily picked out of the air. It is a real date with true estimates, predecessors, and team buy-in. This is the first pass of what can be done. The next step is to compare that with the desired date.
Step 3 – Compare Planned versus Desired
The sponsor has given you a project with a “desired” date. At the conclusion of your planning process, you now have a first pass at a realistic date. You now compare this date with the desired date and begin to adjust accordingly. If the planned date is prior to the desired date, then you can move forward and use the difference in time as a risk barrier, or release some time back to the sponsor.
If the planned date is past the desired date, then you know the true difference in the planned versus the desired dates. It is now time to start talking to the team about their estimates and proceeding to step 4.
Step 4 – Plan Again
You have a realistic project plan and the date is past the desired date of the sponsor. It is now time to inspect the plan to ensure that it does reflect reality. The first pass plan was the desired plan of the project team. It is time to reveal the desired date of the sponsor to the team, but with a strong caveat. Do not allow the team to simply change its estimates. All you are doing in this step is qualifying and quantifying the information that you have in the plan. The question is not, “Can you do this faster?” The proper question is, “If we needed to complete this task faster, what would you need?” The answer could result in crashing or fast-tracking the plan; it could also result in the changing of a few priorities for the team member. In any case, you are starting to develop a list of options that could compress the schedule.
Once you have a list of options, you can then begin to enter those into the plan to see if they would bring the planned date closer or before the desired date. Remember that these are options. If you have followed step 2 properly, then you can see the impact of each option to the overall plan. Develop your different options and the results to the plan. What would you do to bring the date in? What is your primary suggestion?
At the conclusion of this step, you may have brought the date in compliance with the desired date or you may not have. The end result of the step is to ensure that your plan does in fact resemble reality and you have some quantified options to present to the sponsor.
Step 5 – Present to the Sponsor
Step 5 is extremely important and where the work completed so far will provide benefit. In this step, there are three main scenarios:
- Scenario 1 – The planned date is well before the desired date.
- Scenario 2 – The planned date meets the desired date.
- Scenario 3 – The planned date is after the desired date.
We will explore each of the scenarios.
Scenario 1 – This scenario is truly the best of both worlds. Your sponsor requested an end date of 30 June. In your planning with the team, you came up with a date of 30 April. Allowing some risk, you tell the sponsor that you believe that the project will be finished no later than 30 May. If you have already accounted for risk in the plan, you still may want to leave yourself some room for error. The best case is to give back some of the days to the sponsor.
Why not just publish the date of 30 June? The answer is, because your plan does not reflect it. The changes you are hoping to bring to the organization are faith and trust to the project planning process and these must work in both directions to be successful.
Scenario 2 –This is a great scenario. It shows that your sponsor and your team are on the same page.
Scenario 3 – Of course, this is the more difficult scenario. Your team planned the project and then re-planned it. You have looked for several options and have a list of the impacts to the project and it is time to present this to the sponsor. The key is that you are loaded with information and facts about the project. Where most project negotiations fail is that the responses appear to be weak and emotional; for instance, “We can’t possibly complete that by then!” or “The team is just too overworked!” Instead, your responses should be, “In order to complete this by the desired date, I need this,” or “If we can move these priorities, we believe that we can finish this by the desired date.”
The difference is that you are presenting options to your sponsor, not just issues. Phrases that include can’t, impossible, or overworked tend to tell the sponsor that he or she needs a new team or that he or she just needs focus. By following this process, you are telling the sponsor what can be done. If he or she does not believe you, you can walk him or her through the plan, show the impacts, exercise the options, and show how the plan changes. It becomes a collaborative environment and understanding on both sides can be gained.
In most cases, the sponsor will either accept a later date or approve some of the options. At that point, you can move on to step 6.
Of course, there are cases in which, even with this information; the sponsor can still be unreasonable and demand the desired date. There is not much that can be done other than to say that you and your team will do your best. This is not defeat because it was never about winning or losing, it was about developing context. You have shown the sponsor what the reality of the plan is and presented the options to fix it. The sponsor wants to ignore all the options and still demand a date. All you can do at this point is move forward, but there is one more thing that you can do that will protect you and your team. It is a simple thing and it is discussed in step 6.
Step 6 – Publish the Plan
As simple as step 6 is, it can carry quite a bit of weight. Step 6 is to publish the true plan. If scenario 1 or 2 occurred as outlined above, then it will be a simple publication. If scenario 3 occurred as outlined above, hopefully you have a reasonable sponsor and you can publish a plan that was a collaborative effort. Then, there is scenario 3 with an unreasonable sponsor.
The best way to handle this is to publish the plan as is. If the desired date is 30 June and your plan shows you finishing on 31 July, publish 31 July. You can even place a milestone task on 30 June and call it “Target Date,” but the plan is what it is. If the sponsor is irate, the statement that normally works is “We have the target date set as 30 June and we are going to do everything humanly possible to meet that date, but right now our plan is trending past that date, so I need to report what is happening.”
The sponsor can still demand you change the plan, but now, who is changing the context of the project, you or the sponsor? If you change the plan and move the date to 30 June and then publish, you have done two critical things. The first is that you have sent a message to the team that you do not believe in its estimates and you have undermined the planning process. The next time you ask the team, “How long with that take?” The likely reply will be, “Why don’t you tell us when we have to be done?” The second thing you have done is essentially lie. By arbitrarily moving a date to a desired date and then publishing it, you have lied about when the project can be done and committed to it by publishing it. If you publish a date supported by the plan and then the sponsor demands to change it, then the burden shifts to the sponsor, especially if the project actually completes on or before your published date and after the desired date. Was the project really late? Imagine the lessons learned meeting after that scenario!
This may sound aggressive to you, but there are many project managers out there who feel trapped. They are given impossible dates and then chastised when the impossible date is not met. This technique, over time, can improve that situation, because you will at least always have the first date you published. There are the situations in which even with all of the documentation in the world, you find yourself in the same situation. The question becomes then: Are you in the right organization?
Making Emotional Conversations Unemotional
The end result of all of the data collection and variance analysis this paper has led you through is to come to an understanding of the real data so that you can use them in real life to improve your projects. The data will point you to the issue and resolution. There is no magic or man behind a curtain. Data are what will rule all of the conversations you have about a project. Having good data can turn an emotional complaint from a team member into an unemotional fact-based conversation. Several conversations that normally have emotional connotations can, with the proper data, become unemotional discussions. Generally, these discussions revolve around mandated dates, issue resolution, and the over-utilization of the team.
A mandated date is normally the first source of emotional conversations. Project managers and team members can often be heard saying things like, “That can’t possibly be done by that date,” or “That date is impossible!” However, these comments are normally made to each other and not in front of the sponsor. If these comments are made to the sponsor, then they are usually greeted with disdain, giving the impression that the sponsor is unreasonable. The fact is that the person presenting the argument is not giving the sponsor a solution, they are merely complaining about an issue. The truth is that most mandated dates, as we’ve already discussed, are not really mandated. They are a convenient date or a date picked out of the air; the problem is that, unless challenged, they become the real date. However, when the project manager presents the argument that it simply can’t be done, there are rarely any true facts to support his or her position. Without the facts, the project manager sounds like the teacher on Charlie Brown, “Whaa wuh whaa wuh.” Essentially, the emotional conversation tells the sponsor that the project manager lacks the leadership skills to bring the project in on time. Using the facts can change the conversation
For example, Antoine was the project manager installing a project management system for a client. When Antoine received the project from his company, he was told that the project must be complete by 31 March. When he arrived on site, he heard the same message from all of the project team members: how unfair the date was and how unlikely it was that the team could meet 31 March. One team member remarked, “That’s what the sponsor wants, so we will just have to figure out a way to do it.” Already, the team was looking at what requirements it could remove from the project and how to downgrade the deliverables to fit into the mandated date. All of this occurred before Antoine could even start the planning process. When he went to start the project plan, the team was resistant because of the mandated date. Comments were made, such as, “We don’t have time to plan; we have to go forward to meet this date.” Antoine still insisted on getting the team together and planning the project. He asked the team if anyone had had a conversation with the sponsor to understand why the date of 31 March was so important, but the team had not. He instructed the team to plan the project without dates. He asked for tasks, durations, and predecessors and he did not want to hear any dates. When he collected all of the tasks, the date fell on 12 April. The team was again whipped into a frenzy of what to do. More meetings were held to discuss how the date could not be met, yet nobody had discussed this with the sponsor. Antoine wanted to hold a kick-off meeting and have a conversation with the entire team about the project end date.
Antoine opened the meeting with the general information about the project. About ten minutes into the meeting, he showed the planned date of 12 April. The conversation with the sponsor went like this:
Antoine (project manager): “I know that you’ve requested the date of 31 March for this product to go live, but right now the plan is showing 12 April. The team and I will do everything we can to hit the 31 March date. May I ask, what is the importance of 31 March?”
Sponsor (sponsor): “No importance. 31 March sounded good because it was the end of the quarter. 12 April is fine.”
Project Manager: “Alright, but as a team, we will do as much as we can to hit the 31 March date.”
Sponsor: “Fair enough.”
The team members were dumbfounded. They had easily each wasted three to four hour of their time dealing with what they thought had been a mandated date. In the end, the sponsor did come back to Antoine and state that he did want a full quarter’s worth of data in the system, so if the project went past 31 March, they needed to find a way to ensure the data were collected for entry. Antoine then had his contingency plan for missing 31 March. Once the burden of hitting what the team felt was an impossible date was removed, they actually finished on 24 March. The key to the conversation was the facts of the plan. Antoine did not disagree with the date; he simply showed the plan and discussed what the team felt they could do. Then, he asked how important the mandated date was. If the sponsor came back with a stern 31 March, then the team would have to deal with that. However, at least the date would then be qualified.
Having the facts on your side will reveal the truth without political ramifications. When emotions become involved is when major mistakes are made. Another example involves Carmen, a project manager who was leading a funds transfer between holding organizations. This is an extremely regulatory process that requires many checks and balances. Once the funds were moved between the organizations, an oversight was found. A regulatory fine was being handed out to the company. The company’s trustee was on a witch hunt. A team meeting was called during which the trustee blamed Carmen for the mistakes. There were many instances that Carmen could recall in which the trustee had been notified of or even approved the move of the funds. In any case, because Carmen did not have the facts readily available, she chose to wait until the end of the meeting, gather the appropriate facts, and then discuss them. The trustee continued to rant and rave and called for Carmen’s job due to the failure. After the team meeting concluded, Carmen went to her meeting notes repository and typed in the keywords she was looking for. She was presented with times, dates, and documentation of the conversations that she had recalled. Later that day, she was called into her boss’s office where the trustee was present. It was clear that the trustee was going to allow Carmen to take the fall for the regulatory fine. In a clear and unemotional way, Carmen relayed the facts of the meetings, notes, and results, as well as the distribution of the notes. What had really occurred was that the trustee was the one who authorized the movement of the funds, not Carmen. The end result was that the trustee lost his position. Unfortunately, this is a common occurrence. A project manager who is completely responsible for the project tends to find him- or herself in situations that could cost his or her position. In times of great opportunity come either great rewards or great peril. Had Carmen lost her temper in the meeting and become emotional as well, then relationships could have become strained; additionally, Carmen could have also stated errant information in the heat of the moment. The proper reactions are those of calm reserve and fact sharing. Had Carmen challenged the trustee openly and failed, then the end result would have been the loss of her job. Understanding that the unemotional telling of factual data will normally win disagreements, Carmen made the right move.
Using Data in Conflict Situations
We have previously discussed the “it is what it is” attitude. This becomes crucial when using data in conflict situations. The most common conflict stems from the negotiation for more time or a greater budget with a project sponsor. This is a common source of conflict because the dates and budgets are usually selected without proper project planning, which leads to unrealistic timeframes and expectations. Utilizing the data can assist during these sometimes tense situations. Usually, a project manager will state that the project can’t be completed in the timeframe or for the cost selected. The sponsor then asks why. An unprepared project manager will have an answer, such as the team is too busy or the costs will be greater, but does not have the facts to back it up. Using the method provided in this paper, the conversation should go more like this:
Project Manager Eva: “I need your help with the project commitments.”
Sponsor: “Sure, what is it?”
Project Manager: “I’ve been given the date of 31 March and a budget of US$50,000 to complete this project. According to the plan, with the resources allocated, I can meet the budget of US$50,000. The date, however, is coming in at 15 April. Either we can leave the date at 15 April or we can accelerate the schedule. Accelerating the schedule will cost an additional US$5,000.”
Sponsor: “Why will it cost more? I want 31 March, but I have no more in the budget to spend.”
Project Manager: “Let me show you the plan. If we remove this requirement, then we can meet the 31 March date without accelerating the schedule or cost, but we will not have that requirement. What would you like to do?”
Sponsor: “Not much I can do. Can we do this other requirement at a later time?
Project Manager: “Under a new scope, sure. Would you like me to remove the requirement?”
Sponsor: “Will that get me to 31 March for US$50,000?
Project Manager: “Yes.”
Sponsor: “Then do it.”
Project Manager: “I’ll draw up a change request for your signature.”
Notice how the conversation remained factual? This kind of conversation can get quickly out of hand, but there was a subtle technique used in the delivery. The technique is to not say “no,” it is to say, “That absolutely can be done, here are the impacts.” So, many project managers feel that they have to become gatekeepers and, for the most part, this is true; however, they also become emotionally involved to the point that they begin to take sides. When a project manager begins to care which side of the argument wins, then he or she is getting too involved. In the end, the project manager is there to plan and present options to the sponsor. The sponsor should be the one making the decision about which way to proceed on the project; however, many project managers do not take this step. Instead, they think that they understand what the sponsor wants and make decisions on the sponsor’s behalf. They may try to get the project done by a certain time and, if they can’t, they begin removing quality or requirements in order to make the date. They do this because they are afraid to have the tough conversations with the client or sponsor. It is acceptable to present options and request a decision from the sponsor as long as there are facts to back up the request. The important thing is to remain neutral about the outcome of the situation. Simply present fact-based options and address the issue.
For example, Emil was the project manager running a development project, which was three months past due. The client and Emil were working together to wrap the project up as quickly as possible. The lead developer talked to Emil and said that the travel to the client’s location had worn him down. He would appreciate the ability to work remotely for at least two weeks to recharge. He also felt that the time would allow him to finish more quickly and work with fewer interruptions. The developer also said that if his wish was not granted, he would be so burned out that he would probably leave the project. Emil went to the client sponsor to get acceptance of the request, and the following conversation ensued:
Emil (project manager): “The lead developer is feeling burned out and has requested the ability to work remotely over the next two weeks.”
Client Sponsor: “Absolutely not! We need to finish this project and we are already too far behind.”
Project Manager: “I understand and recognize the importance of the project. He really feels he is burned out on the project and needs the time at home to recharge. He has assured me that he would be more productive if we granted the request.”
Client Sponsor: “Do you think he would be more productive?”
Project Manager: “Only time will tell. He has been true to his word so far. He has also been working long hours here, so I don’t think it is a question of motivation; however, if we go against his request, it is likely he may leave the project.”
Client Sponsor: “I want him here. I need to see him here in order to trust that the work is getting completed.”
Project Manager: “I understand. Here are our options, I can force him to return next week, which will likely be a deterrent and may lead to him leaving the project, or we can grant his wish and trust him to complete his work. Whichever decision you make, I will support it. It will likely take me two weeks to replace the development lead and bring someone else up to speed. It could be the same two weeks lost if he takes the time and does not complete his work.”
Client Sponsor: “Are you saying that we should grant the request and begin to look for a new team lead?”
Project Manager: “I’m just presenting the options. If we grant the request and he does everything he promises, the project will be in good shape. If he does not do what he promises, I will have already started on identifying a new team lead. The worst impact would be roughly two weeks.”
Client Sponsor: “Do that. He can work offsite, but I want him gone if we don’t see the productivity.”
Project Manager: “Will do.”
The end result of this decision was to grant the development lead the requested time. He took off two weeks to work out of his home office and worked remotely. He also completed an estimated four weeks worth of work within the two weeks. He was so productive that he never returned to the client site. He completed the rest of the project remotely. Early in the conversation, the client was steadfastly against the remote idea. Emil really wanted to grant the time to the development lead. If Emil had become emotional as soon as the client had said no to the idea, then most likely the request would have never been granted. By staying neutral and presenting the options, the client came to the decision that the project manager felt was best.
A project manager’s role is to deliver on the expectations of the project. Many project managers become upset or frustrated on a project that has many changes or phases. Dealing with these changes in direction is part of the project manager’s responsibility. A project manager should assess a change or request and notify the sponsor of the impact to the project. To be effective, this must be delivered in a fact-based manner. Project manager Gemma shared her story of a discussion that never seemed to end:
Gemma (project manager): “To complete this project by the date requested, we either need to remove a requirement or add US$25,000 to the budget for another resource.”
Sponsor: “I don’t have US$25,000 to spend.”
Project Manager: “Which requirement should we remove?”
Sponsor: “I want everything in there.”
Project Manager: “Alright, is it acceptable to move the desired date?”
Sponsor: “No, I need it by that date.”
Project Manager: “In order to deliver that date, I need to either remove a requirement or increase the budget. Which would you prefer?”
Sponsor: “I already said no to both.”
Project Manager: “So, you would like me to deliver this date without removing scope or increasing the budget?”
Project Manager: “Do you not trust the team or these estimates?”
Sponsor: “I trust the team.”
Project Manager: “The team is saying that it needs more time or resources.”
Sponsor: “I need that date.”
Project Manager: “According to the plan, we are not saying it is impossible, but it is very unlikely to deliver this scope in the timeframe allotted. It is likely that this project will fail before it begins.”
Sponsor: “Are you saying that you can’t run the project?”
Project Manager: “Not at all. We will do our best to deliver this scope in the timeframe allotted. We have asked for the time and resources necessary and have been declined. We will work with what we have to try our best to deliver.”
Of course, the project did go past the due date and the sponsor continuously declined to reduce the scope. However, the sponsor did not blame Gemma. This is not a case of winning or losing, which is not what is important. What is important is to stick to the facts and stay neutral in the conversation. The project manager must present options. In the end, the sponsor will have to deal with the consequences of the decisions made.
The real point of all of this is that staying unemotional and sticking to fact-based arguments will benefit the project manager. All issues can eventually be resolved with data. Find the data and the variances, and the issues will be resolved. This is the same theory that process improvement strategies, such as Six Sigma, are built on. Six Sigma was created in the manufacturing world; it literally means three defects per million opportunities. However, the entire process centers on identifying the process, finding the measurement points, and gathering data. Then, when a process enhancement is implemented, the data are measured again and compared with the original to validate the improvement. The same concepts are displayed in project management. Every decision made in a project will impact time, cost, resources, or quality. Find the data, present the options, and then deal with the change. Whether a sponsor grants more time or not, having the “it is what it is” attitude will allow the conversation to remain factual and unemotional. Presenting the data in an honest way will assist in making the best decision possible for the project and, in turn, improving the chances for project success.
Morris, R. (2008). Project management that works! New York, NY: AMACOM.
Thomsett, R. (2002). Radical project management. Upper Saddle River, NJ: Prentice Hall PTR.
© 2011, Rick A. Morris
Originally published as a part of 2011 PMI Global Congress Proceedings – Dallas, TX