Common Mistakes in Project Management Framework Adoption

𝗜 𝘀𝗽𝗲𝗻𝘁 𝟲 𝗺𝗼𝗻𝘁𝗵𝘀 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮 𝗣𝗠𝗢 𝘁𝗵𝗮𝘁 𝗻𝗼𝗯𝗼𝗱𝘆 𝘂𝘀𝗲𝗱. 🥴 Beautiful governance framework ✅ Fancy project templates ✅ Weekly status meetings ✅ Zero actual adoption. Teams kept working around us. Leaders stopped showing up. And I was basically running a compliance theatre that added zero value. That's when I realized: I was building for perfection, not for people. 𝗛𝗲𝗿𝗲'𝘀 𝘄𝗵𝗮𝘁 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝘁𝗵𝗲 𝗵𝗮𝗿𝗱 𝘄𝗮𝘆: Most PMOs fail because we start with process instead of problems. We design the "perfect" intake form before we know what decisions we're supporting. We build dashboards before we understand what questions leaders actually need answered. (Look at me 🥹 spending months on a framework nobody asked for) 𝗦𝗼 𝗜 𝘁𝗵𝗿𝗲𝘄 𝗶𝘁 𝗮𝗹𝗹 𝗼𝘂𝘁 𝗮𝗻𝗱 𝘀𝘁𝗮𝗿𝘁𝗲𝗱 𝗼𝘃𝗲𝗿. This time? I led with questions: ↳ What decision is keeping you up at night? ↳ What's the biggest bottleneck in delivery right now? ↳ If this PMO could solve ONE thing, what would change everything? And I listened. Like, really listened. 𝗧𝗵𝗲𝗻 𝗜 𝗿𝗲𝗯𝘂𝗶𝗹𝘁 𝘁𝗵𝗲 𝗣𝗠𝗢 𝗮𝗿𝗼𝘂𝗻𝗱 𝟯 𝗰𝗼𝗿𝗲 𝗳𝗼𝘂𝗻𝗱𝗮𝘁𝗶𝗼𝗻𝘀: ☝🏼 𝟭/ 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗰 𝗰𝗹𝗮𝗿𝗶𝘁𝘆 𝗯𝗲𝗳𝗼𝗿𝗲 𝗽𝗿𝗼𝗰𝗲𝘀𝘀 Your PMO can't prioritize work if the organization hasn't defined what matters. I stopped building intake processes and started facilitating priority conversations. We defined criteria. We killed projects that didn't fit. We said no with evidence. Turns out, a simple scoring model beats a 47-field intake form every single time. ✌🏼 𝟮/ 𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻-𝗳𝗼𝗰𝘂𝘀𝗲𝗱 𝗴𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲 Nobody wants another status meeting. I replaced weekly reporting theatre with monthly decision sessions. One agenda item: What choice do we need to make today? Attendance went from 40% to 95%. Because we were finally making decisions instead of just talking about work. 🤟🏼 𝟯/ 𝗣𝗲𝗼𝗽𝗹𝗲 𝗼𝘃𝗲𝗿 𝗽𝗿𝗼𝗰𝗲𝘀𝘀 The best PMO framework is the one that actually gets used. I stopped designing for perfection and started designing for adoption. Simple templates. Clear accountabilities. Just enough structure to add value without adding friction. 𝗥𝗲𝗮𝗹 𝘁𝗮𝗹𝗸: The last time you built something in your PMO that people actually wanted to use? That's usually the moment things start working. 𝗥𝗲𝗮𝗱𝘆 𝘁𝗼 𝗯𝘂𝗶𝗹𝗱 𝗮 𝗣𝗠𝗢 𝘁𝗵𝗮𝘁 𝗽𝗲𝗼𝗽𝗹𝗲 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘂𝘀𝗲? Drop "GUIDE" in the comments, and I'll send you the Ultimate PMO Setup Guide. It's the exact roadmap I use to help organizations build value-driven PMOs from scratch. 𝗣.𝗦. What's the ONE thing your PMO could do differently that would actually change how work gets done? --- Found this helpful? Repost ♻️ to help another PMO leader who's building process when they should be building trust.

