Conflict in project management is inevitable. In fact they say that the only way to not have a project management conflict is to have a one-person project. And even then, some people have a tendency to argue with themselves.
Karin Brünnemann (https://www.linkedin.com/in/karinbrunnemann) recently gave a presentation on the topic of Managing Conflict in Projects to the Project Management Institute (PMI)® Slovakia Chapter. And because it was such a success she suggested that we bring it to you as well!
Karin’s presentation and our interview is full of solid advice and best practices you can apply to the conflicts you will inevitably encounter. We will discuss: Definition & Characteristics of Conflict
- Conflict in the Context of Project Management
- How to Analyse a Conflict
- How to Manage Conflict
A big part of the interview is actually focused on that last part -- the actual project management conflict resolution. We are, however, not going to talk about conflict resolution on multicultural projects. That’s reserved for next week.
Project Portfolio Management and the realization that strategic alignment of all projects within an organization is crucial are both gaining ground. And this realization also emphasizes the need for having solid project selection methods.
But how exactly do you do all of this? The number of books that focus on practical advice for implementing a strategic project portfolio management process is quite small. Lucky for us that a new one with exactly that focus has just been published
The new book is titled Project Portfolio Management in Theory and Practice: Thirty Case Studies from around the World (Best Practices and Advances in Program Management) written by Jamal Moustafaev (https://ca.linkedin.com/in/jmoustafaev. In our discussion, we answer these questions:
1. What is project portfolio management?
2. What are the three pillars of strategic PPM?
3. What are some project selection models that support a company's strategy?
4. How do we achieve strategic alignment?
Setting up a PMO usually means setting up some Project Management KPI (Key Performance Metric). But which?
This interview about PMO metrics with Denise McRoberts was recorded at the 2016 PMI Global Congress in San Diego, California. We discuss her paper and presentation "Meaningful Metrics -- The Path toward Measuring what Matters". Here is the abstract:
"The project management office (PMO) was in a rut. The number of projects in work at any one time was increasing; project managers were routinely reporting that all was well while schedules slipped, and there was limited understanding of true project costs." Does this sound all too familiar? In this session, attendees will learn some innovative methods to implement metrics and key performance indicators (KPIs) to better understand your organizational weaknesses and how to overcome them. This session will provide a case study on how a PMO did just that, with plenty of practical examples
You will learn what makes a 'good' metric, how metrics should be developed, and that we also need specific project metrics and project portfolio metrics.
We spend most of our waking hours at work, yet for many among us the time spent there is unrewarding, unfulfilling, and often just unpleasant. If that sounds familiar, then we can help.
Today we are going to be talking about Enlightened Project Management with Joe Drammissi, PMP (http://enlightenedpm.com/about). At first, this sounds like a method that comes straight out of a new age textbook, but it is in fact a worthwhile concept that helps us project managers not only make a positive difference, but also puts us at the leading edge of change. So keep on listening!
In our interview, Joe and I talk about what enlightened project management is but then quickly talk about the traits that an enlightened project managers has. We review what such a PM strives to do, believes in and how she or he works with stakeholders.
We close out the interview by learning how EPM is applied on a project manager's day-to-day work, and Joe gives us a technique that is easy to apply to get us started -- all based on his book 101 Tips for the Enlightened Project Manager.
The good news is that project managers deal with the uncertainty associated with large projects all the time, and it is very likely that you can be successful. You can imagine projects with dozens (or hundreds) of workers, and very long timeframes. If those project managers can be successful, you can too.
Okay, so what should you do? Here are a couple suggestions for you to consider, depending on what you think will work best in your situation.
Break the work into smaller pieces
The first thing to do with a long project is to break it down into smaller pieces if possible. For example, let’s say you have a traditional waterfall type of project. Although you are not sure about the work to be done in nine months, you should at least know what you will need to do over the next few months. You are probably going to start in a requirements gathering process. Instead of defining a one year project, start by defining a project that will cover only the analysis phase. After that project, you can redefine and estimate the remainder of the work. If you still feel uncomfortable doing that, then perhaps you can create a project that just covers the design phase. Ultimately, you may complete the work in three or four smaller projects instead of one large one, but you will get there nonetheless. You will also be able to more easily confirm the resources you need for each of the shorter projects.
Provide less detail as the planning horizon gets further out
Many organizations are not structured in a way that allows you to break a large project into a set of smaller ones. These companies only want to pay for one project, and track one project. If you break it up into pieces, people could become confused.
The next idea is to estimate and plan the work for the entire timeframe, but understand that there will be less detail the further out in the future you get. Again, you should have a firm and detailed schedule for the next three months, but then the planning will be at a higher and higher level. You have a framework for completing the project, but only the short-term activities are planned out in detail. This is probably the approach most project managers take on long projects.
Of course, you cannot leave everything at a high level. Every month you need to replan the project, validating the detailed work for the next two months, and then building the details for the third month out. This makes sure that you always have a three-month detailed planning window, and you are filling in more and more detail for the outer months. If the detailed planning leads you to believe that you will not hit your deadline or your budget, attempt to resolve the situation immediately or raise this possibility as a potential risk.
Use multiple estimating techniques
The classic estimating technique is to build a work breakdown structure, estimate the work associated with the lowest level activities, and then add everything back up for the final overall estimate. This approach does not work well when you are not sure exactly what the work is a long way into the future. Fortunately, there are other estimating techniques that will help you cross-check your estimated effort, cost, and duration. Fist, you can rely on outside experts to review your Project Charter and schedule to see if they think your estimates are reasonable. Second, you can see whether there have been similar projects in your company where you can review the prior schedule and estimates to see how they line up with your project. Third, you can use industry guidelines to create overall estimates based on how much time you think the analysis phase will take. For example, if you find estimating guidelines that say that the analysis phase of a project with your characteristics takes 28% of the entire project, then you can provide a high-level estimate of the entire project based on your detailed estimate for the analysis phase.
If you are concerned about the availability of resources, this approach should work. When you create the initial schedule, you can start to communicate regarding the specific people you will need in the next three months, and the general types of people you will need further out. If you keep a detailed three-month planning window, you will be able to give the resource managers up to three months lead-time once you finally nail down who you need for the project work. If resources are not available, you also have up to three months to escalate the problem or to look for alternatives. Two to three months notice should be enough time to manage through any of these resource scenarios.
Generally, the problem with long projects is that there are many things that can happen in the future that you do not know about today. In other words, there are potential risks. We have already discussed some ways to deal with the uncertainty of schedule and effort estimating risks. There are other risks as well. For instance, there is a risk that resources you need in the future will not be available when you need them.
All of these risks can be identified, and then a specific plan can be put into place to mitigate the risk and ensure it does not happen. Every month you would update the risk plan to ensure known risks are being managed and new risks are identified. If you think there is risk associated with any aspect of the project in the future, identify it and mitigate it.
You are right to be concerned about the unknowns associated with long projects. However, there are a number of techniques that can be used to make you feel more comfortable. Being comfortable does not imply that you know everything. Being comfortable means that you have taken your best shot at laying the project out as best you can, and then relying on a good set of communication processes, good risk management, and good issues management to deal with future threats and current problems as they arise.
There is a good solution to this problem from a project management perspective, but that does not mean you may not have to struggle to make it work. The key is to proactively utilize risk management, issues management, scope management, and proactive communication to your best advantage.
When you start a project, the first thing you need to do is planning, including creating a Project Charter and a schedule. The planning process includes identifying risks and putting plans into place to mitigate those risks. If you do not think you can hit the imposed end-date, now is the time to say something. When you do, management starts to hear that the end-date is at risk before the project even begins. As part of the risk identification, you can ask the project team and your management for their ideas on how to mitigate the risk. Ideas might include extra staff, leaning heavily on users to get their requirements in on time, etc. Again, there is value in identifying the project risks and working with others on risk resolution. This process also helps from a communication standpoint to better manage expectations.
The schedule and proactive communications also help the users better understand their role. For instance, do they really understand the need for timely feedback on requirements and the impact to the project if they are late? Do they understand the dates that they will be needed so that they can better plan their time? You can raise this as a risk and start to manage expectations for what will happen if the requirements come in late. It also gives you more foundation for the follow-up communications that may be required if the user’s dates start to slip.
Manage Issues and Scope
As the project progresses, continue to manage risks, issues, and communication proactively. For instance, if the users end up not meeting their dates in spite of your risk management plans, then you have an issue that needs to be addressed. Issues management (problem identification and resolution) needs to be performed. Again, get your team, management, and stakeholders involved. Ask your manager for input in resolving the problem that is now impacting your completion date. You do not have direct authority over the users. Get more accountability from your management and the business managers to help resolve project resource problems. Your managers and sponsors are also the ones in a position to manage priorities to get the work done. Again, if the problem cannot be resolved perfectly, at least you are continuing to manage expectations.
Continue this proactive project management in other areas as well. For instance, if a person leaves, you have an issue that could impact the end date. Communicate the problem and its consequences, and ask for help in determining the best options for going forward. If the users add more requirements, invoke scope change management and make sure everyone knows the impact to budget and schedule. Don't proceed with the changes unless the sponsor has approved the extra time and budget necessary.
Although it appears that you are being held accountable for events and circumstances that are not within your control, you do have control over the processes you use to manage the project. Manage risk, issues, and scope proactively, and utilize your manager and your sponsor to try to get everyone focused on meeting the aggressive deadlines.
You also have the ability to manage expectations through proactive communication. You should especially point out cause-and-effect relationships. For instance, you can describe the impact to the project if requirements gathering dates are not met.
When it is all said and done, you may, in fact, not be able to hit your imposed deadlines and budget. However, by utilizing disciplined and proactive project management processes, you at least have a shot of success, and you do a much better job of managing expectations and getting management to be a part of the solution, not just the problem.
- When the Idea is Generated. Some companies seriously consider this option. Some companies try to focus on the time between when an idea is generated and when the idea is fulfilled though a project. Their concern is that it takes too much time to implement good ideas. Tracking a project from the time the original idea was surfaced provides visibility on the total length of time to implement. Unfortunately, it is very difficult to track exactly when an idea surfaced, and there are many variables that might cause projects to be delayed while still in the idea stage.
- When a Budget is Approved. This definition is a little more concrete than the previous idea. In this definition, an idea has been generated and has made it far enough along that a cost/benefit statement has been prepared. The project has also made it through the prioritization process and an actual budget has been approved. Keep in mind that the budget may have been approved during the prior year’s business planning process. The actual work may not start until the following year. Therefore, this definition again can seem to start the clock too early.
- When a Project Manager is Assigned. This one is more common. It is hard to say that a project has started before a project manager is assigned. When the project manager is assigned, the project planning and definition begins and the major work of the project starts.
- When the Project Charter is Approved by the Customer. In some organizations, the project officially starts when the customer approves the Project Charter document. Some companies require an approved Project Charter and Schedule before the project team can be allocated. They do this to ensure that the upfront agreement is in place before project work begins.
- When the Project Kickoff Meeting is Held. Using this definition, the planning and definition work is considered to be “pre-project” work. All projects start with a formal kickoff meeting between the client and project team. When the kickoff meeting is held, the planning has been completed, the client has approved the work, and the project team has been allocated. The kickoff meeting is the time to tell everyone that the project is ready to begin.
To a certain extent, you might think that it doesn’t really matter when the project starts. Having a somewhat undefined start date does not take away from the fact that the work is a project. It’s obvious that the project started at some point, since there was a point when the work was not in progress and a point where the work is in progress. So, at some point the project did in fact “start.”
The reason it is important to know the start date is that there may be consequences and incentives based on how long it takes to complete a project. The following are examples of these consequences:
- Project team accountability. It is hard to hold people accountable for things that are not within their control. For that reason, it makes sense that a project manager is held accountable for the project no earlier than when he is assigned. If the project clock starts before he is assigned, it is possible that some decisions were made and some resources expended before he was assigned to the project. Likewise, if team members are held accountable for completing a project within budget and on schedule, it is hard to hold them accountable for work and decisions that take place before they are assigned. For that reason, perhaps the project should officially start when the Project Charter and Schedule are approved, or after the project kickoff meeting is held.
- Process improvement. Many companies keep track of the total duration of projects and attempt to shorten the average project duration over time. It is important that everyone within the company use a common starting and ending point, or the project duration numbers will not be meaningful.
- Financial / accounting. Many projects are considered capital expenditures. Precisely defining when a project starts has consequences in terms of the work that can be capitalized and the work that needs to be expensed.
- Comparisons with other companies. If you compare how long it takes your organization to deliver projects, you want to make sure you have a common definition of start and end dates. If your company considers a project to start when a project manager is assigned and other companies start the clock at the kickoff meeting, it will appear that your company takes longer to deliver projects.
All projects have a start date. But knowing exactly when a project starts is something that companies can define differently. There are a number of events that would be candidates for the start date. Some dates are very early in the business planning process. Other companies place the start date closer to when the work is ready to begin. If your company does not capture metrics and does not provide incentives based on completing a project on time and within budget, then it doesn’t really matter. However, if there are consequences based on the defined start date, then a company must be careful to make sure that the defined start date drives the behavior they are trying to achieve.
Project manager responsibilities are fairly similar in different companies
Whether you have the title or the role of project manner, there is a basic set of job responsibilities that you normally have. Although all publications look at this differently, the responsibilities can be broken down into two major areas.
- Process responsibilities. This includes defining and planning the project, and then managing risk, issues, scope, communication, etc.
- People responsibilities. In addition to process skills, a project manager must have good people management abilities. These include leadership, motivating, communicating effectively, listening, providing performance feedback, etc. (Notice that the basic people management skills don’t include hiring and firing people.)
Most project managers would agree that they have general process and people management responsibilities. However, different companies have different ways that they assign authority to the role of a project manager. The PMI Project Management Body of Knowledge (PMBOK® Guide) captures this thought by identifying different types of project management authority. At one end is a person who manages projects part-time, but has very little authority other than to coordinate the project team workload, and notify others when there is a potential problem. At the other end is a project manager with total authority over the project and the people. In between these extremes are other types of project managers who have various levels of authority.
You need to recognize your level of authority
There is nothing wrong with calling yourself a project manager, even if your level of authority is low. (Of course, if you called yourself a project coordinator or team leader, there would be nothing wrong with that either.) What is important is that you recognize the level of authority you have, and determine how best to manage the project to a successful conclusion.
Let’s take an example of scope management. All project managers should recognize when scope changes occur, and be able to document the benefit of the change and the impact to the project. If you are a project manager with less authority, you might need to take all scope change requests to the sponsor for resolution. If you had more authority, you might be able to approve a scope change yourself, if the impact is below a certain threshold. In both scenarios, the project manager manages the scope change request. The difference is how much authority the manager has to make final decisions.
This holds true with communication, risk management, quality management, etc. You should first understand the level of authority you have, and then determine the project management procedures that are necessary. You might be surprised how few project managers have everything within their control. It is much more common for the project manager to have less than total control over all the people and resources. Instead, in many situations you need to see your functional manager, your client sponsor, a steering committee, etc. for a final decision.
You will find that the more experience you have and the more successful you are, the more authority you will be given. Unless your managers are control nuts, they typically would rather delegate much of the routine project management authority anyway. They just need to have a degree of confidence that if they take on a less active role, you will be able to step up and fill a project management role with more decision-making authority.
Most project managers have limits on their ability to act independently. Even within one company, you will usually find some project managers with more authority than others. There is no shame in that. You need to understand your situation, and then determine the proper project management procedures within those limitations. You should find that you are able to acquire more power as you gain experience and have successfully completed projects in the past.
Let’s assume that the number of failed projects is 50% - a low number. What is interesting is to try to relate that number to personal experience. Where are all of these failed projects coming from? Can you say that half or more of the projects that you managed were failures?
It’s All in the Definition
The idea of a failed project starts with understanding the definition. You may have a perception of what it means to manage a failed project. Your company should have a definition as well, and if they do, your definition should be the same as theirs. One major concept that plays a key role is the idea of tolerances.
Define a Reasonable Cost and Duration Tolerance Level
If you estimate a project to cost $230,000, is your project a failure if the actual cost is $230,500? You missed your budget, right? Yes, but this gets into the concept of tolerances. If you delivered within $500 on a $230,000 budget, you should be lifted on someone’s shoulder and paraded around the company as a hero.
Your company needs to establish the tolerance level that they consider to be reasonable for projects. For example, the tolerance level may be -10% to +5%. That is, if you deliver the project for 5% over budget, it is still considered a success. For the $230,000 project, that means you could have gone overbudget by $11,500 and still have been considered successful. On the other side, if the final cost was underbudget by greater than 10%, that is a problem too. The problem is that the company wanted to deliver projects within expectations. If the sponsor had known that the project actually cost a lot less than estimated, they may have been able to make other decisions with the unused budget. The cost estimate should also include any formally approved scope changes. If your original budget was $200,000, and the client approved an additional $30,000 in scope changes, then $230,000 is the number that you get held accountable for, plus your tolerances.
Normally there is some room for tolerances with your deadline as well. If the projects are internally focused, the end dates are in many cases arbitrary. Your original deadline must also be extended if scope changes were approved.
Declaring Success From a Project Perspective
Once you understand your tolerances (if any), you can start to evaluate success from a project perspective. Generally, the project team members can declare success if:
- The project is delivered within the estimated cost, plus or minus the tolerance.
- The project was delivered within its deadline, plus or minus the tolerance.
- All of the major deliverables were completed. (Some minor ones, or minor functionality, might not be delivered.)
- The overall quality is acceptable. (It does not have to be perfect.)
Declaring Success from a Company Perspective
Declaring success from a project perspective is normally what is required of the project team. However, from a company perspective, success would also be based on whether the company received the value that was promised from the initial ROI calculations. If the project was a failure from a project perspective, it is normally a failure from a company perspective as well. (Although this is not always the case.)
However, there are many examples of projects that were successfully delivered, yet are not delivering the value promised. If the project team delivered successfully within tolerances, there is usually nothing else that can be done from their perspective. However, it is possible that the return on investment calculations were faulty, or the marketplace was misjudged by the client and sponsor. It is also possible that this project was part of a larger initiative. Although your project may be successful, the overall, larger initiative may be a failure.
Every organization should have some general rules about how to declare overall project success or failure. Your project isn’t a failure if you miss the budget by a dollar and deliver a day late. Normally a project will still be considered successful if it delivers within cost and deadline tolerances, and delivers all major deliverables within acceptable quality. From an overall business perspective, another set of questions should also be answered as to whether the business value was achieved as promised.
On the other hand, there are project managers that are known as turnaround artists, and they love to take over projects like yours. In fact, many of them like the worst projects best of all. There are people like this at all levels, including CEO’s whose expertise lies in turning around companies that are in terrible shape.
The project may be need to be completed regardless of the cost in terms of dollars and human relationships. Let’s assume for now that you will try the latter course of action – the project turnaround.
The first thing you want to do is assess the current state of the project. This includes the project schedule and the project team dynamics. Your response to the project team problems will depend on where you are with the schedule. If you only have 30 days of work remaining on the schedule, you will have less ability to make an impact. In this case, the best course of action may be to try to motivate the team for the final push and watch the schedule like a hawk. On the other hand, if your project has many months to go, then you need to see what can be done to repair the damage on the team as well as to replan the schedule to deliver on a new realistic timeframe. Any plan is going to include the following items.
Communicate well. Have you been on a project where the project manager is a poor communicator? This trait usually results in a miserable project experience for everyone. Teams with poor morale tend to have poor communication channels. Don’t let rumors and uncertainty fester. Make sure you share as much information as you can about the project status and anything else that may impact the project team. There is hardly any time when over-communicating is a problem. In your case, it can do nothing but good.
Praise and compliment. When people on your team do a good job, make sure they know it. People do not expect money or gifts when they do a good job – just a pat on the back and a ‘well done’ by their manager. Give it to them – both informally and formally. Another cause of negative morale is poor or no positive feedback or recognition.
Set clear expectations. People like to understand what is expected of them so that they know the challenges they need to meet. They want to see the dragon and slay it. Make sure you give clear instructions when you hand out work so that people understand what they are expected to do. When you hand out work assignments, give a deadline date. When a team member is creating a paper deliverable, like a testing plan, give guidance on how it should be prepared.
Don’t overcommit your team. As you try to improve morale, you also need to be careful not to overcommit the team. Determine what exactly is required to finish the project, and remove anything that is extraneous or can be done after implementation. Make sure you manage scope tightly, and try to defer all changes until after the original project is completed. Poor morale can cause your team to miss deadlines, which causes more pressure and degrades morale even further. The opposite is true as well. If the team can start hitting some interim deadlines (and you communicate this fact and praise them), the team morale should improve, which may make it easier to hit your next deadline.
These are some ideas for turning the project around. First, make sure you understand where you are in the schedule so you know how much time you have to make significant changes. Also, make sure you try to identify as many team problems as you can, as well as the root causes if possible. Then, put together an action plan based on how much work and time is remaining on the project. If there is not a lot of time remaining, focus on the schedule. If a lot of time is remaining, focus on repairing the project team, as well as completing the schedule. There are many areas to look at as a part of repairing damage to the project team. Communication, timely performance feedback and clear expectations will be a part of every turnaround plan. Then, go out of your way to start building some successes – even interim ones. These general ideas, as well as others that you will identify, will give you a fighting chance to turn things around. Who knows - if you are successful and you enjoy the challenge, you might be known as a turnaround artist within your own organization!