The following letter was written to a corporate level trainer/media developer who wanted to submit a proposal to his top management in order to create and implement a multimedia training system. The letter outlines the steps that must be taken to develop an internal proposal that has a "fighting chance" of being funded.
Thanks for letting me take a look at your proposal. If I may, I would like to share with you a couple of points that might help you to develop a better proposal. But first, let me put on my "we ain't got the money, and I don't care or understand computers" boss hat. Over the years, I have learned that most managers and executives who control the pursestrings for an organization are looking for solutions. In other words, they are not going to buy an aspirin unless they have a headache. And even then, it has got to be a real pounder that blurs their vision. The driving force behind this attitude is profitability. Every penny spent by an organization lowers the overall profitability of the organization. In short, to maintain or increase profitability, the organization must try to spend less. This is a common and logical line of reasoning. And one you must overcome anytime you propose to spend money. Keep in mind that whenever you submit a proposal, you are making a pitch. You are trying to sell something. That something has to be a solution. Let's face it, those of us in the creative end of the world like to experiment and tinker with new ideas, concepts, and strategies. People who control the money in this world usually don't want to experiment. They want "sure things." They want to know, if I spend X amount of money, then I will get Y amount back within a given period of time. It's what I call a "banker's attitude." Again, the driving force is profitability. So, with this frame of reference, I would like to suggest the following as additional content for your proposal. You begin a proposal by describing a problem that needs to be solved.
1. Identify and define the problem
A. What problem are you trying to solve? Be specific.
B. How big is the problem? In other words, how much does the problem hurt, i.e., how much is it costing us?
C. When does the problem occur?
D. Where does the problem occur?
E. Why is the problem occurring?
F. If we don't solve the problem, how much will it cost us over the next year? Two years? Three?
You get the idea. Also, keep in mind that the decisionmaker may not realize that he or she has a problem. And when you point out that they do, they may (1) want to kill the messenger, (2) deny that a problem exists, (3) look for someone to blame it on, (4) take a wait and see attitude or any number of other strategies to maintain a secure, safe and profitable status quo. The key to presenting a problem within a proposal is to do it in unemotional financial terms. The problem must be described as logically as possible, and presented as reality. Describing the problem may be thought of as the "sure foundation" upon which your proposal is based. The remainder of the proposal must then build upon this foundation. If your foundation is weak or illogical, then the rest of your proposal will be weak, illogical and will fail to convince the decisionmaker to fund your proposal.
At the end of the problem description portion of the proposal, the decisionmaker must make the first of several critical decisions: Do I want to try and solve this problem? Let's take a moment to look at how most people try to solve problems. Problems are, at best, disruptions in our daily routines. Problems are annoyances. Most human beings don't want to address or solve problems. We just want them to go away. But real problems don't go away. If anything, they get worse. Let's go back to our headache example. Once the decisionmaker realizes he or she has a headache, they will start looking for an aspirin. They will start their search by exploring for a "nearby" solution. They may look in their desk. Nope, no aspirin. They may wander into the next office and say, "Do you have an aspirin?". If they can't find any aspirin nearby, they may go down the hall. They may end up in your office. It is during this stage of the problem solving process that they want their problem solved for free.
When they can't get what they want for free, they may re-evaluate how bad their headache is. If it's bad enough, they will eventually leave the building and buy some aspirin at a local store. Now, let's translate this analogy into selling your proposal. Once you have described the problem in your proposal, you then want to describe a solution. In short, you want to be their "nearby" aspirin provider. You do this by providing the decisionmaker with unbiased information and a logical plan.
2. Present an effective solution
A. Briefly describe several possible solutions. Give the pros and cons of each. This demonstrates that you have thought about the problem and have not jumped to recommend your first "half-baked" idea.
B. Take your best idea and then turn it into a recommendation for a preferred course of action.
C. Explain your plan of action by describing:
1. The specific steps that will have to be taken;
2. Who will be involved;
3. What resources will be needed (both human and technical); and
4. When will the plan be implemented (a time line or Gantt chart is often used to describe this portion of the proposal).
In short, you want to describe a course of action that will solve the problem. This portion of a proposal is often referred to as the Technical Section. At this point, you must play the role of a consulting salesperson helping a customer to find the best pain reliever by providing information and making an educated recommendation. Note that no costs are mentioned at this point. Cost descriptions come next. What you want to do at this point is to "sell" your solution.
Now the decisionmaker must make a second critical decision, that being he or she must answer the question: Is this the best solution to the problem? If you have done your homework and you have carefully prepared your solution plan, the resounding answer should be YES! Once the decisionmaker decides that your solution is what should be done, you must next announce the price of the solution.
The third section of a proposal is called the Cost Section. The Cost Section is built on the various items identified in the Technical Section. In other words, you must build a line item budget for your proposal.
3. Present cost information
A. Break your budget out by the specific steps that will have to be taken
B. Budget for people who will be involved
1. Professional time, internal/external consultants, etc.
2. Support personnel
C. Budget for technology that will be required
D. Detail cost over time (again, a time line or Gantt chart may be used to describe this portion of the proposal)
Keep this portion of the proposal logical and realistic. Your goal in steps 2 and 3 is to give the decisionmaker factual information which allows him or her to answer the question: Is this a cost effective solution?
4. Project Results
Many decisionmakers may acknowledge (1) that a problem exists, (2) that they want to solve the problem, and (3) that your proposal provides a cost effective solution, but will fail to move. Therefore, your fourth step is to contrast the cost of not solving the problem with the cost of solving the problem. This is perhaps the most critical portion of the proposal. This is where you must give the decisionmaker a "cold blooded" rationale for "investing" in your solution. You must project a future break-even point where your solution will begin to save the organization money, i.e., make the organization more profitable. Since most managers and executives work on a quarterly or yearly profit and loss time frame, their attitude will always be "the sooner the better." Be careful not to fall into the trap of inflating your projection. It is better to be seen as being conservative, rather than overly optimistic in your projections. Step 4 helps the decisionmaker to determine: When will we profit from this proposal?
5. Ask for the order.
The final page of your proposal should be a permission to start page that approves the project. This is where you ask the decisionmaker to make his or her final decision... that is to buy. It's the decision that you have been working up to and without it you have wasted your time. It prompts the decisionmaker to act and not put you off. The decisionmaker must decide to solve the problem or not. It's the proverbial "the ball is in your court," now do something. The decisionmaker may hedge, ask for more information, or present objections. Respond speedily, giving the decisionmaker only what is asked for, but no more. Don't let them waste your time. Get a decision. Go or no go. If the proposal is killed, file it away. If the problem gets worse and upper management starts looking for someone to blame, you have CYA, and can document that you had a solution, but well, you know.
Which brings us to an important point, don't waste your time trying to solve little problems. Go for the ones that will make a difference. The ones that are important. The ones that are causing a lot of pain. Be a problem-solver, and you will build your credibility and reputation as someone who gets things done.
As a side note, you might think of how your proposed instructional delivery system might be used by other departments such as accounting or information services, thereby magnifying its worth to the organization while at the same time developing allies in other areas of the organization. In short, THINK BIG. Why not, it takes the same amount of time and energy as thinking small.