Managing Persistent Issues in Project Management

I’ve had to protect my team in the past, particularly when their time or focus was at risk. I’ve seen this happen at companies like Microsoft, Google, and Amazon, where mandates and initiatives would stack during the same timeframe. While each initiative alone might have been reasonable, together they overburdened the teams. Those compiled costs may be invisible to the folks driving the individual mandates. You may have seen teams get overwhelmed by a major release, a review cycle, and bi-annual business planning all at once. This type of time management stress is usually manageable, but there are times when teams can be stretched too thin and compromise morale and quality. When you witness this, I believe it’s crucial to step in. You will hear from your team and you need to be close enough to the issues to decide how to respond. This can be tricky for a leader: on one hand, you want to ensure your team can succeed; on the other, you’re part of the broader leadership and need to support the decisions being made. Sometimes, you have very little room to maneuver. In those cases, I find it most effective to have a private conversation with key decision-makers. Meeting behind closed doors allows you to present the reality of your team’s capacity without putting anyone on the spot. Armed with clear data or project plans, you can often negotiate more realistic timelines or priorities. Another common pressure is when stakeholders create frequent direction changes. Repeated shifts in goals or features will thrash your team and waste energy. This often reflects deeper issues with strategy, alignment, and communication. However, you may not have time for a complete overhaul of your planning processes, and you still need a way to prevent thrash. A short-term fix is to set firm near-term milestones or “freeze” dates, after which any changes must go through a formal triage process. This ensures that if changes are necessary, they follow a transparent, deliberate sequence rather than blindsiding. After the freeze, broader project changes can be considered. Ultimately, I see my responsibility as a leader as fostering an environment where my team can perform at a high level, stay motivated, and avoid burnout. Part of a leader's role is to protect their team’s capability and long-term health. There will always be sprints and times when you need to push, but you also need to consider the long view and put on the brakes when required. People who feel supported are more productive, more creative, and likely to stay engaged.

I can spot a doomed project in four sponsor moves. Want to know how? 𝗪𝗮𝗿𝗻𝗶𝗻𝗴 𝗦𝗶𝗴𝗻 #𝟭 - 𝗧𝗵𝗲 𝗗𝗲𝗹𝗲𝗴𝗮𝘁𝗶𝗼𝗻 𝗖𝗮𝘀𝗰𝗮𝗱𝗲: Sponsors who offload project communication to direct reports have disengaged. What starts as “Loop Sarah in on updates” becomes “Sarah will handle all project communication going forward.” Sounds great in theory, but Sarah’s not the one responsible for project success. Assure them that you’re only going to bring them issues that require their input - and bring Sarah in, she’s the gatekeeper now. 𝗪𝗮𝗿𝗻𝗶𝗻𝗴 𝗦𝗶𝗴𝗻 #𝟮 - 𝗧𝗵𝗲 𝗦𝘁𝗮𝗹𝗹: If week-long delays in communication and “let me think about that” have become their go-to, your project has dropped in priority. Reframe your requests with consequences front and center, and offer options to help expedite their thinking. Your job isn’t JUST to elevate the risk, it’s to help them mitigate it. You don’t make the final call, but you need to inform it. 𝗪𝗮𝗿𝗻𝗶𝗻𝗴 𝗦𝗶𝗴𝗻 #𝟯 - 𝗠𝗲𝗲𝘁𝗶𝗻𝗴 𝗧𝗵𝗲𝗮𝘁𝗲𝗿: Sponsors show up to status meetings, but treat them like a box to check, not a place to engage. Stop running status updates with your executives. Make meetings about current risks and decisions that require their input, ask about their current priorities and how the project connects and cancel meetings when there’s nothing that requires their input. 𝗪𝗮𝗿𝗻𝗶𝗻𝗴 𝗦𝗶𝗴𝗻 #𝟰 - 𝗕𝘂𝗱𝗴𝗲𝘁 𝗔𝗻𝘅𝗶𝗲𝘁𝘆: Sponsors who approved 500k are suddenly questioning every expense? This isn’t fiscal stewardship, they’re questioning project value. Tie every expense to business outcomes. “This integration saves us 100k in manual costs” is more persuasive than “you signed off three months ago.” Then, figure out what’s killed their confidence and work with them to restore it. Strong PMs recognize these signs, and manage up to ensure sponsors are engaged, and the project has what it needs to go over the finish line. #projectmanagement #stakeholdermanagement #changemanagement ___________ If this resonated, let’s connect. I work with organizations to diagnose and fix the dynamics that kill projects and profitability.

