Can You Improve Proposal Operations Without a Process Engineer?
The short answer is yes.
The better question is: How will you know whether you've improved the right things?
Proposal teams absolutely understand their pain points. They know where the process feels slow. They know where people are frustrated. They know where deadlines are missed, content is difficult to find, reporting is inconsistent, or software isn't being fully utilized.
Many teams are facing mandates to make improvements. From what I’m hearing, these talented proposal teams are facing benchmarks and KPIs that they very much want to meet or exceed. Ironically, the same expertise that makes teams effective can also make it difficult to challenge the assumptions built into their current processes.
The people closest to the work often have the clearest view of the symptoms. In quality management, there's an old saying: "The expert is the one within 20 feet of the problem." The challenge is that proximity provides deep insight into the symptoms, but not always the broader system that created them.
It’s hard to think outside the box when you’re working in the very paradigm that needs to change.
Identifying operational friction and designing scalable systems are different skill sets. Most proposal teams do not have access to the core knowledge, principles, and experience that come with thousands of hours of engineering processes.
Symptoms and Causes Are Not Always the Same
I've seen organizations invest months in redesigning processes only to discover that the original problem still exists.
Why?
Because they solved the symptom instead of the cause.
A team believes the problem is poor communication.
The root cause turns out to be unclear roles and responsibilities.
A team believes the problem is slow proposal turnaround times.
The root cause turns out to be a lack of content governance and approval workflows.
A team believes the problem is inefficient meetings.
The root cause turns out to be a lack of visibility into project status and inconsistent use of existing tools.
These are very different problems that require very different solutions.
I've seen an organization spend years developing a proposal content library, only to discover that it had optimized the system for one person instead of the organization. The library worked because that individual knew exactly where everything was. Everyone else struggled. When that employee moved on, the organization spent more than a year redesigning and rebuilding the library.
The original problem wasn't technology or content. It was the system design. The organization had unintentionally built a process that depended on institutional knowledge rather than creating one that could scale beyond a single individual.
The Challenge of Knowing What You Missed
Most organizations don't struggle because they lack intelligent people.
They struggle because operational systems are interconnected.
A change in one area often impacts several others:
Process
Governance
Reporting
Roles and responsibilities
Technology utilization
Training
Adoption
Metrics
Integrations
Change management
Improving one element in isolation can unintentionally create friction somewhere else. This is one of the reasons internal process improvement efforts can become frustrating. Teams may successfully fix the issue they can see while unknowingly creating new issues elsewhere.
Experience Changes the Questions You Ask
One of the greatest values of experience is knowing what questions to ask.
How will this process work when your proposal volume doubles?
What happens when a key employee leaves?
Will your reporting still work six months from now?
Does your governance model support the behavior you're trying to encourage?
Are your tools configured to support the process, or are people creating workarounds?
How will new employees learn the system?
These questions rarely emerge during a brainstorming session about immediate pain points. They emerge from seeing similar challenges repeatedly across different organizations and industries. They emerge when you've seen organizations solve the same problem three, five, or ten different ways—and observed which solutions actually sustained performance over time.
The Cost of Getting It Wrong
Most operational decisions are not permanent. They can be changed. The question is: “At what cost?”
The cost of getting it wrong may include:
Months of rework
Lost productivity
Poor adoption
Duplicate work
Frustrated employees
Underutilized software investments
Inconsistent reporting
Delayed growth initiatives
Organizations often discover these costs only after implementation. After the software has been purchased, the new roles have been assigned, and the contracts have been signed. By then, the organization isn't simply redesigning a process. It's redesigning the redesign.
So, Can Your Team Do Its Own Process Improvement?
Absolutely.
Many organizations should be deeply involved in improving their own operations. No consultant knows your business better than you do.
Engineering and operational experience bring something different. They bring perspective. They bring pattern recognition. They bring an understanding of dependencies, tradeoffs, and unintended consequences.
Most importantly, it helps answer a difficult question: How do you know what you missed?
Because the most expensive operational problems are often the ones you don't discover until after you've implemented the solution.
If you're redesigning your proposal operations, a second set of experienced eyes can prevent expensive rework.
Sometimes the greatest value of a process engineer isn't providing the answer.
It's helping organizations see the questions they didn't know to ask.