Every executive has said it. “It worked in the pilot.” Six months later? Adoption stalls. ROI blurs. Momentum fades. The pilot didn’t fail. The organization did. The most expensive mistakes don’t happen during the pilot. They happen the moment you go live. Here’s the CXO checklist. 1. The Theater Pilot A small, high-performing team runs it. They’re motivated. Tech-forward. They make it work. But you didn’t test against: → Average performers → Busy managers → Messy data → Existing incentives Scaling exposes what the pilot protected you from. Gut check: Did we test in real operating conditions or in a lab? 2. Tool = Strategy Buying tech isn’t strategy. A pilot isn’t an operating model. If rollout sounds like: → “Company-wide next quarter.” → “Everyone gets licenses.” → “We’ll host training.” You have distribution, not transformation. Gut check: Did we redesign workflows and accountability or just add software? 3. No Incentive Realignment You ask teams to: → Use new tools → Change behavior → Share data But you don’t change: → Compensation → KPIs → Performance reviews People follow incentives, not vision decks. Gut check: What does someone lose by not adopting this? If the answer is “nothing,” adoption will stall. 4. The Middle-Management Freeze Executives sponsor the pilot. Managers live the rollout. They’re wondering: → Does this expose performance gaps? → Increase my workload? → Reduce my control? If managers aren’t enrolled, they’ll quietly resist. Gut check: Are managers champions or skeptics? 5. No Operational Owner During rollout, ownership blurs. Who owns: → Adoption targets? → Integration? → Optimization? If it’s “shared,” it’s unowned. Transformation needs a named operator. Gut check: Who wakes up thinking about making this succeed? 6. Metrics Disappear In the pilot, you measured everything: → Time saved → Output lift → Conversion impact Post-launch? The dashboard goes quiet. Without visible performance tracking, momentum dies. Gut check: Are we still measuring what justified the investment? 7. Culture Was Never Addressed AI. GTM redesign. Automation. These aren’t tech projects. They’re identity shifts. If your culture values: → Heroics over systems → Individual wins over shared intelligence → Control over transparency Your pilot will work. Your transformation won’t. Gut check: What belief does this initiative threaten? The Real Problem Isn’t the Pilot Pilots are built to succeed. Scaling exposes truth. Before you go live, ask: → Did we realign incentives? → Assign clear ownership? → Enroll managers? → Redesign workflows? → Keep performance visible? Because “It worked in the pilot” isn’t proof of success. It’s a warning. Need help getting started with or refining your AI strategy? DM me to get a conversation started.

My 10 mistakes introducing PLM. 🚩  1. Lack of clear objectives PLM initiatives start without a precise definition of: - What exactly should be improved (e.g., change processes, data quality, time-to-market, …)? - How success will be measured? - How do I balance diverging targets: function, integration, technology? - ALM, PLM and ERP are the most important IT-Systems along the PLC. How are functions and processes distributed and integrated? ➡️ Consequence: The project loses focus, becomes bloated, or fails due to unrealistic expectations. 🚩  2. Treating PLM as an IT project PLM is fundamentally a process and organizational transformation, not just a software. ➡️ Consequence: Poor involvement of departments leads to low adoption and inefficient workflows. 🚩  3. Unclear or conflicting processes Companies often attempt to implement PLM while their underlying processes: - do not exist, - are poorly documented, - differ across organizational units. ➡️ Consequence: The tool ends up digitizing chaos instead of improving it. 🚩  4. Scope too large / Big-Bang implementation Trying to deploy a comprehensive PLM system all at once is one of the most common pitfalls. ➡️ Consequence: Delays, budget overruns, and user frustration. 🚩  5. Insufficient Change Management PLM affects roles, responsibilities, and daily work habits. Common oversights: - weak communication, - missing training, - lack of key-user involvement, - lack of C-level involvement. ➡️ Consequence: Resistance, workarounds, and low acceptance. 🚩  6. Poor master data and document quality - inconsistent or duplicated data, - no data cleanup before migration, - missing standards (naming, numbering, classification, ...). ➡️ Consequence: Bad data stays bad—only now inside an expensive system. 🚩  7. Over-customization Companies frequently try to model every exception and satisfy every request. ➡️ Consequence: Complex, costly, hard-to-maintain systems that hinder upgrades. 🚩  8. Underestimating integration PLM relies on clean interfaces to systems like: CRM, CAD, ALM, ERP, MES, SCM. ➡️ Consequence: Media breaks, duplicate data, and process gaps. 🚩  9. Insufficient resources or the wrong project team PLM is often done “on the side": - no dedicated project manager, - limited internal PLM expertise, - weak executive sponsorship. ➡️ Consequence: Delays and unsatisfied never ending stories 🚩  10. Focusing only on basic design features Many PLM deployments center solely on CAD and E-BOM. But PLM should cover: requirements management, variant management, change management, service, ... ➡️ Consequence: PLM becomes an expensive CAD data vault rather than an enterprise-wide product backbone or PLM functions are taken over by CAD (Onshape) or ERP ✅ Summary Most pitfalls arise not from technology or functional coverage, but from strategy, processes, and change management. Organizations often underestimate the cultural and organizational change—and overestimate what the software alone can fix.