The 7 Deadly Sins of Project Management How to spot it and then fix it immediately… Most failed projects don’t blow up overnight. They bleed out, one misstep at a time. Here are the 7 sins that derail even smart teams… …and what great project managers do differently 👇 1. Unclear or Shifting Goals The project kicks off. People are excited. But no one’s aligned on what success actually looks like. 📉 What happens: – Team members solve different problems – Timelines drift – Delivery misses the mark ✅ How to fix it: Start with a single, brutally clear outcome. → Define “done” in terms of impact, not effort → Document it → Revisit it every time something changes 2. Scope Creep (The Silent Killer) It starts small. "Can we just add this one feature?" "It’ll only take a few hours." But 12 “quick additions” later… you're off-budget, off-schedule, and exhausted. What happens: – The team loses focus – Resources are stretched thin – Stakeholders get frustrated How to fix it: → Define scope in terms of user value → Use a change log → Train your team and stakeholders to ask: “Does this serve the core goal?” 3. Lack of Communication Loops Most projects don’t die because of bad intentions — they die from silence. What happens: – Issues stay hidden – Team morale drops – Small problems compound into disasters How to fix it: → Build real feedback loops (weekly check-ins, async updates, decision logs) → Create psychological safety, your team should feel safe surfacing risks early → Over-communicate priorities and blockers 4. No Risk Mitigation Plan Assuming nothing will go wrong is project management malpractice. What happens: – You get blindsided by predictable issues – Deadlines slip – Firefighting becomes the norm ✅ How to fix it: → Identify top 5 risks upfront → Define early indicators (“What would we see if this risk is materializing?”) → Create a fallback plan → Reassess risks monthly, not just once at the start 5. Neglecting Stakeholders You think you’re building the right thing, but your stakeholders had a different vision. Now they’re disengaged… or worse, actively blocking progress. What happens: – Last-minute scope changes – Misalignment at delivery – Loss of executive sponsorship ✅ How to fix it: → Identify your real stakeholders → Understand their definition of success → Keep them involved with milestone demos, not just final delivery 6. Trying to Be the Hero Many new PMs try to “do it all” because they think asking for help shows weakness. What happens: – You burn out – Bottlenecks form around you – The team becomes reactive instead of empowered ✅ How to fix it: → Shift from “doer” to “enabler” → Delegate with trust and clarity → Make accountability part of your project design. Great project managers don’t just manage timelines. They manage risks, relationships, clarity, and culture. Add 7th in the comment.

Someone describes a problem. Three seconds later, someone else suggests a solution. Five minutes later, a training course has been ordered. The problem? No one actually understood it. This pattern is so widespread that it has a name: jumping to solutions. Under time pressure, teams move straight to corrective actions without even remotely understanding the root cause. It is like a doctor prescribing headache tablets without asking whether the patient maybe has not had any water for three days. In day-to-day work, it looks like this: The project is delayed. Solution: We need more staff. But the real cause was that three departments had different requirements and no one aligned them. The error rate goes up. Solution: Training. But the real cause was that the process standard had not been updated since years, and half the team was working from a different version. Customer complaints increase. Solution: Complaint management software. But the real cause was that the website promised a three-day delivery time while logistics actually needed seven. Harvard Business School puts it succinctly: leaders instinctively reach for the solution before the diagnosis is clear. That is human. But it is expensive. Because every wrong solution creates a new problem that then also has to be solved. This is where the crucial skill becomes visible: not finding solutions, but reading causes. Anyone who asks “Why?” five times, as Taiichi Ohno established at Toyota, almost always ends up at a missing standard, an unclear process, or a responsibility that no one has defined. In 99 percent of cases, the cause already contains the solution. No training, no seminar, no new tool. Instead, a system that ensures the mistake can no longer happen structurally. The difference between organizations that solve problems permanently and those that manage them permanently does not lie in the budget. It lies in whether they stop after the first “Why?” or keep asking. Sources: Stephen R. Covey, The 7 Habits of Highly Effective People / Harvard Business School Online (2024) / Taiichi Ohno, Toyota Production System (1988) / Kepner-Tregoe, “Top 5 Reasons Companies Ignore RCA” 💾 Save this if you’re locked in. ♻️ Like, Comment, Repost if this was helpful.

