How to Manage Open-Ended Engineering Projects

Most 0-to-1 projects don’t fail because teams move too slowly. They fail because teams move fast in the wrong direction. By the time they realize it, they’ve burned trust, budget, and time. There are four steps I return to every time: 1. Start with a Clear Vision, Then Break It Down You need to know where you’re going. I break the vision into 3 to 4 core pillars—outcome-oriented themes that guide both teams and partners. A good test: If we only delivered these pillars, would the customer clearly benefit? 2. Design an Operating Model, Not Just a Roadmap I’ve seen teams spend months building features, only to find three different groups thought they owned the same customer experience. A written operating model prevents this. Most leaders skip it because it feels like overhead. It’s not. Clarify: • What do you own versus your team and your partners? • What are the working norms? • How are decisions made and surfaced? 3. Ask Before You Answer Early in 0-to-1, you’re not managing execution. You’re managing uncertainty. Questions are how you surface what the team doesn’t know yet but needs to figure out before making real commitments. Ask: • What are the key unknowns? • What decisions must be made now, and which can wait? • How will we know what we’re building actually works? 4. Prove Something Works End to End Before you go big, test something small. “End to end” doesn’t mean polished. It means a real user completing a real workflow—without you in the room to explain it. If you have to be there for it to work, you haven’t proven anything yet. Even if it’s rough or manual behind the scenes, this kind of test exposes the gaps fast. The best 0-to-1 leaders I’ve worked with all share one trait: They’re willing to feel slow early in order to move fast later. The foundation always pays back—but only if you build it.

The biggest mistake in large engineering projects is thinking they are only technical decisions. In reality, they are decisions about risk, timing, and long term consequences. Over the years while building and executing industrial projects at SES, I have noticed something interesting. One large project can quietly move a company several years forward. The wrong one can do the exact opposite. Not immediately, but slowly through stretched teams, cash pressure, and execution fatigue. The difference is rarely intelligence. It usually comes down to the way the opportunity is evaluated before saying yes. When I look at large scale engineering opportunities, I try to step back and think through a few simple principles that keep the decision grounded. First. Strategic fit before revenue. ↳ A project may look attractive on paper, but if it does not strengthen our capabilities or move us closer to the kind of work we want to be known for, revenue alone is not a strong enough reason to pursue it. Second. Thinking beyond the first outcome. ↳ The first year of a project usually looks manageable. The real pressure often comes later through delayed payments, working capital stretch, regulatory challenges, or client concentration. Looking ahead helps avoid surprises. Third. Reversible and irreversible decisions. ↳ Some decisions can be corrected quickly. Others stay with you for years. Large capital commitments, technology bets, or long term contracts need far deeper thinking than decisions that can be adjusted easily. Fourth. Margin for the unexpected. ↳ In engineering projects, timelines shift and costs change. If a project only works when everything goes perfectly, it is probably too fragile. Fifth. The uncomfortable question. ↳ Before moving ahead, I sometimes ask the team to imagine that the project did not work out three years later. The reasons people share in that discussion are often more revealing than any presentation. One more thing I always remind myself. ↳ Look carefully at who carries the downside risk. Over time I have realised that leaders are not just approving projects. They are deciding where the organisation’s capital, reputation, and energy will go. Not every opportunity deserves execution. Not every growth opportunity is strategic. And sometimes the most important decision a leader makes is simply choosing not to proceed.

