Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Maintain Control in Lessons Learned
| In a traditional lessons learned session that is conducted face-to-face, project managers know each person who is present and his or her role on the project. But technology today affords us the luxury of being able to do many things online -- such as holding a lessons learned session. We can engage with people across the country or someone who may be sitting right next door. Regardless of where someone is located, we must maintain a cordial and professional manner when we interact online. When you have dispersed project teams -- and even sometimes otherwise -- getting people to stay focused and not be disrespectful to others in a lessons learned session is a challenge. To overcome this, set the rules for participating in the session. Make sure participants understand them and agree to them. These rules should include:
When you maintain control of the meeting and employ general courtesy, it keeps the discussion flowing and ensures everyone gets the information needed about lessons to be learned. How do you maintain control in lessons learned sessions? |
There's No 'Root Cause' in Project Failure
Categories:
Stakeholder Management
Categories: Stakeholder Management
| "Complex problems have simple, easy to understand, wrong answers." -- H. L. Mencken When a relationship with a key stakeholder breaks down, or there is some other failure in your project, it's tempting to assume there is a 'root cause.' We think that by finding and fixing this key factor, the problem will be resolved. Many tools help find the root cause and these tools work for simple problems. However, they are dangerous to use in complex systems. The '5-Whys' approach assumes that each presenting symptom has only one sufficient cause. By asking 'why?' five times, you can drill down to the root cause. For example, say that your boss complains that her computer is not working. You see the plug is out of the wall socket. You replace the plug and solve the problem, right? Well, the answer depends on how you define the problem: Problem: Lack of power. Solution: Replace the plug. Problem: Lack of training or knowledge. Solution: Teach your boss about the plug. Problem: Poor joinery design. Solution: Put the power points on the desktop instead of on the floor. The '5-Whys' approach requires the right definition of the problem to start digging for a root cause. Even then, the approach only follows one line of thinking, which limits its ability to identify complex interactions. When considering problems in socio-technical systems, such as stakeholder relationships, the assumption that there is a single event that triggers a chain of events that lead to a problem is false. Most problems have multiple contributing causes. Each element is necessary but only when all of the elements are combined 'correctly' is there sufficient impetus to create the breakdown. When trying to understand failures in complex systems, like relationships, a different paradigm is useful. For example, let's say you used a range of motivational techniques to help your team perform that have worked well in the past. This time, however, the team disintegrated, and productivity dropped. Chances are that the problem emerged from a confluence of conditions often associated with the pursuit of success. But in this specific combination, there was "trigger failure;" each item was necessary, but on its own or in a different combination could be more beneficial. These unexpected outcomes are encountered because complex systems, like relationships in and around a project team, have emergent behaviors, not resultant ones. Complex causes require subtle management. You need to be continually prepared for nonlinear behaviors where small problems can result in large and cascading failures. Rather then resolutely applying your standard approaches, look, listen and 'tune-in' to your team. When a complex system reaches the tipping point and collapses into failure, it is too late. You need to feel the issues emerging and adapt to the changing situation. How do you detect failures in stakeholder management? Read more about stakeholder management. |
Project Management Knowledge Versus Technical Knowledge
Categories:
Leadership
Categories: Leadership
| As project managers, we have to manage various tasks in multiple lines of work. At times, we operate from our technical background and impart that knowledge and expertise more than our project management knowledge. There needs to be the distinction of when we use our "project manager hat" versus our "technical specialist hat." Many project managers work in two common extremes: process focus or technical detail focus. This is common for junior project managers and for project managers who are new to an organization. That often happens, in my opinion, because those project managers haven't developed their management style yet or haven't adjusted to the organizational culture. When the project manager thinks something is going wrong on a project, either with how someone is performing a task or the results of a deliverable, we often try to fix it. We do that with our strongest toolkit -- usually, that's our technical background. We often take over and hijack the task just to do it "our way," based on our experience. Remind yourself that as a project manager, you have a different role as a leader. You also can't be a technical skills expert for your team. Realign yourself to the deliverables. Gain a clarity of the project goal, the project management approach you are using and your role in managing the given project resources. Project managers can be quite connected and attached to the project outcome. But when you see an opportunity to improve something based on your technical expertise or what you would do differently, stay focused on your role, which is to deliver the project according to the business requirements, aligning with the business sponsor and the organization. Let your team handle their tasks according to their experience and expertise. Do you ever rely too heavily on your technical expertise? Read more from Dmitri. |
Fill in the Blanks for Junior Project Team Members
Categories:
Generational PM
Categories: Generational PM
| The other day, a member of my project team e-mailed me and proposed that we consider starting a new project. The new project would complement a project we are currently working on. Eventually, I learned that the project board had rejected this proposed project before. I discovered that a stakeholder who had pushed to start the project several times -- despite the fact that the board discarded it -- approached my team member, who happened to be a junior member and new graduate. As a new member to our team, I had to explain the project selection process of our organization. The board selects projects from a business-oriented approach. Under this direction, projects produce business benefits that will contribute to achieve organization's strategic objectives. The proposed project did not fit this mindset, but as a new project team member, how could he have known? I explained further to this project team member that in this mindset, project professionals must wear a business and technical hat. Depending on the situation, project managers must ensure that their project teams deliver projects that will produce the benefits and results that the organization is looking for. This is just one example of how project professionals will need to be able to coach "multi" teams, especially those made up of new and young project members. You can't assume that everyone on the team shares your same knowledge. Eventually, the junior team member understood why only projects that will help the organization fulfill its intended purpose should be selected. A few days later, we met with the stakeholder to ask for specifics about the project with regard to the organizational benefits. How do you coach junior project team members when they are less knowledgeable? |
Tailor Your Coaching Style to Project Team Members
Categories:
Education
Categories: Education
| In coaching project team members, project managers may forget that each person is different. Thus, the approach to engage them will be different. It is imperative to remember you are not creating a clone of yourself and that your team members may have a different working style than you. You must have a game plan when coaching individual team members. It does not need to be written down; you just need to pay attention. Focus on the way your team members prefer to work, listen and learn. Some people like to draw when they talk or explain. Some people write everything down. Others just stare blankly but give good responses when requested to. When you have an idea of how your team members operate, try these tips to coach them further:
How well do you know your team members? How do you engage their interest in learning new things? |