You can't.
But before you close this tab — keep reading, because understanding why will save you a headache and may actually change how you think about proposal time.
Why the System Won't Allow It
Time entered into a pillar is permanent. Proposal time is proposal time. Project time is project time. This is not an oversight or a missing feature. It is a deliberate design decision that protects the integrity of your data.
The Real Problem with Moving Proposal Time
If you're looking to move time from a proposal to a project, the instinct usually comes from a good place: the proposal won, the work is real, and it feels wrong to leave that time sitting in overhead. But here's the issue with that reasoning.
Proposal time doesn't belong to the project that won. It belongs to the act of pursuing work.
Consider a realistic scenario: your team spends time on five proposals. Three become projects. Two do not. Had your team not pursued all five, they likely would not have won the three they did. The relationships built, the thinking done, the pricing developed — all of that created the conditions for winning.
If you move the time from the three winning proposals into their respective projects, you have:
Understated the true cost of business development
Overstated the direct labor cost of those three projects
Made the two lost proposals look like pure waste, when they were part of the same effort
Created a false picture of how you actually win work
Proposal Time Is Overhead — By Definition
Business development and proposal writing are indirect costs. They exist before a project is a project. The client doesn't owe you for the time you spent deciding to pursue them, writing your approach, and pricing your services. That's the cost of being in business and competing.
Treating it as direct labor after a win doesn't make it direct labor. It makes your books inaccurate.
The One Edge Case Worth Discussing
The strongest argument for moving time is: "The proposal was essentially scoping work — we were already doing the project."
This is a legitimate edge case. If a client asked for a detailed technical study or working deliverable as part of the selection process, and then awarded the work, there's an argument that the time was direct from the start.
But the answer to that situation is not to move the time after the fact. It's to recognize in real time that this is no longer proposal activity — and log it accordingly as the work proceeds. The pillar should reflect the nature of the work when the work was done, not the outcome you learned about later.
What to Do Instead
If you're trying to account for the cost of winning a project, the right move is to track your proposal time consistently and report on it as a cost of revenue. It becomes a part of your overhead and is included in the overhead factor and borne by all projects.
Your proposal time, logged faithfully over months and years, becomes genuinely useful data:
What does it cost us to win a project?
Which types of pursuits have the best win rates relative to investment?
Are we spending too much or too little on proposals?
None of that analysis is possible if proposal time bleeds into project time.
Summary
What do you want to do | What you should do instead |
|---|---|
Move proposal time to the winning project | Leave it in the proposal pillar — that's where it belongs |
Reduce overhead on a project | Review actual project time entries for accuracy |
Show the full cost of a project | Include a business development in your overhead factor |
Account for pre-award work that was really scoping | Log it as project time when it's happening, not retroactively |
The system isn't blocking you to be difficult. It's holding a line that, once crossed, quietly corrupts the data you depend on to run your business well.