For 10 years as a construction engineer, I would plan any package of work like this… 1. Lay out a structure Break down the scope into logical chunks. Usually, these are physical components (Pile cap, headstock, bridge deck etc.). But not always. However YOU think about the scope is best for the rest of the steps to flow. Planners would call this the WBS, but who needs the jargon. 2. List the tasks Virtually build the components in your mind and just list the steps. Don’t worry about relationships, durations, calendars or anything else - it will only break your flow. Get the steps down in order. 3. Add relationships Link together the tasks to make sequences. Focus on physical constraints (what planners would call “hard logic”) rather than sequences of crews or equipment. For example, the road surface needs to be done between the line marking… that kinda stuff. 4. Estimate durations Give your best guesstimate of durations for all the tasks. It’ll be wrong approximately 100% of the time, but you need to start somewhere. If you are completely at a loss, grab a foreman or site supervisor, they love estimating durations 😉 5. Add constrained resources Don’t bother adding every resource each task needs (you don’t have the time). But, most engineers know if their project has a limited concrete supply, struggles to get enough electricians or has space constraints on site. Add this information to your tasks and check for conflicts. 6. Verify durations and optimise the sequence. Ok, now you need help. Get the most experienced people in your team together (sure, get your manager but supervisors and leading hands are better) and walk through the sequences. Ask for validation of durations and search for ways to pull things forward. This will usually kick off a discussion about crew sizes and their flow. Add this to your plan as you update the durations. Ps. This resource step is super easy if you are doing this in Aphex. 7. Prepare the plan for communication. You have a plan that the right people are bought into. Now, you need everyone to understand it. If you have subcontracted teams, assign them. If you need a QA inspector, assign them. If you need… you get it. 8. Communicate, communicate, communicate. Host a briefing session to run through the plan, recap short-term sequences at pre-start meetings, consistently update the plan and reissue it to everyone. Keep repeating the plans until you are sick of hearing your own voice. For over a decade, I found this was the fastest way to build a workable plan. It works in Aphex, in a spreadsheet, on on a whiteboard, or using slate and chalk for that matter.

I've trained 600+ project managers over the last 3 years. From budding teams in start-ups to large-scale projects in multinational corporations. Hre are 9 challenges and recommendations frequently shared. 1) Scope Creep Management It's daunting when project deliverables keep changing. Without clear boundaries and pushback, projects will derail. Highly recommend reading "Scope and Requirements Management" and "Effective PM and BA Role Collaboration" to solidify your scope management strategies. 2) Time Management Effective PMs understand that every minute counts. Design an “Ideal Project Week” and schedule critical tasks. Risk assessment? Schedule it. Stakeholder meeting? Schedule it. Documentation review? Schedule it. 3) Stakeholder Engagement Project Managers need to skillfully manage stakeholder expectations. Instead of just updating on progress, send out agendas ahead of stakeholder meetings. Focus on critical discussion points, and be prepared to address the top concerns. 4) Resource Allocation It's tempting to bring in the best talents, but ensure they align with the project's current needs. Don’t bring in a high-level consultant when you need hands-on expertise on the ground. 5) Driving Team Accountability Inconsistent team updates and feedback loops can hurt a project's momentum. As the PM authority, establish regular checkpoints. Embrace the mantra: “Consistency is the heartbeat of projects.” 6) Clear Project Objectives If stakeholders or team members can't quickly summarize the project's goal and outcomes, there’s a clarity issue. Consider methodologies like SMART goals to crystallize your objectives. 7) Handling Conflicts Project disputes, if not addressed promptly, can escalate and impact delivery. Address conflicts head-on. Familiarize yourself with techniques from "Crucial Conversations" for effective resolution. 8) Budgeting Managing finances is critical. A well-told narrative about your project’s ROI and value proposition is invaluable. Understand your budget's narrative, including how resources are allocated, potential ROI, and long-term project benefits. This narrative informs future budgeting decisions. 9) Project Strategy Many project managers grapple with succinctly defining their approach. A clearly articulated strategy not only provides direction but aids in stakeholder buy-in. I highly recommend diving into the "Project Management Body of Knowledge (PMBOK)" to sharpen your strategic skills. How do you prioritize and balance stakeholder engagement with ensuring timely project delivery, especially when faced with conflicting interests?

