Signs Your Company Needs a Formal Project Submission Process

I’ve watched small teams resist a formal project submission process because they feared bureaucracy. Then they ran the real portfolio through memory, interruption, and the last person who spoke to engineering.

Formal does not have to mean heavy. It means the request has a known door, a minimum story, a visible review, and a recorded decision. If your company lacks those four things, you already have a process. It is merely informal enough to deny.

The following signs mean the hidden process is charging more than a simple one would.

Requests arrive wherever somebody can catch a person

Hallways, chat messages, meeting endings, forwarded emails, and direct developer conversations all create work. Nobody can count total demand because the demand lives in other people’s attention.

One department head who believed she had submitted six requests. Technology could find two. The other four were not lost in software. They had never crossed a boundary that made them real.

A formal path gives every request a stable record. The conversation can happen anywhere. The work begins in one place.

Teams start before the problem can be retold

If a developer receives a solution sentence without the current workweek behind it, intake has failed. “Add approvals” may mean fraud risk, a manager’s preference, or an audit observation. Those are different projects.

Require what happens today, who is affected, what goes wrong, what better looks like, and who owns the follow-up. Put those facts into software project intake before estimation or kickoff.

Formal intake should reduce premature detail. If your form demands a vendor and launch date, it is formalizing fiction.

Priority changes with the room

The ranked list changes after every leadership conversation. Quiet operational work waits behind visible initiatives. Teams keep several projects “active” because nobody wants to record a no.

That is a demand-management problem, not a motivation problem. Compare strategic alignment, impact, timing, confidence, and total capacity in the same review. Record who chose the tradeoff.

I have watched a portfolio turn green because every hard decision moved to “pending.” The color improved. The queue did not.

Project managers spend their time reconstructing requests

Project managers can coordinate dependencies, risk, budgets, and delivery. They should not have to interview five people to discover why a request exists before coordination can begin.

When every submission needs a professional translator, the process has confused polish with readiness. A stranger should understand the story. It does not need to sound like a charter.

The Anti-PMO playbook for software intake is the lighter alternative: define who submits, what ready means, who reviews, and which artifacts you refuse to recreate.

Capacity surprises appear after approval

Projects are approved against engineering hours while operations, training, policy, procurement, and support remain invisible. The business then “fails to adopt” a change it was never given capacity to absorb.

A formal submission process does not need a perfect estimate. It needs an honest list of who must participate and what cannot move. That is enough to stop an approval from pretending the entire company is available next Tuesday.

If these signs are already familiar, move to how to fix a broken business project intake process. Diagnosis should end when the first boundary is ready to change.

Use the free Project Intake Evaluation Worksheet to score the current path, find shadow channels, and choose the first boundary to repair.

You need a formal process when demand can become work without becoming visible. Keep it small. One door. Five facts. One review. One recorded decision. Bureaucracy begins when you add artifacts that protect none of those.