Frequently Asked Questions
Straightforward software project intake FAQs about requesting work, estimating it, getting approval, and moving it into delivery.
Getting Started
It is a software delivery management (SDM) ecosystem — the all-in-one software lifecycle from a software idea through requirements, sprints, testing, and release.
A business person can explain a software change in their own words. Precision Foundry then helps the business and technical teams ask the right questions, estimate their parts of the work, make a decision, and run that approved work on a unified requirements and sprint tracker.
No. That category invites campaigns, hiring queues, and office workflows — work Foundry is not a good fit for.
Precision Foundry occupies software delivery management and unified requirements-and-sprint tracking. On G2 and Capterra it should be tagged under Requirements Gathering Software, Agile Delivery Environments, and Project Prioritization Tools — not Project Management or Work Management.
No. Precision Foundry is designed for people who know their business, even if they do not know project-management terminology.
The screens use guided questions and plain-language explanations. You provide what you know, save a draft when you are unsure, and bring in other people for the parts they know best.
Anyone involved in requesting, reviewing, approving, or delivering work can use it. For example:
- A department manager asking for a new system or process change
- An employee reporting a problem or suggesting an improvement
- A business expert explaining how the work will affect people and operations
- A technical team estimating and delivering the technology work
- A leader deciding which work should be funded or done first
Task tools are usually best after a team already knows what needs to be done. Precision Foundry helps everyone reach that point—and keeps that thread through testing.
It captures the reason for the request, fills in missing information, gathers estimates from both sides, records the approval, and then helps the delivery team break the approved idea into requirements and tasks. The QA tester verifying a release is looking at the same data thread the business user created during intake—not a ticket rewritten from a charter or email.
Why copying intake forms into Jira backlogs kills project context
Those are real projects, but Precision Foundry is not a good fit for them.
Foundry treats every item as a software change that needs a story, value case, discovery, business and technical estimates, approval, and a delivery plan of requirements, epics, stories, and acceptance criteria. A campaign calendar, event runbook, or office checklist belongs in a general team tracker.
Use Foundry when you are building or changing the software that supports those operations—for example, event registration or CRM automation. Keep the day-to-day campaign or event work elsewhere.
Those are project and work-management tools. Precision Foundry is a software delivery management ecosystem — not an alternative for campaigns or office work.
Jira plans and tracks work items. Asana is work management for tasks, projects, and workflows. Leantime combines strategy canvases with project execution. Foundry is where Business and IT figure out a software request, estimate both sides, decide, and then deliver that work on Foundry’s board, sprints, testing, and release. Another tracker is optional.
Why copying intake forms into Jira backlogs kills project context
Why Asana Forms are the wrong software intake
Yes. That is optional coexistence: Foundry is the front-end filter, and Jira can stay the work-item system of record.
Engineering can keep the Atlassian suite they already paid for. Precision Foundry runs the Business–IT gate—story, both estimates, and a recorded yes—then has native delivery boards so a Jira copy is optional. If the contract requires Jira, point work items at the Foundry thread instead of pasting the story into a new description.
Use Precision Foundry with Jira
Requesting Work
- Choose Project for a larger new idea that needs review, estimates, and approval.
- Choose Enhancement when you want to improve something that already exists.
- Choose Issue when something is broken, incorrect, or causing a problem now.
You do not have to complete everything at once.
Finish the questions, both estimates, and a recorded yes. Do not schedule a kickoff week.
Start from a complete software request. Ask project-specific questions on that same record. Close the answers that would change the build, or leave them visibly open. Estimate business and technical effort against a first-release boundary, then record a yes, no, or not yet before anyone opens a sprint. A kickoff week, a sprint zero, and a Definition of Ready checklist are not the phase.
That is normal.
Save what you know as a draft. The guided questions can point out what is missing, and you can ask another person to help with answers about their department, system, cost, or process.
Detailed requirements belong in the Delivery Project after the work is approved.
The Project in the portfolio is the proposal: what the organization may do, why it matters, and roughly what it will take. Delivery is where the team works out exactly what must be built or changed. Those answers stay on the same record as intake, so product, developers, and QA are not maintaining three versions of the story.
How to stop requirement drift between product managers and developers
Estimates and Approval
Because the work is rarely only technical.
A technical team may need time to configure a system, move data, test, or build software. The business may also need time for training, communication, procedure changes, vendor coordination, data cleanup, and helping people adopt the change. Seeing both estimates gives leaders a more honest picture of the total effort.
Because they usually size only the code.
Story points and a hallway date ignore training, process change, legal review, and work that was never in the request. Pair a business estimate with the technical estimate against a first-release boundary, then record a yes that cites both numbers. A developer range is not a calendar commitment.
Estimate the work your department will need to do—not the technology work.
- Employee time spent answering questions or reviewing work
- Training and communication
- Changes to policies or day-to-day processes
- Data cleanup or preparation
- Vendor or outside-service costs
- Legal, compliance, or finance review
- Support during launch and adoption
The Business Effort helper walks through these areas, so you do not have to remember them on your own.
Write the first-release boundary before anyone opens a sprint.
Scope that shows up in sprint planning usually started earlier: a vague request, no exclusions, and tickets created to discover the work. Capture the problem and outcome, review the requirements that change behavior, estimate both sides, and record a yes against that first release. New ideas become a later increment or a new request.
Keep one data thread. Do not let each role rewrite the request.
Scope creep adds unapproved work. Requirement drift changes the meaning of work that was already approved—because the PM brief, the developer tickets, and the QA checklist became three stories. Trace stories to reviewed answers, put new decisions back on that record, and have testers open the same intake the business user wrote.
How to stop requirement drift between product managers and developers
The Technical Effort estimate covers the expected size, complexity, length of time, systems affected, teams needed, confidence level, and important unknowns. It is a high-level estimate for making a decision, not a promise of an exact completion date.
Yes.
Business users can estimate their own department's effort, while technical users estimate the technology work. A person can do either or both when their assigned permissions allow it.
The approval decision becomes available after both Business Effort and Technical Effort have been submitted. Until then, the Estimate Queue shows which side still needs attention.
The Estimate Queue has separate Business and Technical views. Each view shows estimates that still need work, are in progress, or are completed, plus aging work that has been waiting 7 or more days.
People and Access
A role is simply the kind of work a person is allowed to do in Precision Foundry.
For example, one person may submit ideas, another may provide estimates, and a leader may approve work. Roles keep each person focused on the screens and actions that apply to them.
Yes.
This is common in smaller organizations. Someone might submit requests, provide a business estimate, and approve work. An administrator can use the permission setup guide to choose the jobs that fit that person.
Your assigned role may not include that type of work, or the Project may be locked because it has already been approved. Ask your organization administrator if you believe you need additional access.
AI Help
It helps you think through the work; it does not make the decision for you.
It can point out missing information, suggest questions, and draft items such as requirements, stories, acceptance criteria, and tasks. Think of it as a helpful first draft that your team reviews.
Yes—always.
Your team can edit, accept, or reject AI-generated content. AI suggestions do not approve projects, assign funding, or replace a person's judgment.
No.
AI does not know your organization the way your employees do. It helps with first drafts and follow-up questions so your business and technical experts can spend more time making good decisions.
Your subscription includes an AI allowance. Precision Foundry shows the amount included, used, and remaining in dollars, so you do not have to understand tokens or model terminology.
Trial and Pricing
Yes. The Professional plan includes a 7-day free trial so you can walk an idea through the workflow—from explaining the request through estimates, a decision, and delivery planning.
Yes. A payment method is required when the trial begins, but you are not charged for the Professional subscription until the trial ends.
Additional AI use is billed at actual OpenAI cost plus 25%. Usage is shown in dollars—included, used, and remaining—so you can see the cost as it accumulates rather than discovering an unexplained charge later.
It depends on the plan. Starter includes one user and does not allow additional seats. Professional is billed per seat for up to 9 users — we recommend upgrading to Team at 8 users. Team includes 10 users and lets you add more.
Your Information
Your organization keeps ownership of its project information and the content created with AI.
No.
Your organization's project information is not used to train public AI models.
Yes.
Delivery requirements and technical design documents can be exported as PDF for sharing, review, or use outside Precision Foundry. Technical design PDFs are available in draft and completed states.
Ready to see it in action?
Start a 7-day Professional trial and walk a real idea from review through estimates, a decision, and delivery planning.