Projects don’t fail at the end. They bleed out quietly. The dashboard’s green. Scope is locked. Risk register: pristine. But deep down, something’s off. And then: collapse. These five failure patterns operate quietly beneath traditional project governance. Most project managers don’t see them coming. Most executives don’t know to look for them. Let’s change that. 1️⃣ 𝗧𝗵𝗲 𝗛𝗶𝗱𝗱𝗲𝗻 𝗖𝗮𝘀𝗰𝗮𝗱𝗲 𝗘𝗳𝗳𝗲𝗰𝘁 One change order doesn’t seem dangerous. Until it quietly shifts timelines and inflates costs by 20 to 40 percent. You’re not managing a project. You’re managing a web of invisible triggers. ✅ Fix: Map interdependencies, not just deliverables. One change? Check every downstream impact before approval. 2️⃣ 𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻-𝗠𝗮𝗸𝗶𝗻𝗴 𝗙𝗿𝗶𝗰𝘁𝗶𝗼𝗻 𝗟𝗼𝘀𝘀 When decision-makers sit too far from execution, delays go unspoken. By the time leaders hear about a problem, the team has already worked around it three times. ✅ Fix: Flatten the information flow. Real-time visibility beats formal escalation. Informal standups uncover truth faster than formal updates. 3️⃣ 𝗧𝗵𝗲 𝗠𝗲𝗮𝘀𝘂𝗿𝗲𝗺𝗲𝗻𝘁 𝗕𝗹𝗶𝗻𝗱 𝗦𝗽𝗼𝘁 You can’t manage what you don’t measure. Many teams launch without clear performance thresholds, bias checks, or value realization metrics. ✅ Fix: Define success at the start—not after go-live. Measure more than delivery. Measure adoption, behavior change, and realized business value. 4️⃣ 𝗧𝗿𝗲𝗮𝘁𝗶𝗻𝗴 𝗖𝗵𝗮𝗻𝗴𝗲 𝗟𝗶𝗸𝗲 𝗟𝗼𝗴𝗶𝘀𝘁𝗶𝗰𝘀 You explain the “what” clearly. But the “why” never lands. Employees nod in meetings, then quietly work around the new process. ✅ Fix: Change isn’t just about communication. It’s about emotion. Give people space to grieve the old way before pushing the new one. Trust builds adoption. 5️⃣ 𝗧𝗵𝗲 𝗨𝗻𝗶𝗾𝘂𝗲𝗻𝗲𝘀𝘀 𝗕𝗶𝗮𝘀 “This project is different.” It’s probably not. When leaders skip reference class analysis, they ignore past patterns (and repeat them). ✅ Fix: Study three similar initiatives. Understand where they struggled. Use real data to inform planning, not assumptions. These aren’t isolated issues. They all stem from a shared root cause: We manage projects like delivery machines, while ignoring the people, the relationships, and the blind spots that actually drive success or failure. You can hit every milestone and still miss the outcome. ----- 👋 I’m Lars – delivering transformation that sticks. 🔔 Follow me for more on fractional leadership and change management.

