Implementing Project Management Software

You've chosen the AI tool. You've rolled out the policy. You've told everyone to use it. Why isn't anyone using it? What tends to happen usually in AI adoption is a top-down implementation: • Management selects an AI solution (often without user input) • They announce the new tool with fanfare • They roll out a policy document • They say: "We can use it now" • Then they wait for results Three months later, adoption is minimal.  The AI sits unused.  The project is labeled a failure. The missing piece? Effective change management. Change management isn't about glossy slide decks or mandatory training sessions. It's about bringing humans along on the journey. It looks like: • Consulting users at every step of the journey • Involving key stakeholders in tool selection • Creating AI champions within teams who can demo products • Establishing two-way feedback channels • Testing workflows with the people who'll actually use them You need to balance 2 critical communications: 1. Benefits: "This could genuinely make your work easier. Let's collaborate to get the most from it." 2. Risks: "I need your help watching for potential issues so we can address them together." When people feel a sense of agency and ownership, they become invested in the project's success. When they feel like cogs being forced to adapt to a new machine, they resist. You see, success isn't determined by the technology you choose, but by how well you bring your people along. The AI tool might be management's decision, but adoption is each individual's choice. Make them partners in the process.

I've seen PMOs designed in a way where teams & stakeholders ignore them. Not because the frameworks were bad. Because no one had involved them in building it. The typical approach: Build the framework. Roll it out. Then figure out how to get people to use it. Perfect PMO processes get created this way all the time. Beautiful templates. Clear governance. Everything documented. Then teams ignore them. The problem isn't that people resist change. It's that adoption gets treated like an afterthought. Most PMO teams spend 90% of their time designing the process. Then scramble to "sell" it to teams in the final 10%. By then, it's too late. Here's what actually works: Adoption isn't what happens after you build something. It's what you design for from the beginning. The most effective PMOs flip the entire approach: Start with the people who'll use it. Instead of asking questions and then disappearing to build, bring them into the design room. Build together from day one: ↳ They show you their current workflow, messy parts and all ↳ You bring lightweight structure options, not finished templates ↳ You prototype together, test with their real work, iterate fast The key shift? They're not giving feedback on what you built. They're co-creating what you're building. Not a comprehensive framework. Not a polished playbook. Just the minimum viable structure that solves their actual problem. The result? Frameworks that don't need training sessions to explain. Tools that people ask for instead of avoid. Processes that feel helpful, not bureaucratic. PMOs don't fail because people won't adopt them. They fail because they weren't designed to be adoptable. Want a PMO that actually gets used? Stop building first and hoping for adoption. Start designing for adoption from day one.

"My product is internal only. My user base is captive - leaders will force them to use." Ring a bell - many PMs building internal products think this way. "I build products based on requirements given by 1 business stakeholder - s/he will ensure adoption. I build, adoption is not my headache." If you are in this boat, time to wake up. Think like a real product manager, not a project manager. Here's how you can behave and showcase your true PM skills, by caring about meaningful product adoption: 🔍 Understand Your Internal Users: Treat your colleagues as customers. Conduct user interviews, surveys, and usability tests to understand their pain points, needs and workflows. Just like external customers, internal users have unique requirements and expectations. 🛠 Iterate Based on Feedback: Gather continuous feedback from users. Use this data to iterate and improve your internal product, ensuring it truly meets the needs of your users. 📈 Drive Adoption: Adoption is the internal product’s equivalent of growth. High adoption rates indicate that your product is valuable, user-friendly, and effectively solving problems. Monitor usage metrics, engagement levels, and satisfaction scores to gauge success. 🚀 Champion Internal Advocacy: Encourage your teams to pitch your product on any stage available. Create compelling training materials, host workshops, and provide excellent support to make it easy for users to adopt and champion your product. 🔄 Align with Business Goals: Ensure your internal product aligns with broader business goals. Demonstrating how your product contributes to overall efficiency, cost savings or any other objective and key result committed by your team. If you really think about it, you can erase the boundaries between an internal or external product. A product is a product, period. And your role as a product manager for an internal product is as critical as a PM for an external profit-making product. If you are not continuously obsessing about product adoption, you are not really doing your core work - you end up being a project manager or an engineer at best. #ProductManagement #InternalProducts #UserAdoption #ProductDiscovery #GrowthMindset #OrganizationalSuccess

