Wednesday, June 16, 2010

Managing Proposal Time

Writing proposals is a critical function that too often is done with leftover time. We fit the activity in between project and operational tasks, frequently waiting until the last minute to complete our writing assignments. Like many nonbillable tasks, proposals are commonly relegated by technical professionals to "when I find the time or the deadline is upon us."

Not surprisingly, the lack of prioritization is evident in the results. A/E firms routinely accept win rates of 15-20% as the norm. But the best firms in the business boast 50-60% win rates. What's the difference? One of the biggest is that the more successful firms manage proposals like a project. This includes budgeting and managing the team's time. Here are a few suggestions for managing proposal time:

Don't waste time on losing proposal efforts. One of the first steps to better time management is eliminating time wasters. This, of course, conserves time for more important, more productive tasks. With proposals, this means passing on those RFPs where you have little chance of winning. Sure, you can can occasionally overcome the odds. But in the long run, it's not worth it. Every hour spent on a losing proposal is an hour that could have been spent better positioning your firm with a prospective client or preparing a stronger proposal where you had a better chance of winning.

Include proposal team availability in your go/no go decision. There are some proposals you just have to do, finding a way even when resources are scarce. But for those less obvious decisions, the availability of staff to prepare the proposal should be considered. As noted above, if you commit time to a proposal with long odds, you may be stealing time and attention away from another proposal where you are better positioned for success. Remember, you can always do a better job with a little more time. So be careful of spreading limited resources too thin.

Develop a plan. If it's unwise to execute a project without a plan, the same principle should apply to proposals. It's a team effort and the team should be involved in the planning. This not only enables you to better coordinate the team's various contributions, but to pool the collective brainpower to come up with a better proposal strategy. Typically, this is done in a kickoff meeting. For larger, more complex proposals, multiple meetings may be warranted.

Make assignments, budget time, and set firm deadlines. This is an important outcome of the planning process. Making assignments is common practice. But budgeting time is not. That's an unfortunate oversight and a key reason why we struggle to complete proposal assignments in timely fashion. If you are assigned the writing of Section 2, for example, how much time is needed and where will it come from? You should schedule your time just like any project task, which will typically involve reworking your calendar to make the time available. Intermediate proposal deadlines are important to putting together a quality deliverable, and thus should be adhered to.

Revise the schedule when necessary. Setbacks and detours inevitably happen, forcing you to diverge from the original proposal schedule. But often we don't specifically define how we will correct course and ultimately get back on schedule. It's wise to do so. When delays and disruptions occur, get the team together and reconfigure the proposal schedule, still providing adequate time for reviews and revisions.

2 comments:

cameron said...

great idea on the resources availablitiy being part of the bid no-bid process. would you have agood example of points to consider for the bid no-bid decision making? www.globalkap.com

Mel Lester said...

Hi Cameron,

I have a go/no go matrix posted on my website (www.bizedge.biz/toolbox). It's a synthesis of several such forms that I had collected over the years. But I prefer a much simpler screening process: (1) Had we been talking to the client before the RFP? (2) Can we beat the competition—really? (3) Can we prepare a strong proposal? (Which is often a resource issue.)