The 3 biggest project management mistakes I see agencies make: 1. Treating PM software like a magic wand. Look, I love ClickUp as much as anyone (we probably love it more than most here at ZenPilot, actually). But even the most robust software won’t fix broken processes. You can't just slap ClickUp on top of chaos and expect miracles. 2. Ignoring the human element. Your PM system is only as good as the people using it. If your team doesn't buy in or understand how to use your systems, you won't improve productivity long-term. 3. Hopping from tool to tool. I've seen agencies switch PM tools every 19 months on average. That's extremely wasteful. Constantly switching up your approach is exhausting for your team and kills consistency. Pick a solid framework and stick with it long enough to see results. Here's the hard truth—which we’ve learned by executing over 3,000 ClickUp implementations: Effective project management isn't just about fancy tools. It's about the right tool + clear processes + (most importantly) consistent team habits. Most agencies hyper-focus on tools, neglect processes, and completely ignore habits. Then they wonder why things fall apart. Want to actually improve your agency's project management? Start by auditing your team's daily habits. That's where the real magic happens.

Leaders worry about strategy during transformation. That’s rarely what breaks it. Most transformations stall for quieter reasons. Here are 10 pitfalls that quietly kill organizational change: 1/ No Clear, Compelling Case for Change ⤷ People won’t act if they don’t understand what’s at stake. ⤷ Show the cost of doing nothing with real examples 2/ Rushing the Rollout ⤷ Speed without readiness breaks trust. ⤷ Pilot first, scale in phases and include feedback gates before full launch. 3/ Ignoring Emotions and Resistance ⤷ Resistance isn’t obstruction, it’s information. ⤷ Run listening sessions and address the top 2–3 concerns visibly. 4/ Poor One-way Communication ⤷ Top-down memos invite rumors. ⤷ Build a two-way plan for team conversations. 5/ Leaving Out Users and Front-liners ⤷ Changes decided in a vacuum don’t stick. ⤷ Co-design with key users and frontline reps. 6/ Over-reliance on Structure and Systems ⤷ Org charts alone don’t change behaviour. ⤷ Pair system changes with coaching and clear behaviour anchors. 7/ Overlooking Informal Power Networks ⤷ Trusted employees quietly shape opinions. ⤷ Identify them early and involve them. When they’re on board, others follow faster. 8/ Not Enough Leadership Visibility ⤷ Delegated programs get deprioritized. ⤷ Require leaders to model behaviours weekly and report progress publicly. 9/ Lack of Skills and Resources ⤷ Without training or time, people fail. ⤷ Build a skills matrix, fund critical training, and protect practice time. 10/ Using the Wrong Metrics ⤷ Measuring output hides adoption issues. ⤷ Track both adoption and outcomes. Review quarterly. Avoid these, and transformation stops being a struggle. -- 📌 If you want a high-res PDF of this sheet: 1. Follow Daniel Lock 2. Like the post 3. Repost to your network 4. Subscribe to: https://lnkd.in/eB3C76jb

As a PMO director, I've led or witnessed many projects. The most common mistakes I've seen smart PMs make: 1/ Doing others' work ⮑ Fix: Define roles early on. 2/ Ignoring issues / red flags ⮑ Approach concerns head-on. 3/ Catching problems too late ⮑ Break down snarly tasks, and track progress by %. 4/ Not using systems ⮑ Leverage repeatable processes for predictable results. 5/ Excluding key players ⮑ Establish a steering committee for every project. 6/ Burying valuable information ⮑ Share and maintain a project dashboard and workspace, including schedule and RAID log. PS - What issues have you experienced, or witnessed in a project? How did you fix it the next time around? ___ 👋 Follow me Timothy Morgan for more about enterprise project and portfolio management. . .