⭐𝗖𝗛𝗔𝗡𝗚𝗘 𝗘𝗡𝗔𝗕𝗟𝗘𝗠𝗘𝗡𝗧 [Post 6 of 7 in the PMO System Series] A system only changes when people do. And people don’t change because a project goes live. They change when someone makes the change make sense. 𝘐𝘧 𝘱𝘦𝘰𝘱𝘭𝘦 𝘥𝘰𝘯’𝘵 𝘶𝘯𝘥𝘦𝘳𝘴𝘵𝘢𝘯𝘥 𝘵𝘩𝘦 𝘤𝘩𝘢𝘯𝘨𝘦, 𝘵𝘩𝘦𝘺 𝘸𝘰𝘯’𝘵 𝘤𝘢𝘳𝘳𝘺 𝘪𝘵. I learned this years ago when my organization deployed a new portfolio management system. The tool was excellent. The adoption was a disaster. Not because the solution was weak, but because teams were overwhelmed, messages were inconsistent, and nobody explained what would actually change in their day-to-day work. The project delivered. The change did not. Most PMO professionals treat change as communication and training. Emails. Townhalls. Slide decks. It creates the illusion of readiness. But communication is not adoption. And training is not behavior change. 𝐂𝐡𝐚𝐧𝐠𝐞 𝐞𝐧𝐚𝐛𝐥𝐞𝐦𝐞𝐧𝐭 𝐢𝐬 𝐭𝐡𝐞 𝐝𝐢𝐬𝐜𝐢𝐩𝐥𝐢𝐧𝐞 𝐭𝐡𝐚𝐭 𝐭𝐫𝐚𝐧𝐬𝐥𝐚𝐭𝐞𝐬 𝐬𝐭𝐫𝐚𝐭𝐞𝐠𝐲 𝐢𝐧𝐭𝐨 𝐬𝐨𝐦𝐞𝐭𝐡𝐢𝐧𝐠 𝐡𝐮𝐦𝐚𝐧𝐬 𝐜𝐚𝐧 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐥𝐢𝐯𝐞. ✔️It prepares capacity before asking for new behaviors. ✔️It aligns voices so teams hear one clear message. ✔️And it reinforces the future state until it becomes the new normal. Change pulls from every other PMO discipline. It depends on quality to set expectations clearly. It depends on financials to size effort realistically. It depends on risk assurance to surface impacts early. And it gives governance and portfolio intelligence the human truth they often miss. When change enablement is strong: ✅ resistance drops ✅ confusion shrinks ✅ and adoption becomes an outcome, not an accident. 𝐈 𝐮𝐬𝐞 𝐭𝐡𝐞 𝐅𝐫𝐚𝐦𝐞𝐰𝐨𝐫𝐤: “𝐂.𝐇.𝐀.𝐍.𝐆.𝐄.”: 𝐂 = 𝐂𝐚𝐩𝐚𝐜𝐢𝐭𝐲 for Change People cannot adopt what they have no space for. → Ask leaders “What must stop if we expect this to succeed?” 𝐇 = 𝐇𝐚𝐫𝐦𝐨𝐧𝐢𝐬𝐞 Signals Conflicting messages kill momentum. → Start every update with “Here is what we are all saying about this change.” 𝐀 = 𝐀𝐧𝐜𝐡𝐨𝐫 Behaviors If behavior doesn’t shift, nothing shifts. → Show one concrete example of what “good” looks like. 𝐍 = 𝐍𝐚𝐯𝐢𝐠𝐚𝐭𝐞 Impacts Unseen ripple effects create resistance. → Ask “Who pays the price of this change?” and plan for them. 𝐆 = 𝐆𝐮𝐢𝐝𝐞 Adoption The first weeks determine everything. → Run a “first-10-days” support sprint. 𝐄 = 𝐄𝐦𝐛𝐞𝐝 the Future State A change is real only when the old way disappears. → Tie one governance metric to the new behavior. This is the shift from executor to strategic partner. You stop announcing change and start enabling it. --- Next (and final) in the series: #7 Continuous Improvement where evolution becomes a habit instead of an event. --- ♻ Repost if this helped you rethink change enablement! 📌 DM me if you want the high-resolution PDFs 👋 Follow me for more Career Transformation 👉 Ready to move forward? Work with me: https://lnkd.in/dWgE53x2

