Nufacturing - inventory and operations management PRD

The brief

Nufacturing manufactures supplements under FDA audit. Inventory, vendor qualification, production scheduling, sales quoting and compliance records each lived in a different place, so nobody could see the operation as a whole. The CEO wanted one system instead of five, but the harder question was what that system actually had to do - and which of the current records could not be lost on the way.

My role

This was paid contract work through Gallimore Software, from October 2024 to January 2025. I was the sole analyst on the engagement. My job was to understand the current operation and turn it into a Product Requirements Document a development team could build from. Vendor selection, the build itself and implementation were outside my scope.

What I did

I ran two recorded elicitation sessions with the CEO - 31 minutes on 23 October and 1 hour 11 minutes on 30 October 2024 - walking through the legacy system screen by screen. The useful part was the awkward questions: what happens to a lot that has sat unused for six months, whether first-in-first-out should pull from an expired lot, what "par level" means here, and how the six stock states relate to each other.

I then analysed the company's own 660-row physical inventory worksheet, which compared two stocktake dates in September and December 2024 with vendor, lot number, unit cost and total value on every line. That meant the requirements described the stock, vendor and costing problems the business actually had, rather than the ones I would have assumed.

The output

A twelve-section PRD, version 1.0, dated 27 December 2024: purpose, background, objectives, scope, user stories, functional requirements, detailed functional requirements, non-functional requirements, assumptions and dependencies, risks, timeline and appendix. Nine user stories in "as a role, I want this so that" form cover warehouse, operations, quality, purchasing, production, sales, customer service and compliance perspectives, connecting daily work to system behaviour across six modules.

Every module carries a paragraph explaining why the business needs it, so a reader can tell a requirement from a feature request. Five non-functional requirements are specific: an interface usable by diverse roles, real-time updates, 1,000 concurrent users, role-based access control with encryption, and 99.9% uptime. The risk section names data-migration inaccuracy, user resistance to workflow change and compliance failure. Predictive AI scheduling and marketplace integrations are named as out of scope and deferred. The delivery plan runs sixteen weeks across four phases: two for requirements and design, eight for core modules, four for testing and feedback, two for deployment and training.

What happened next

I delivered the PRD as the requirements package for the proposed build. The build did not proceed on the vendor side, so the system was never developed. The document still shows the decisions, boundaries and delivery detail needed to take the work forward.

One reflection

The section I would defend hardest is the shortest one: what the system will not do. Naming predictive scheduling and marketplace integrations as out of scope took ten minutes to write and removed the two things most likely to expand the project quietly. Scope is easier to hold when it has already been written down and agreed.