How to Scope Engineering Tasks Professionally

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 watched CEOs spend enormous sums fixing "broken" software teams when the real problem cost a fraction to solve. All because they were missing a critical planning tool most companies overlook. What's missing here? A properly built 𝐒𝐜𝐨𝐩𝐞 𝐨𝐟 𝐖𝐨𝐫𝐤 document. When executives see declining velocity, missed deadlines, and frustrated teams, the knee-jerk reaction is to: • Hire more developers • Replace leadership • Adopt a new methodology • Rebuild from scratch Yet in my experience, the core issue is often much simpler: 𝐩𝐨𝐨𝐫𝐥𝐲 𝐝𝐞𝐟𝐢𝐧𝐞𝐝 𝐬𝐜𝐨𝐩𝐞 𝐚𝐧𝐝 𝐞𝐱𝐩𝐞𝐜𝐭𝐚𝐭𝐢𝐨𝐧𝐬. A comprehensive Scope of Work is the foundation of any successful piece of software. When teams and stakeholders have different mental models of what "done" looks like, no amount of talent or resources can bridge that gap. That’s why you absolutely need rigorous SOW practices that: ✅ Define clear deliverables with measurable acceptance criteria ✅ Establish realistic timelines based on complexity, not wishful thinking ✅ Document assumptions and dependencies explicitly ✅ Include change management processes that protect both business needs and engineering reality ✅ Create alignment between business objectives and technical implementation One enterprise client I advised was about to replace their entire development team (7-figures in transition costs). After implementing proper scoping practices and realignment workshops, the same team delivered on expectations within just a few months. The math is crystal clear - Investing in proper scope definition should be a non-negotiable, a business imperative with ROI that outperforms most other interventions. Leaders: before you overhaul your team or platform, ask if you've given them the clarity they need to succeed.

If you're looking to build a custom software solution for your organization, here's how to scope the project the right way to avoid scope creep. Because jumping into development without a well-defined scope is like starting construction with no blueprint. You’ll build something, but it may not be what the business actually needs. At BNMA, we’ve scoped and delivered dozens of custom software solutions — from fast-moving $100K MVPs to multi-phase enterprise platforms. Here's the process we follow to set projects up for success. Step 1: Start with the business case Ask: → What are we trying to improve? → How will we measure success? For example: “Reduce manual data entry by 70%” or “Give PMs real-time job costing insights." As a side note, look closely at the areas where your team is using spreadsheets to make critical business decisions. That’s usually a sign there’s a workflow that’s: → Highly manual → Repetitive → Dependent on one person’s knowledge → Prone to error These are often the best opportunities for automation or custom tooling. Step 2: Map the current workflow Get in a room with the people doing the actual work. Draw it out. Sticky notes, whiteboard, Miro — doesn’t matter. What steps do they take today? Where are the bottlenecks? You’re not just digitizing a process — you’re fixing it. Step 3: Identify must-haves vs. nice-to-haves features Every project has a wishlist. But we all know, if everything is a priority, nothing is. Rank features into: - Must-have (we can’t go live without this) - Should-have (important, but not mission-critical) - Could-have (can wait until Phase 2) This step alone can save you thousands. Step 4: Define user roles and permissions Who needs to log in? What should each person see or be able to do? → PMs may need to edit budgets. → Field teams may only need to input hours or upload photos. Clarity here reduces confusion (and development cost) later. Step 5: Document system dependencies Are you connecting to QuickBooks, Procore, Acumatica or another internal tool? Get clear on where data lives, how it flows, and what needs to integrate. You want to create one data source across multiple systems. Step 6: Set constraints → What’s the timeline? → What’s the real budget? → What internal resources will support this project? Be honest. If your dev partner doesn’t know your limits, they can’t help you succeed within them. __________ Scoping is your blueprint. You don’t need a 40-page doc. Just enough clarity to avoid confusion, rework, and missed goals. And if you’re not sure how to start? Start with your internal workflows. Talk to the people in the trenches — they’ll tell you exactly what needs fixing. #customsoftwaredevelopment #automation

Automation Project - Behind-the-Scene Process Most people think getting hired only comes down to writing PLC code. But hiring managers are also looking for someone who can plan projects. They want someone who can walk up to a machine and immediately make sense of it. It's a great skill for troubleshooting a machine and planning an automation project. They will want to discover: If you can scope a project If you can mentally break a machine down If you can group I O logically If you can structure hardware and tags cleanly You instantly separate yourself from the crowd. In this video I show you how to scope a small automation project the same way professional controls engineers do. I filmed it several years ago, but the principles never change. Here is the workflow. Study the machine Before touching a laptop, just observe. Identify every component, every safety device, every axis, every motion. Watch an auto cycle Do not guess how a machine works. Watch it run. Then watch it again. Group components Bundle the HMI, switches and safety together. Then group each nest or station on its own. This keeps the program structure clean. List every I O Top to bottom and left to right. Sensors, clamps, solenoids, switches, everything. Build your hardware plan Once the I O is counted, determine the controller and the exact modules you need. This prevents mid project surprises. Organize your tags Export tags to Excel, fill in your notes, map everything cleanly, and bring it back into the controller. Professionals do not scatter their tags. This is one of the fastest ways to become valuable, because it shows you can think like an engineer, not just click through software. Watch the full walkthrough here https://lnkd.in/gJKdJ7dC If you want more real world lessons like this that help you move from beginner to automation professional, let me know in the comments. #PLCProgramming #AutomationEngineering #ControlsEngineering