Effectively Dealing with Conflict on Projects – Part 2
Posted by Brad Egeland
In Part 1 of this series we looked at the first five of ten ways to calmly and constructively work on dealing with conflict within your projects. How the project manager proceeds with conflict resolution can have a huge effect on the project and the team members involved and possibly on the overall outcome of the project. And let’s not forget the customer satisfaction component – especially if the customer is observing or involved in the conflict.
In this Part 2, we’ll examine ways six through ten of dealing with project conflicts….
6. The project manager keeps everyone focused on the cause of the conflict. He avoids the tendency to blame someone or to rationalize it away. Staying focused on what caused the conflict can be the best course toward actually resolving it. Straying from that can lead to the ‘blame game’ which we all know is not a product road to take.
7. The project manager keeps the big picture in focus. He asks himself what the best way is to resolve the conflict so as to achieve the project goal. Always be thinking in terms of the overall project goal. When you do that and allow that thought process to guide your actions, then you’re more likely to resolve project conflicts in ways that are not detrimental to the project and its forward momentum – assuming it has one.
8. The project manager sets a plan for resolving the conflict. He also remains objective. Planning is critical in all project management actions. And that applies to conflict resolution as well. Jumping in without proper planning could land you on one side or the other in the conflict or leave you less than objective in your actions. That is not a place you want to be as the project manager.
Effectively Dealing with Conflict on Projects – Part 1
Posted by Brad Egeland
I’ve written about this one before but bears discussing again. Why? Because conflict on the project is inevitable. It’s as inevitable as project risk, project budget issues, death, and taxes. If the project manager has to deal with conflict, then it makes sense to do so as logically, graciously, and constructively as possible. After all, remember that it’s real people you’re dealing with even if you sometimes have trouble keeping them focused on the end goal and not on issues with each other or the assignments you’ve tasked them with.
Let’s look at a few ways that the project manager can calmly and constructively work to deal with conflict on the project:
1. The project manager diffuses the charged emotion within himself. This is basically the classic ‘count to ten’ process we try to teach our kids and ourselves. Before reacting, take a deep breath and count to ten. You’re less likely to kill someone that way and less like to do something that could permanently taint your career. Remember the old “if you can’t say something good, don’t say anything at all?” Well, that’s not really what I’m talking about here …. it’s more like “don’t say anything out loud that you wouldn’t say out loud after counting to ten first.”
2. The project manager diffuses the charged emotions in other people. This is kind of like separating fighters and telling them to go back to their corner. Calm the parties down that are having a conflict and basically have them count to ten. Probably figuratively speaking. Tell them to go to lunch, come back, and we’ll figure out how to settle the disagreement. Lunch always helps. And sometimes food – or lack thereof – is part of the problem. You’ve seen the recent Snickers commercial with Betty White, right?
3. The project manager identifies the facts of the situation to determine the cause of the conflict. He avoids comments that can be viewed as taking sides or being accusational. The last thing the project manager needs to be doing is taking obvious sides in disagreements among project team members or with the customer. Remaining impartial and appearing to be the mediator or even facilitator, if necessary, is key. I’ve said that the project manager needs to be a good negotiator. Look for ways to offer give and take opportunities. Look for ways to make this turn out to be in everyone’s favor. It’s not easy, but if you look hard enough, you’ll likely find it.
Four Principles to Guide Project Managers – Part 1
Posted by Brad Egeland
This Part 1 of a two-part article outlines the first two of four principles to guide you on your project management endeavors. It is not all encompassing, by any stretch of the imagination. And I would gladly welcome your feedback and input through comments on this article.
Be Conscious of What You are Doing
Luck should never be the plan for success as a project manager. Project success should not be accidental – at least not as an ongoing plan. It may work on short-term efforts or when you’re working alone. But it’s not a good plan for long-term undertakings or when you’re leading a project team.
A project, by definition, is something that has a unique aspect to it. Even if you are performing your tenth software implementation of something that is nearly identical to the previous nine, there are still going to be variables that make it different. The environment and IT infrastructure will mean performance variations that will need to be understood and handled, etc. Projects are difficult enough, leaving things to luck makes success that much more difficult to achieve. Plan well, create an effective plan, and utilize repeatable processes and reusable templates.
Invest Heavily in Front End Work
Do it right from the beginning. If you’re like me, you get a new piece of software or a new gadget of any type and the first thing you do is start to use it. Directions? Who needs ‘em?
When we kickoff projects, we need to have a different mindset. We need to get it right from the start. Invest in the upfront work. Don’t jump from handoff right into the project. Plan well up front.
Caution: Jumping in too quickly in project management is going to get you into big trouble in a hurry.
Never Tell the Customer the Sky is Falling
Posted by Brad Egeland
Every project is important – no matter how big or small it is. We want to succeed on every project and we want our customers to realize that success and build confidence in us.
Building customer confidence
In fact, it is my belief that everything we do on a project we should do with a mindful eye to building customer confidence in both our ability as a project manager and our team’s ability to deliver a quality solution to the customer. Given that concept, it is then understandable that how we conduct ourselves and how are team conducts themselves on the project and in front of the customer is of utmost importance.
I am a firm believer that we should not withhold bad news from the customer. It is certainly reasonable and acceptable to withhold it long enough to strategize with your team or your executive management on how to present the news or to quickly work up some potential response scenarios. But that should be done swiftly and the customer needs to hear the news quickly from the project team before they find out through another means or on their own. And in every instance that I can ever dream up, that news needs to come first from the project manager.
The sky is falling
What can’t happen is a project team member that essentially exhibits behavior that tells the customer “the sky is falling” when a problem or issue is faced on the project. The quickest way to lose customer confidence in the project manager, the potential for project success, and the team member who is professing that the sky is falling is to act like an insurmountable issue has reared it’s ugly head.
Four Project Decisions You May Regret Later On
Posted by Brad Egeland
Sometimes, depending on the size and visibility of the project, there is a tendency to want to cut some corners on. This may come about due to pure laziness. Or maybe it comes as a directive or request from your executive management. However it evolves, it can be a slippery slope and it can cause big problems on your project. You may have to ‘scale’ your best practices for the project depending on its size and budget, but it’s never a good idea to skip key activities altogether – even if you’re being told to do this by superiors. If the directive to cut corners is coming from above, you may need to educate them on the risks that are invited into the project by eliminating key best practices steps along the way.
At any rate, it’s important to pay attention to detail no matter how big or small the project is. And, given that thought, I’ve outlined four poor decisions you could make on your project just to save time or money – these could come back to haunt you in a big way later in the project. They are:
Skipping key up front planning documents
What you or your customer may consider time wasters are actually building blocks to good project documentation and understanding. Even if the customer isn’t paying for the early planning documents some of them still should be created – especially ones like the Communications Plan, the Risk Plan, and the Change Control Document outlining how project changes and change orders will be handled. Creation and signoff of these plans at the beginning of the project will ensure everyone understands how to handle these issues and processes when they come up and customer satisfaction will be higher as a result.
Not putting together a detailed master schedule
This should be done even for the smaller projects. A detailed project schedule created and distributed early in the project provides the customer and project team with a solid understanding of the tasks, goals, level of effort, and timeframe for the project. Even if the project is extremely simple and you never update it after the first creation, it will still help your project team and customer – and you – far more than you realize.
Not creating a requirements traceability matrix
Thorough requirements documentation with a matrix to trace the requirements through the design and development of the solution will help ensure that key requirements aren’t missed in the process. With a requirements traceability matrix, you’ll be able to document how and where each customer requirement is met in the solution.