In project management, it’s rarely the workload that burns you out, it’s the open loops. It’s not the number of hours you work. It’s not the pressure of deadlines. It’s the small, invisible things that pile up in your head, the message waiting for a reply, the decision that’s still “pending,” the update you’ve been meaning to send since Monday. You tell yourself you’ll do it later. And maybe you will. But until you do, it keeps draining you. Every open loop steals focus. It interrupts your flow, eats your energy, and quietly builds that mental tension you can’t name but always feel. I’ve been there, running multiple projects, crossing tasks off every day, and still ending the week with that heavy sense that something was off. That’s when I realized: it wasn’t the workload. It was the weight of unfinished communication. The truth is, project management isn’t just about tracking what’s done. It’s about bringing closure to what’s not. Here’s what changed everything for me: I started treating every open loop as a blocker, even if it’s “just” a message. I set aside 15 minutes a day to close them, no meetings, no multitasking. I learned to make small decisions fast, instead of carrying them around for days. I started ending meetings with one clear question: “Who owns this next?” I stopped letting “I’ll circle back later” become a default response. And something shifted. Less mental clutter. More trust from the team. Clearer communication. Projects started moving smoothly, not because we worked more, but because nothing got stuck. Because leadership isn’t about being busy, it’s about being clear. And clarity doesn’t come from speed. It comes from finishing what’s open. If you’re feeling overwhelmed lately, try this: Don’t add more to your list. Just close what’s already there. So, what’s one open loop you can close before today ends? -- -- If this resonated, like, comment, or share your thoughts. Follow me for more tips on project clarity and operational excellence!

Ever watched a project implode—not from bad tech or lazy teams… but because two “experts” refused to talk to each other? Or worse—thought they were aligned… while building two totally different realities? That’s not miscommunication. That’s interface management failure—the silent killer of complex projects. Most PMs obsess over timelines and budgets… …but forget the human wiring between teams, systems, and stakeholders. ↳ When Engineering speaks “code” and Marketing speaks “customer pain,” who translates? ↳ When Vendor A’s deliverables don’t plug into Vendor B’s inputs—who owns the gap? ↳ And when assumptions pile up like unread Slack messages… chaos isn’t coming. It’s already here. ☑ Great interface management isn’t about more meetings. ✓ It’s about clarity rituals: ↳ shared definitions, visual handoffs, and one source of truth. ✓ It’s appointing “boundary spanners”— ↳ people who live in the seams. ✓ It’s asking: “What does ‘done’ look like… to THEM?” ↳ before work even starts. I’ve seen $2M projects saved by a single 30-minute alignment session. And $10M ones derailed by a glossary no one agreed on. Your move: 👉 Don’t just manage tasks. Map the handshakes. 👉 Don’t assume alignment. Prove it—visually, verbally, repeatedly. 🗨️ Here’s my out-of-the-box question for you: If your project’s interfaces were physical bridges… how many would be held together by duct tape and hope? 🔁 Repost if you’ve seen a “perfect plan” collapse at the handoff. ➕ Follow Mohamed R. for no-fluff, human-first project leadership that actually ships results. P.S. The best PMs don’t just build projects—they build understanding. Start there. #ProjectManagement #InterfaceManagement #Leadership #TeamAlignment #PMOT

Software projects have their own unique ways of veering off course. I’ve watched enough projects take unexpected turns to know that it’s not only technical skill that keeps them on track but a blend of clear vision, teamwork, and focus on value. These are the practices I’ve found the most useful to stay on track: ➜ Define the scope clearly and stick to it At the outset, every project has a vision. But as development progresses, new ideas inevitably pop up, and it’s easy to expand that scope without realizing the impact on deadlines or budgets. I’ve learned that clear scope management upfront is the foundation of a successful project. Before we dive in, we define what’s in and out of scope and stay accountable. ➜ Keep the user as the guiding focus It’s easy to get caught up in adding “nice-to-have” features, but the user should drive every decision. What will make the software more useful? What features add real value? When I see projects struggle, it’s often because they’ve lost sight of what the user needs. Regular user testing and feedback loops throughout development keep the project grounded. ➜ Build a well-rounded team from the start A common mistake is waiting too long to involve key team members like design, engineering, QA, and customer support. Each of them brings a unique perspective to the project. I’ve found that involving a complete team from day one helps make better decisions and keeps the project aligned with its goals. This approach strengthens the project and ensures all aspects are considered. Even with the best planning, unexpected challenges will arise. What keeps projects on track is the ability to adapt while staying focused on the big picture. #flexmade #softwareprojectmanagement #projectmanagement #ceotips #leadership

