Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
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? |
Plan and Facilitate a Requirements Workshop
Categories:
Project Planning
Categories: Project Planning
| Every project manager knows that there is no single best way to collect project requirements. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Fourth Edition identifies several tools and approaches for collecting requirements. They include interviews and focus groups, facilitated workshops, group creativity and group decision-making techniques. Combining some of these tools and techniques with a requirements workshop can be the most efficient and effective requirements elicitation approach. But only if the workshop is planned and facilitated well. Planning a requirements workshop is no different than planning any meeting or event. Some simple steps to follow: 1. Define the scope and establish an agenda The scope and agenda should make it clear to all participants the reasons why they are attending the workshop. 2. Invite the right people Generally, you want to keep the guest list short, but make sure to invite key stakeholders. These include representatives from teams or user groups that will benefit from the project's outcome, project sponsors, product or system owners, and business and technical consultants. 3. Plan the logistics To facilitate an open and constructive working session, make sure that the workshop's location and environment has sufficient capacity and appropriate equipment for hosting the workshop. Now that we have a good plan, how do we facilitate the workshop? 1. Lay ground rules Establish basic ground rules. For example, start on time, stay in scope, and respect and build on other people's ideas. 2. Gather requirements Get everyone involved through questioning and individual interviewing. Apply group creativity techniques, such as brainstorming and mind mapping. And for topics that require in-depth and focused discussions, organize dedicated breakout sessions. 3. Record the workshop Make sure that someone attends the workshop solely to write the protocol during the workshop. He or she should capture all requirements, ideas, assumptions, risks and open items. 4. Pre-qualify and pre-prioritize requirements To facilitate the scoping process at a later stage, try to leave a requirements workshop with pre-qualified and pre-prioritized requirements. 5. Review the protocol and develop a follow-up plan At the end of the workshop, plan sufficient time to review the written protocol and the derived action items. Develop a follow-up plan to address the open items. Identify the owner of each item, and establish deadlines and next-steps. Do you hold requirements workshops? If so, how do you plan and facilitate them? |