In almost every data and AI strategy I’ve led, the hardest problem was never the technology. It was the people who didn’t want it. Every organisation has them and I often label them as "detractors". They aren't villains and certainly aren't incompetent. In fact, they are often experienced operators who understand how the place really works. Treat them as obstacles and they will become one. Treat them as stakeholders and they frequently become your strongest allies. Well, that's the idea! Over time I’ve noticed recognisable patterns: The Historian: “We tried this before. It failed.” They are not blocking you; they are protecting the organisation from repeating a mistake. #Strategy: ask them to explain the failure in detail and incorporate one of their lessons into the plan. Respect converts memory into advocacy. The Territorialist: Quietly concerned about loss of authority, budget, or influence.#Strategy: give them ownership of a visible component. People rarely undermine a system that carries their name. The Perfectionist: Endless questions, dismantles every slide. #Strategy: make them part of the design review. Channel criticism into quality assurance and you gain a risk manager for free. The Detached Expert: Supportive in principle, never available in practice. #Strategy: don’t schedule meetings. Ask for a single judgement call. Experts respond to being needed, not invited. The Sceptic: Believes the programme is another management fad. #Strategy: don’t sell vision, deliver a small operational win. Evidence persuades faster than enthusiasm. The mistake people tend to make is to try and remove this friction. But friction is information, because detractors often understand operational reality better than the project team. The strategy that survives them is the one that survives the business. Practical tactics: 👉Share early drafts, not polished decks 👉Ask for criticism before approval 👉Credit them publicly when they improve the plan 👉Involve them in value efforts, not just governance 👉Never surprise them in steering committees Most resistance comes from exclusion, not disagreement. What if they still won’t come to the table? Change the table. Implement a small improvement in their area. Remove a daily pain point. Let results introduce the strategy for you. Nothing converts a critic faster than discovering the new process improved their Monday morning. Of course they may still refuse to come to the table. At that point it is no longer a strategy issue, it is leadership alignment. An operating model cannot be optional. - Supporters help you launch. - Detractors help you succeed. Bring them closer. Many future champions are simply cautious professionals wearing protective armour. Are detractors actually a problem or a signal your strategy hasn’t met reality yet?

The success of your modernization effort won't be measured by lines of code.   It will be measured by user adoption.   If the system is brilliant but the users hate it, the project failed.   This is why our delivery model integrates change management from day one. We don't just build the tool; we build the path to adoption.   We ensure the system solves real problems for the people using it, so they actually want to use it.   Because working software in production is only half the battle. The other half is getting people to log in.   If user adoption is your biggest hurdle, let's have a conversation.

Training Isn't a "Side Thing" in Your F&O Implementation. Elif Item, MCT, MVP has run major D365 F&O implementations for 15 years. She's seen the pattern repeat over and over: projects treat change management and training as separate from the actual implementation work. That separation is killing adoption. We discussed why successful F&O implementations embed training into every project task rather than treating it as an add-on. Because here's the reality: you can have perfect technology, but if people don't use it, you won't get the ROI you promised the board. Three take aways about F&O training that you won't hear often: 1️⃣ Training isn't free just because you use internal resources. The "train the trainer" model sounds budget-friendly until you realize those internal champions still have their day jobs. Expecting them to build comprehensive training programs alongside their regular responsibilities is setting them up to fail. Training will cost you money and time whether you hire externally or do it internally. Plan for it. 2️⃣ The sales process sets you up for this mistake. Microsoft and implementation partners typically separate change management costs from implementation costs in their proposals. This makes the core implementation price look better, but it creates the illusion that training is optional or can be handled "later." By the time "later" arrives, you're already behind schedule and over budget. 3️⃣ Project management experience predicts training success. Elif noticed that customers with PM teams who've implemented ERPs before (even non-D365 systems) immediately understand that adoption drives outcomes. They demand better training plans. They push back on inadequate resources. They seek out specialists when the partner's plan feels thin. If you're implementing F&O and your project plan treats training as a line item rather than a core workstream, you're not planning for success. How is training and change management structured in your current or recent D365 implementation? Is it embedded in the project plan, or treated as a separate track?