If you are only technically strong, it will not help you in project management. You must have enough management skills to deliver your project. Sometimes, even being over technically strong weakens your decisions related to management. At the same time, if you don't have knowledge of the site/field and again, you can not deliver the project if you are only an email boy. The key to success is in between. You must have enough knowledge of site/field and, at the same time, enough skills related to communication/ management /stakeholder engagement and soft skills like emotional intelligence, etc . So, the balance is important. Sometimes, for rush projects, you have to take bold decisions, which is a test of your management/leadership skills. Technical Guys/Subject Matter experts have a different domain of thinking, but you as a project manager should consider all aspects related to the delivery of the project and to ensure benefits realization of the business case. I will give you a real time example, in the project initiation phase, your target is to finalize the POs for major equipment and long lead items as soon as possible as the design will not start without that. If 98% things are ok and only 2% stuff requires some technical exercise/negotiation, then your target should be to finalize the PO first and risk of 2% uncertainty will be managed along with. But if you are stuck on only that 2% aspect of the PO or items, you are putting the overall project at risk to lose the critical path. In a nutshell, expert judgment should be hybridized with management skills to deliver projects on time in the best interest of all stakeholders. Regards TABRAIZ AHMED ALVI HV PROJECTS MANAGER MS-EE, PMP, RMP JEDDAH, KSA 05.11.2024

In our fast-paced world, projects can easily fall into limbo when scopes are ill-defined.    I was speaking recently about this because it's a trap I’ve seen time and again: the team is motivated, the idea is strong, but the lack of clarity can lead to endless iteration.   Here’s what helps:   🔑 Appoint a Lead: Every project needs a responsible leader who has the authority to make decisions and push progress. Without a lead, responsibility is diffused, and momentum stalls.   🎯 Define the Scope: It’s easy to “wishcast” every possible outcome onto a project, but unrealistic expectations lead to disappointment. A well-defined scope ensures the team is aligned and focused on what truly matters.   🚀 Set Clear Goals: While the path may evolve, you should always know where you're heading. What key questions are you looking to answer? Keeping the end goal in sight helps avoid distractions.   👥 Clarify Roles: Who’s contributing to the project, and in what capacity? Clear roles prevent confusion and keep everyone accountable.   📅 Consistent Check-Ins: Regular progress updates keep projects on track, but constant communication is even more important. Keep the feedback loop open to ensure alignment and course correction when needed.   With these steps, projects stay on course and deliver results.

When working on GTM Ops projects, it's like you are remodeling a house while people are living in it and trying not to disturb them at all. So it’s no wonder that you can get into some hairy and anxiety-filled situations when leading GTM Ops projects. At CS2 we do them all the time, and we have had our share of learnings and lots of successes. So here are some tips for those of you in the middle of some transformational GTM Ops projects at your org (or with a client if you are a consultant.) 1. Understand the level of complexity Having a good grasp of the overall complexity will give you a more realistic sense of how “hard” it will be to get your project done. For every person that needs to be involved and for every ounce of tech debt or existing process you are going to replace you will need to account for hours of project management, meetings, reporting, and undoing of process to be done. Do not underestimate this and if anything, expect more than you think. 2. Communicate - effectively and often.     One of the best ways to tackle project complexity is with good communication. This might mean having a weekly “interlock” team of stakeholders that frequently give updates on progress and timelines, sending weekly status updates in a fashion that everyone understands, and leaving enough time for a lot of workshopping and education for your stakeholders before deciding on any solutions. Ensuring that your key stakeholders are educated and “sign off” on what is being done will save you headaches down the road. Also, communicating with your stakeholders early when you foresee risks will also save you time and ensure it actually gets done. 3. Don’t fall victim to “Death by Committee” This might seem contrary to my suggestion above, but as much as you want to work cross-functionally and educate your key stakeholders, you need to be mindful of who will have an opinion and can make key decisions. Involve enough folks who will be impacted by the changes and can help inform the right decisions, but involving too many people will make your project drag out way longer than it should. And in the end, you need to be responsible for making a decision despite having varying opinions. 4. Understand your environment and take all necessary precautions This kind of goes without saying, but since we are remodeling a house with people living in it, you need to understand how you can get the work done with little impact or disruption to anyone or anything. Do a thorough enough audit of all things that can be impacted. Communicate how you will make your changes to teams who could be impacted. Always make sure to develop in a controlled environment, like a sandbox, where you can do as much testing and QA as possible. There are so many other tips I could share but these stand out at the top. As you can see from this list, soft skills really matter in GTM Ops!