What Enterprise Consulting Taught Me About Requirements

Before I moved into Scrum and project management, I spent years in enterprise consulting working with SAP implementations. If there is one thing that world drills into you, it is this: bad requirements are the most expensive mistake you can make.

In SAP projects, a missed requirement does not just mean rework on a feature. It means reconfiguring modules, re-testing integrations, retraining users, and sometimes delaying go-lives by months. The cost of ambiguity is enormous. That pressure taught me habits I still carry today.

Write It Down, Then Validate It

Enterprise consulting taught me to never trust verbal agreements. If a stakeholder says "we need the system to handle approvals," that is not a requirement. That is a conversation starter. How many levels of approval? What happens when someone is on leave? Is there a dollar threshold that changes the workflow? You have to dig.

I learned to write requirements in a way that a developer and a business user could both read and agree on. Not user stories, not technical specs, but clear statements of business need with acceptance criteria. This skill transfers directly to product work.

The Gap Analysis Mindset

In ERP projects we always started with a gap analysis: here is what the system does out of the box, here is what the business needs, and here is the gap. I apply this thinking to every project now. What do we already have? What does the user actually need? What is the delta?

This mindset prevents scope creep because it forces you to justify every piece of new work against a baseline. It also helps with prioritization. Not every gap is worth closing.

If you are a PM who has never worked in enterprise consulting, borrow this discipline anyway. Treat your requirements like they cost ten thousand dollars each to change. Because in aggregate, they do.