If you’re in the AEC industry, you've heard it countless times: "Digitize or get left behind." Easier said than done, right? Having navigated both sides of this shift, from boots and hardhat in the field to working in AEC tech, I know firsthand that the transition can feel overwhelming. But here’s the secret: digitizing your workflows doesn't have to disrupt your entire operation. Instead, think of it as unlocking new levels of efficiency, accuracy, collaboration and reducing risk. Here are a few practical steps I've found based on my AEC experience and also change management training that can be crucial for successful digital transformation and change management in AEC: Start Small & Scale Up Don't overhaul everything at once. Begin with high-impact, low-disruption areas—like field data collection or site inspections. Prioritize Ease of Use Pick digital tools your team can adopt easily. Remember, the goal isn't complexity; it's clarity. If your tech requires extensive training, reconsider your choice. Clear Communication Wins Your team must understand the "why" behind digitization—not just the "how." Show them tangible benefits: fewer errors, saved hours, improved communication. Make it relatable and practical. Champions & Support Identify internal champions who are excited about tech and can help lead the transition. They’ll be crucial in troubleshooting, encouraging adoption, and providing peer-to-peer support. Integrate & Automate Use digital tools and workflows tools that integrate with existing systems. Integrations with platforms like Autodesk Construction Cloud or Procore not only enhance efficiency but also minimize disruptions to existing workflows. Feedback Loops Regularly check in with your team to understand their experiences and adjust your strategy accordingly. Digitization isn’t a one-and-done; it’s a journey of continuous improvement. Its been said many times before, evolution, not revolution. Embracing digital transformation thoughtfully can boost your team’s productivity and reduce project risks. Change is rarely easy, but with the right approach, it becomes manageable and beneficial.

Your ERP went live successfully. So why is your team still using spreadsheets? I once led an ERP implementation where every decision took forever.  The company's mode of operation was to build consensus on everything. It stretched the project timeline out by months.  But the client was willing to pay for the extended time to get it right. Their operations teams were involved in every design decision, which meant they understood the "why" behind every workflow. They had a perfect launch with over 85% adoption out of the gate.  No spreadsheets. No workarounds.  The team owned it because they built it. Last month I talked to a client who took the opposite approach. Leadership made all the decisions.  The operations teams weren't engaged until 4 months from go-live. Now they're experiencing massive resistance.  The team has zero interest.  And leadership doesn't know how to fix it. The difference between these 2 real-life scenarios comes down to one thing: 𝗼𝘄𝗻𝗲𝗿𝘀𝗵𝗶𝗽. When your team is told "this is how you'll do it now" without understanding why, they tend to put up walls. When go-live comes, they will default back to what they know. Contractors are natural problem solvers.  If they don't like how something works, even if it works fine,  they will find a workaround. But guess what? Workarounds are why you lacked standardized processes in the first place.  Once someone uses a workaround, they'll use it again.  Then someone else does the same. This is a slippery slope, and it isn't the fault of the technology.  It's simple human nature and habit. In contrast, when your team helps design the processes, they champion the system. If, like my client, you're stuck 4 months from go-live with a resistant team, here's what you can still do:  1. Stop the train.   2. Bring your operations leaders into the room.   3. Show them what's been configured and ask: "What doesn't work for how you operate?"  4. Let them redesign workflows that don't fit.   5. Explain why certain processes need to standardize.   6. Give them ownership of the solution. It might push your go-live.  It might cost more.  But the alternative is going live with a system nobody uses. Building consensus takes longer.  But if you're seeing spreadsheets six months after go-live, you'll wish you had. #ERP #ChangeManagement #ConstructionTech

Why your latest software implementation failed. The biggest reason software fails has nothing to do with the software and everything to do with adoption. You can buy the world’s greatest tool but if people don’t use it, it’s worthless. I’ve seen this for years. Companies invest in good software. Everyone agrees it’s powerful. And then… nothing changes. Why? Because software does not magically insert itself into daily work. If it’s not used every day, it has no value. And usage does not happen without implementation. People don’t avoid software because it’s bad. They avoid it because they don’t know how to use it, or how it fits into their workflow. Or when it’s supposed to replace what they already do. That missing piece is always the same. Implementation. That means: Education and training. Clear operating procedures and best practices. Customer support and coaching. Ongoing check ins, re-training, and updates. This is the part most teams ignore. Some people say, “We’ll just build it ourselves.” But who would teach people how to use it? Who sets standards? Who updates workflows when reality changes? They forget the other half of the work. They act like it doesn’t exist. We are entering a world where software is easier to build than ever. And that makes everything more complex. Software can now do far more than people can absorb on their own. Which means adoption becomes harder, not easier. I see a future where 80 percent of success is implementation. Not features, code, or clever UI. Implementation will matter more than the software itself. At Mosaic, we call it: half software, half getting you there. Make sure your software supports your implementation.