There's confusion with frameworks like Agile, Scrum, Kanban, and EOS due to piecemeal implementation at companies. Here are two scenarios I've experienced, and curious if you have been through soemthing similar? 1. EOS Implementation: • A leadership team reads Traction and goes "all-in" on EOS. • They establish meeting cadences (L10), conduct people analyzers, set rocks, and create accountability charts. • Over time, practices fall off: → Rocks get replaced with OKRs. → Team turnover leaves people analyzers outdated. → Accountability charts are ignored. Result? L10 meetings persist without context. New leaders often don’t understand why they’re called L10s—it’s just routine. EOS is never mentioned again. 2. Agile Misuse: • A leadership team learns about Agile, hoping to bring order to chaos. • Instead of addressing process issues, they adopt Scrum superficially. • Daily stand-ups, called Scrum, are project managers reciting tasks and often past-due deadlines. • The team is still a feature factory, disconnected from leadership priorities and decisions. Newcomers may think they’re in a Scrum environment when the principles aren’t being followed. Leaders justify constantly shifting focus as being agile instead of empowering the team. Is it any wonder there’s confusion around these frameworks? I advocate for understanding the why behind practices rather than rigid adherence to processes. Leadership often tries to mask dysfunction with a veneer of so-called proven methods, but true change requires deeper understanding and a commitment to engage in the difficult work of change management. #Agile #Scrum #Kanban #EOS #ProductOperations #ProductManagement #BusinessProcess #ChangeManagement

ACC implementation didn't fail because the software is bad or people are incompetent . It failed because of 𝗺𝗶𝘀𝘁𝗮𝗸𝗲𝘀 𝗮 𝗹𝗼𝘁 𝗼𝗳 𝗰𝗼𝗺𝗽𝗮𝗻𝗶𝗲𝘀 𝗺𝗮𝗸𝗲𝘀. 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 #𝟭: 𝗖𝗼𝗻𝗳𝘂𝘀𝗶𝗻𝗴 𝘁𝗵𝗲 𝘁𝗼𝗼𝗹 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗽𝗿𝗼𝗰𝗲𝘀𝘀 You bought ACC. Set up some folders. Gave everyone access and said: "ok, now go - and do the work in ACC" Then wondered why nobody uses it properly. Because ACC is a 𝘁𝗼𝗼𝗹. Not an 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗻𝗴 𝗺𝗼𝗱𝗲𝗹. You still need to define: → What goes where (structure) → How information moves (workflow) → Who can change what (permissions) → What we information we use in "this" specific situation Without these? ACC becomes an expensive fancy Dropbox. 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 #𝟮: 𝗪𝗲𝗮𝗸 𝗰𝗵𝗮𝗻𝗴𝗲 𝗺𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 You trained people on "how to click buttons." You organize a day ACC training. You even hire external "BIM Specialists" who are "experts" in CDE implementation. .... and what these "experts" do? : They show ACC features. They demo the interface. Then assume people will change 10 years of email habits overnight. Training ≠ Adoption But this training didn't address: → Why they should change their habits using new platform → What's in it for them, and how CDE it will make their life easier, when used properly → How we are going to handle the transition period → Who to ask when things break So teams fell back to email and local drives. Because that's what they trust. 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 #𝟯: 𝗡𝗼 𝗺𝗲𝗮𝘀𝘂𝗿𝗲𝗺𝗲𝗻𝘁 You launched CDE solution (e.g.ACC ) and hoped for the best. But you never tracked: → Are people actually using it? → Where are they still using email/Teams to exchange files? → What friction points exist? → Is adoption growing or stalling? Can't see it = Can't fix it. 𝗧𝗵𝗲 𝗽𝗮𝘁𝘁𝗲𝗿𝗻: Firms think: "If we buy ACC, chaos will fix itself." It won't. ACC gives you the 𝗰𝗮𝗽𝗮𝗯𝗶𝗹𝗶𝘁𝘆 to organize information. But it doesn't give you the 𝘀𝘆𝘀𝘁𝗲𝗺 that makes it happen. You need both.