When you’re accountable but not in charge as a PM This is one of the silent struggle of many Project Managers. One of the most persistent challenges we face as PMs(this is also applicable to Scrum) is managing poor #performance on a project team without direct #authority over the individuals involved. Yes, you’re responsible for the outcomes, timelines, budget and deliverables. But the people doing the work report elsewhere.🙃 So what do you do when performance is slipping and the #project is on the line? Here’s how I’ve approached it over time: ✅ Lead with project impact, not personal judgment. Focus on how delays or quality issues affect project dependencies and commitments, not the individual’s shortcomings. → “When the database design is delayed, it holds up development and puts our go-live date at risk.” ✅ Use your PM tools as leverage. ↳Dashboards, status reports, and steering committee updates bring natural accountability. Visibility often drives improvement. ✅ Set clear expectations early. ↳At kickoff, establish deliverable standards, communication norms, and escalation paths. When performance dips, you're not starting from scratch, you're referring back to agreed norms. ✅ Stay connected with functional managers. ↳Check in regularly so that when issues arise, you can raise them with specific impact and evidence. Those relationships make a real difference. ✅ Structure your project around your strengths. ↳Assign critical-path tasks to high-reliability team members. For underperformers, just break work into smaller chunks with more checkpoints and fallback options. ✅ Document consistently. ↳Every missed handoff, scope issue, or conversation gets recorded. Oh yes! This is about protecting the project and enabling functional managers to take informed action. ✅ Use retrospectives wisely. ↳Sometimes team feedback surfaces patterns that direct confrontation doesn’t. Retrospectives can be a powerful tool for collective accountability. At the end of the day, our greatest source of influence is the visibility we have as PMs. We see the full picture, where things connect, where they’re lagging, and what the consequences are. 📍And with that perspective, we can lead without needing the org chart to validate it. Isn't that amazing?? Lol I'd love to hear from you. Ever had to fix performance issues on your project team without formal authority over the person involved? Follow 👉 Benjamina Mbah Acha for insights that help you plan, execute, and deliver projects with confidence.

What if your biggest project risk isn't in your status report, but hidden in a workaround so habitual your team no longer sees it? We champion "𝐆𝐞𝐦𝐛𝐚" on the factory floor , going to see the real work. Yet we manage multi-million dollar strategic projects through filtered PowerPoint slides and sanitized status reports. I recently witnessed the power of a Project Gemba Walk with "Project Alpha" an ERP upgrade that was consistently yellow due to "data migration delays." The status report showed a team working overtime. The Gemba Walk revealed the truth: developers constantly switching screens because the legacy system timed out every 10 minutes. They called it "data archaeology" , a workaround that had become normal. The result? The sponsor who saw this firsthand immediately approved a server upgrade, cutting login times by 80%. We then fixed the root cause: flawed data mapping specifications. This is the power of going to where the real work happens. A Project Gemba Walk isn't a progress review. It's a structured visit to: 👀 Observe the actual process 🤔 Ask humble questions 💡 Uncover systemic impediments 🙏 Show respect for your team's challenges Ready to try it? Here's your framework: 1. PREPARE with Purpose Tell your team: "We're coming to learn about the process, not judge performance." 2. OBSERVE & INQUIRE Watch the workflow. Ask: • "What's taking longer than expected?" • "If you had a magic wand, what would you fix?" • "Can you show me how this actually works?" 3. ACT & CLOSE THE LOOP This is critical. Report back within 24 hours with concrete actions. This builds trust for next time. The most valuable insights for your project's success aren't in your dashboard - they're in the quiet frustrations and brilliant adaptations of your team. Stop managing by report. Start leading by observation. #InnoveraConseil will guide you through this journey. What's the most surprising thing you've discovered by going to where the work actually happens? Share in the comments below. #ProjectManagement #LeanLeadership #GembaWalk #Agile #ContinuousImprovement

One of the most useful lessons I've learned as an organizational psychologist is that the presenting problem is rarely the actual problem. ↳ A team says, "We need better communication." ↳ A leader says, "We need more accountability." ↳ A project feels stuck, so everyone assumes the issue is a lack of effort. Then you dig in, and you realize the "problem" is often just the symptom everyone can see. The real constraint is sitting one level deeper, quietly shaping the situation. This is why certain issues keep coming back. You fix what is visible, but you don't fix what made it possible. ↳ Another meeting gets added, but roles stay unclear. ↳ The new tool gets bought, but the workflow stays undefined. ↳ The training gets delivered, but the incentives stay misaligned. ↳ The person gets coached, but the system keeps rewarding the same behavior. Over time, teams start to feel like they're running on a treadmill. Lots of motion, no durable change. And, it burns them out. A simple practice that helps is just going one or two levels deeper. After any fix, ask one more time: "What made this possible?" Not in a blaming way. In a design way. If the issue was a missed deadline, what made it possible? Was the scope unclear? Was the handoff vague? Was the timeline fictional? Was there no owner? Was the work competing with five other priorities? If the issue was "communication," what caused the miscommunication? Was there no decision log? Were expectations implicit? Did updates live in three channels? Was there no agreed response time? If the issue was a conflict, what made it possible? Was it role collision? Was it competing incentives? Was it unclear authority? Was it a lack of shared standards for "good"? Once the root cause is found, can you address it? The best part is that the fix usually doesn't require a big initiative, but rather just a small system change that prevents recurrence. ↳ A clear owner and deadline. ↳ A definition of done. ↳ A single source of truth. ↳ A simple escalation rule. ↳ A standing five-minute weekly review. The goal is not to become a root-cause detective who never ships. The goal is to stop doing surface fixes that feel productive but don't hold. In my experience, a good sign you found the real constraint is that the solution feels almost boring (i.e., less heroic and more structural). If something in your work keeps reappearing, you might not need to put in more effort. You might just need to go one level deeper. If you enjoy posts about building strong systems, finding joy, and creating a life full of agency, I will not let you down. Please follow me here: Michael Rucker, Ph.D.

My first day at one of my previous new jobs went badly. The elevator was broken, so I had to climb six flights of stairs. I was sweaty and late when I rushed into the meeting room. I interrupted the director, who was talking about something important. Everyone stared at me. That is not how I wanted to start my new job. Instead of trying to hide my embarrassment, I owned it with a quick joke about getting my cardio in, then immediately contributed to the discussion. That moment taught me my most valuable career lesson - in engineering, persistence matters more than perfection. Why Persistence Matters in Engineering Teams Throughout my decade+ in engineering roles, I've noticed something troubling: we celebrate quick fixes and clever solutions but rarely discuss the importance of sustained effort on complex problems. After leading teams across different tech companies, I've identified four persistence principles that have consistently separated high-performing engineering teams from average ones. Four Persistence Principles That Transform Engineering Teams: 🏒 Daily updates solve problems. During a major system integration crisis, our junior engineer's consistent documentation of failed attempts ultimately led us to the solution, while intermittent "genius" ideas repeatedly led nowhere. The consistent communicator won. 🏒 Rejected ideas can succeed. My proposal for a new framework was immediately shot down by our technical lead. Instead of giving up, I addressed every concern and returned with version 2.0 two weeks later. That framework saved my team a lot of development hours each quarter. 🏒 Recognize effort, not just results. Our team was stuck on a critical performance bug for three weeks straight. Morale was dropping until we started celebrating persistence itself. We finally solved it on attempt #12, long after most teams would have abandoned the approach. 🏒 Find a persistence partner. The most complex technical challenges drain your motivation. Having an engineering colleague who picks you up when you're ready to quit - and whom you can do the same for - has helped me solve problems I never could have tackled alone. This persistence-focused approach has not only improved our technical outcomes but has also significantly reduced team turnover. Engineers want to work where their sustained efforts are recognized, not just their momentary brilliance. What's the toughest engineering problem you've solved through sheer persistence? How has "not giving up" shaped your technical career?

Avoiding hard conversations costs projects. Intel uses this for billion-dollar decisions. Most PMs wait too long. The feedback session last month didn't work. The conflict keeps escalating. Now your project is at risk. You keep hoping it resolves itself. It won't. Andy Grove — Intel's legendary CEO —  called it 𝗖𝗼𝗻𝘀𝘁𝗿𝘂𝗰𝘁𝗶𝘃𝗲 𝗖𝗼𝗻𝗳𝗿𝗼𝗻𝘁𝗮𝘁𝗶𝗼𝗻. When to use it: → Feedback isn't landing after multiple attempts → Someone crossed a serious line → Team conflict is spreading → Ignoring it = project failure or budget loss The 4 principles: 1. 48-hour rule — don't wait weeks 2. Attack the problem, not the person 3. Involve only people who can fix it 4. Facts and data only — emotions stay outside 𝗣𝗵𝗮𝘀𝗲 𝟭: 𝗣𝗿𝗲𝗽𝗮𝗿𝗮𝘁𝗶𝗼𝗻 Before the conversation, answer: → Does it affect the work? How? → What happens if I ignore it? → What's my goal? → What's their perspective? → Was it always like this? Diagnose the root cause. People underperform for 4 reasons: → Understood differently → Don't know how → Can't (blocked) →Don't want to Each reason = different solution. 𝗣𝗵𝗮𝘀𝗲 𝟮: 𝗧𝗵𝗲 𝗖𝗼𝗻𝘃𝗲𝗿𝘀𝗮𝘁𝗶𝗼𝗻 Start with change: "Before it was X, now it's Y. What happened?" Use the pause technique: → Situation + Argument 1 + PAUSE → Let them respond → Argument 2 + PAUSE → Let them respond Listen more than you talk. Can't get through? Exit. Try again differently. 𝗣𝗵𝗮𝘀𝗲 𝟯: 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻 + 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 → Agree on specific next steps → Set timeline → Define how you'll check progress → Schedule follow-up The longer you wait, the bigger the mess. What conversation have you been avoiding?