Proposal Writing Tips » RFP

How To Create a Scoring System When Evaluating Request For Proposals

Jane Ripley — Tue, 25 Oct 2011 13:46:25 +0000

How do you create a scoring system so that business proposals are scored fairly? One way to do this is to develop a scoring system and award points for each part of the bid. You can further refine this by adding ‘weights’ to the scores, i.e. as some parts of the bid are more important that others.

Evaluating Proposals

Yesterday, we looked at how to setup the proposal assessment team. This team is responsible for evaluating bids, scoring the proposals, and making recommendations.

The next step is to decide how to evaluate the actual bid. Here’s a suggested approach:

During the Request For Proposal evaluation, evaluate the bids under the following five headings:

Project Understanding – The prospective contractor must have a deep understanding of what the government agency is trying to achieve and how it wants to achieve the solution. It is critical that the proposal demonstrates an appreciation of the business needs and technical requirements.
Quality of the Proposed Solution – The evaluation team will assess the fit between the proposed solution and the requirements of the ITT. This is the main part in the evaluation; bids should present how the system will be implemented at the business level and technical levels, with regard to the preferred technical environment and procedures.
Project Management – This covers aspects of the project including scheduling, resource allocation, risk management, issue management, quality assurance, and reporting.
Proven Ability – It is essential that prospective contractors have proven track records with the type of technical solution proposed; projects of this size; clients similar to government agency and ideally in the business area. The assessment of capability may require references and referees.
Completeness of the Proposal – The least significant (and lowest score), this ensures that areas that fall outside those listed above are evaluated and help score the overall completeness of the bid.

In evaluating each bid under these headings, create different forms and templates.

Guidelines For Scoring Bids

The score given to each section will depend to a certain extent on the project under evaluation, its size, the technology involved, the business division and timelines.

However as a general guideline it is proposed that the total Phase 1 evaluation is marked out of 1,000 marks, and that the weights of each of the five criteria are chosen to achieve this overall total. In addition, a threshold mark for each criteria should be agreed by the evaluators. It is important to note that should a proposal fail to achieve the threshold mark in any one criteria, then the proposal will fail overall.

For example, the marking scheme could adopt the following weights and thresholds:

Criteria – for example, Understanding of the Project
Threshold – for example, 40, 50 or 60
Weight – for example, .5, 1, 2 or 3
Max Possible (Weighted Score) – this is the total combined scored when all factors have been combined

For example:

1. Project Understanding   40   1.5   150
2. Proposed Solution 60   3   300
3. Project Management 40   3   300
4. Proven Capability 60   2   200
5. Completeness 0   0.5   50

Make sure to add notes and comments when submitting these marks, i.e. to explain why you awarded these scores.

You may also want to reference any perceived risks not addressed in the proposals.

How to: Writing Risk Analysis for Business Proposals

Editor — Sun, 23 Oct 2011 18:09:22 +0000

Risk assessment creates problems for proposal writers. When responding to a Request For Proposal (RFP), you need to identify all known risks but also flag how these will impact other projects and deliverables. Your response also needs to discuss how you will mitigate against this; in other words, if you were awarded the contract, what measures would you take to reduce the risks.

Outline the Costs. Provide line item details and daily rates

It’s a challenging area for bidders as you don’t want to seem too negative but… you need to demonstrate that you understand the risks and have the expertise to control them.

Risk Assessment in RFPs

You can discuss the risks by breaking them down as follows:

Risk Number – provide a unique number to each risk. This helps track it across all procurement documentation.
Category – identify a set of categories and place each risk into its own category.
Detail – use this section to describe the risk in detail and how it relates to the requirements as identified in the Request For Proposal.
Impact – highlight where it impacts the solution and what other issues need to be addressed.
Mitigation Actions – finally, include a section that discusses the steps you will take to reduce this and minimize disruption to services.

Risk Analysis: Number

Use a numbering system that it easy to track in both Microsoft Word and Excel. Avoid complicated numbering systems as these take time to manage and update. If possible, cross reference the risks to the requirements.

Risk Analysis: Category

Examples of categories include:

Mobilization
Project Management
Client Input
Organisation
Functionality
Acceptance
Schedule
Budgets

Restrict the number of categories to keep it manageable.

Risk Analysis: Level of Detail

Discuss the risk in detail so the reader understands your concerns and later the mitigating actions you’re going to take. Here are some examples from a previous project:

Number of people that will join the project. Risk that there will not be space or facilities for them.
Deadlines are aggressive. The solution needs to be in place by September 2012.
Client’s resources are either not available to participate from the start or participate at different stages throughout the project.
Unclear contractor responsibilities result in less effective project management.
Change is not managed in a controlled manner.
Security audit requirements; may take several weeks.
Parallel project (which we are dependent on) is delayed.
Scope changes.
Client is not prepared for acceptance on completion of User Acceptance Test (UAT).
Client does not deliver test environments before start of the Technical Design phase.

Risks Analysis: Impact

The next step is to discuss how these may impact the project’s success.

Lack of preparation may result in delays.
Delays will result in negative perceptions in staff.
Delays will impact timelines and costs.
Scope creep results in delays and unanticipated complexity.
Security audit may impact the project’s timelines and thus project costs.
Project team does not have the required information before technical design begins.
Impacts to project timelines
Impacts to costs.
Impact delivery timelines.

Risk Analysis: Mitigation Actions

So, how do you mitigate against this? Here are some examples:

We have successfully delivered projects for Government clients, such as [project name]
We have the experience of meeting tight deadlines. We can ensure that each stage is managed tightly and produces the right inputs for the next stage.
We have will work with you to ensure that there is adequate notice of when all client resources are required.
We have the experience to provide the cohesive project management capability that you require.
We have has experience of working with and managing third parties to work together as a coherent and productive team and to successfully deliver projects.
Monitor scope in order to ensure successful delivery.
Baseline and agree the scope of the project during the Scope Definition phase.
We are accustomed to planning audits and designing solutions that meet these security audit requirements.
We have has taken into account your readiness date when planning.
We can work with you to manage any issues relating to project overlap.
We are accustomed to building solutions that need to interface with third party solutions.
We have can work with you to monitor any impact on parallel projects.
We will help prepare the UAT user group for conducting UAT with a view to acceptance on behalf of the organisation.
We will ensure that you are aware of the timelines by which environments are required.

Conclusion

When writing the risks section of the proposal, it’s best to present the information in a table format. Creating a table (possibly in landscape format) will help the evaluation team examine the risks and, if necessary cross reference them back to the Request For Proposal’s requirements.

What else would you add?

How do you identify risks? Do you use a specific numbering system? How do you discuss the mitigating actions?

RFP Checklist For Describing Functionality

Editor — Fri, 02 Sep 2011 15:09:17 +0000

How do you describe the website’s functionality in your RFP? The next section in your Website RFP is to describe how it works, i.e. functions.

The functionality section of your RFP can be distilled to a few pages. Share sample sites that illustrate functionality you’d like to see on your site.

Download Request For Proposal Template for only $14.99

To describe the website’s functionality in your RFP, create a table with a listing of all potential functionality.

Indicate which functionality is:

Implemented,
Planned, or
Under consideration

Website RFP Checklist – How to Write Functional Requirements

Write the functionality from the customer’s perspective. This helps the bidder to visualize how the website will work as they can see it as the user would.

To do this, describe:

Examples – Sites that approximate the desired functionality
Database – Outline if your site involves database development or integration
Components – Describe which (if any) software components that have already been installed, such as chat, project management, multimedia, e-mail, other…
Ecommerce – Describe how transactions will need to be managed. Include details of payment, fulfillment, verification, and order tracking

Takeaway

When describing the functionality, create a matrix and list what’s currently installed, what needs to be developed, and what would be nice to have, i.e. useful but not urgent.

This helps the bidder when preparing the cost section.

How?

They can provide a bandwidth of costs depending on which functionality is developed and which is ignored or postponed to a future date.

You can then choose which suits your budge and which you feel if good value for money.

RFP Checklist for Content, User Interface & Design Needs

Editor — Mon, 22 Aug 2011 14:57:33 +0000

If you’re writing an RFP for a website, you need to describe the content types and graphic. This enables the bidder to create a prototype that will manage the different content assets and present it in an attractive manner to your customers.

Download Request For Proposal Template for only $14.99

Website RFP Checklist – Content, User Interface, and Design Needs

Design and content are two critical elements in front-end solutions and, by extension, branding.

Content, layout, navigation, and design make up the user interface, which is a critical driver of the user interface.

The user interface determines how content is displayed to customers on your web site.

Website RFP Checklist – Content, User Interface, and Design Requirements

Describe the following in the RFP:

Target Users – Who are the main users of your site?
Core Messages – What are the key messages that need to be delivered to those users?
Format – Is your site information or graphic-oriented?
Delivery – Is the delivery of the key messages like a book, a magazine, or something else?
Navigation – How will different visitors navigate your site?
Page Count – How many pages of content will your site contain?
Content – Does content need to be developed, and if so, what – if any – resources are available?
Outsourced – What percent of your content can be outsourced?
Style Guide – Is there an style guide for content or design?
Benchmarks – Is your company aware of sites that have the desired information or creative design you require?
Archives – Is there an archive of photos or other imagery that can be used for your site?
Commission – If appropriate, would your company commission original design or photography?

Takeaway

These are examples of some of the requirements you need to list. Make sure to add to this list and share the specific needs which must be addressed.

Remove guess-work.

Help the bidders prepare a proposal that realizes your objectives.

What other requirements would you add?

RFP Checklist For Describing Website Technical Needs

Editor — Sat, 20 Aug 2011 22:10:42 +0000

How do you describe the website’s technical needs in your RFP? The next section in your Website RFP is to describe how it works from a technical standpoint.

For instance, this helps bidders understand if it can be integrate with MS, Oracle, or WebSphere. Without this technical details, they will not be able to prepare a valid solution.

Download Now for only $19

Website RFP Checklist – Describing Technical Needs

Technical specifications describe the back-end both from an infrastructure (e.g. hosting environment) and software development point of view.

Provide the following information in your RFP:

Domain – Has your domain name been registered? Have you registered different variations?
Hosting – Is your hosting currently in-house or outsourced? Have you had issues with the hosting.
Statistics – What are the usage statistics and anticipated growth?
Security – Are there significant security concerns? What are the security needs of your site, i.e. physical and electronic?
Platforms – What development platform do you use (e.g. Windows NT, UNIX, etc.)?
Legacy Systems – Are there legacy systems that need to be considered? What are the existing databases in place (e.g. Oracle, SAP, IBM etc)?
Web Browser – What browsers are visitors likely to use? Has a targeted browser version been determined?
Mobile – Do you need a mobile version of the site?
Languages – Which of the following might be used (if known): HTML, DHTML, Java, CGI?
Multimedia – If multimedia capabilities are required, which development tools will be used (e.g. Premiere, Flash, Audio)?

Takeaway – Describing Technical Needs

Provide enough details so bidders can, if necessary, create a prototype showing you how the solution will function. Highlight tools you do not want or may be impractical to implement, such as Adobe Flash if you plan to develop for the iPad.

How To Get Your Proposal Accepted By Difficult Evaluators

Editor — Thu, 18 Aug 2011 22:14:32 +0000

What’s your success ratio with proposals? 25% is average. Very few get 50%. I help government agencies evaluate proposals. Most bids that come across my desk make the same errors, use the same flawed strategies and are never accepted. And the next time, they repeat the same mistake. Here are some ways to avoid this. It’s not painful, it just requires effort.

What does a Proposal Evaluator Do?

My job is to reject your proposal. I fail proposals if they miss a requirement, avoid a clause or get the figures wrong. We received 36 proposals for the last RFP. Some were over 300 pages. The less I have to review, the better.

Tip: make sure the proposals are well-bound. We scribble all over them, book-marking pages, and adding comments. Don’t use cheap papers and poor ring-binders. If they fall apart, I’m not going to re-assemble your document.

I eliminate proposals that don’t measure up. This means they fail on a technicality, are over budget, don’t agree to the deadline or have omitted to include some document.
Then I review what’s left and make a short list.
For me, evaluating a proposal is a process of elimination, not a process of selection. That happens later.
When you start your proposal, don’t focus on getting selected, instead WRITE A PROPOSAL THAT CANNOT BE ELIMINATED!

Here’s how you can do this:

Write your proposal so that the evaluator cannot reject it on a technicality.
Respond to every requirement in the Request For Proposal (RFP). This means you cannot be dis-qualified on the grounds that you were “non-responsive to the RFP.”
Identify the solution. If it’s a product, name it & give the version number.
Don’t be vague. State clearly how you will do this. If possible, describe the solution in a single sentience.
Demonstrate that you have provided this expertise in a similar project.
Support you claims with case studies, white papers and other reports where you are given credit.
Provide pen portraits of your team. CVs go in the appendix.
List the benefits that your solution provides. Cross-reference these against the requirements. Itemize and prioritize each benefit.

Remember, the evaluators are looking for ways to disqualify you.

Check your proposal once, twice and three times.
Each time check for a different weakness or error. For example, once for writing errors, then for flaws in the solution and finally in the costs. You can make errors elsewhere but NEVER in the costs.

Conclusion

Write the proposal so that it cannot be eliminated.

Once you have this established, then drill-down into each requirements and respond from the perspective of the reader. Regardless of how good you think your proposal is, if you overlook a technicality, you’re out.

What have I missed? Let me know what you think below.

No related posts.

What is a Bid Manager?

Editor — Tue, 16 Aug 2011 22:37:41 +0000

What are the roles and responsibilities of the Bid Manager during the proposal development process? The Bid Manager’s role is like that of the Project Manager on an IT project. Their role is to coordinate the team members, analyze the Request For Proposal, allocate resources, define the schedule, keep the deliverables on target, and ensure that the proposal is submitted on time.

Proposal Team Roles and Responsibilities: What is a Bid Manager?

A Bid Manager is responsible for:

Manage and implement a proposal development process (if none exists)
Apply a structured approach to the development of proposals
Analyzing the Request For Proposal
Allocate resources to each section, e.g. who responds to each requirement
Define the project schedule, costs, and deliverables (e.g. the proposal)
Keep the deliverables on target
Ensure that the proposal is submitted on time and in the correct format
Developing and writing task order proposals.
Understand the government task order development process
How proposals are scored by customers.
Coordinate a team to develop the proposal document
Visualize solutions, processes, and create graphics to represent these processes
Provide expertise in preparing Federal government contracts
Understanding of the procedures and the acquisition process
Coordinate the proposal delivery, printing and publications
Write major parts of the proposal if/when necessary
Ensure that the proposal reads smoothly as a single document
Collate the entire document.

What are the biggest mistakes that Bid Managers make? Please share your thoughts in the comments sections.

Defining Objectives in Your Website RFP

Editor — Sun, 14 Aug 2011 14:50:29 +0000

If you’re writing an RFP for a website or content management solution, you need to outline your online objectives and how the new site will drive your web site’s content, design, functionality, and technology.

Download Request For Proposal Template for only $14.99

Website RFP Checklist – Why Define Objectives?

All of your business units need to understand what they are trying to accomplish through the internet.

For instance, the objective of a web site might be to have a marketing presence based largely on your corporate literature or…

Incorporate customer service or…

Focus on e-commerce aimed at increasing revenues.

In considering objectives, consider the intended audience and the online benefits to that audience.

Articulate your objectives and rationale in one or two paragraphs.

Website RFP Checklist – How to Define Objectives

To do this, explain which of the following best represent the type of site desired:

Marketing presence
Customer service
Static information delivery
Dynamic information delivery
E-commerce
Supply-chain management,
Community-building or
Other

Note: more than one may apply.

Takeaway

Keep your objectives concise, non-ambiguous, and relevant. In addition, highlight if your competitor(s) provide the internet offering you want? If so, refer to this.

Also, outline what your new site will do more efficiently than current processes. How will it increase sales, reduce costs, or generate new leads?

What other objectives would you add?

RFP Checklist – Defining the Business Context

RFP Checklist – Defining the Business Context

Editor — Mon, 01 Aug 2011 17:00:28 +0000

You want to create an RFP for a new website! What do you need to include?

The first section is the business context.

Why do you need to put your business proposal in context? Think of it from the reader’s viewpoint. By placing it in context, you’re helping them understand your requirements so they can marry their solution with your needs.

RFP Checklist – Defining the Business Context

To do this, start your RFP with a few paragraphs describing your business. Imagine they know nothing about you. What would you tell them? How would you describe what you do… in non-technical terms. And with no jargon.

Give them some corporate literature and/or a press kit, if possible.

Next, answer the following questions so that bidders have a better understanding of your requirements:

Industry. In what industry is your business?
USP. What is your unique competitive positioning?
Competitors. Who are your company’s major competitors?
Customers. What is the profile of your company’s customers?
Suppliers. Who are your key vendors/suppliers? How many in total?
Performance. What has been your company’s performance over time (growth rate, stock performance, etc.)?
Size. What size is your company (revenues and employees)?
Location. What is the geographic span of your company?
Strategy. What is your company’s growth strategy?

Give the bidder enough information so they:

Can grasp your position in the market a little better
Don’t need to request clarifications on minor points
Help you frame the rest of the RFP

Conclusion

Keep this section brief but informative. Don’t give too much detail here. Rather refer them to the appendix and other supporting documents. You want to be helpful so they have adequate information, but you also want to move them into the main section of the RFP and get into the requirements.

The takeaway is that some parts of your RFP will be high-level (as in the Executive Summary), whereas others drill-down into more granular detail.

If possible, assign different writers to each task unless your writers have the skills to write both sections.

No related posts.

Business Proposals: How to Write Costs For RFPs

Editor — Tue, 28 Dec 2010 12:16:00 +0000

Having difficult getting started with the Budget and Costs section in your Business Proposal? The purpose of the Budget is to give more than just a statement of proposed expenditures; it is an alternate way of showing, for example, the fluctuations that may arise depending on how the scope of work may change or if new requirements are added to the list of deliverables.

Business Proposal – Sample Budget Guidelines

In essence, your budget is as much a credibility statement as your project narrative. Key Budget questions to answer?

Does your budget:

Provide sufficient resources to carry out your project?
Include a budget narrative that justifies major budget categories?
Present the budget in the format desired by the sponsor?
Provide sufficient detail so the reviewer can understand how various budget items were calculated?
Relate budget items to project objectives?

Business Proposal – How to Write Budgets and Costs

Make sure your calculations are exact. For example, instead of writing,

travel = $324

be more specific and write:

local mileage for project director, 100/mi/mo @ .27/mi x 12 mos. = $324.

Indicate the name, location, and date.

In multiyear budgets, allow for yearly increases such as inflation. If the project will occur in phases, identify the costs associated with each phase.

Business Proposal – Mistakes to Avoid with Costs

Include a budget narrative immediately following your budget to explain or justify unusual expenditure items, even if the sponsor does not require one.

Ultimately, it shows how well you’ve estimated the time and effort required to complete this project. Budgets that are too low cast doubt on your planning skills and ability to gauge the amount of work involved.

What other mistakes should we avoid?

About the Author: Ivan Walsh provides business proposal writing tips, tutorials, and templates on the Proposal Writing Course every week. Get his free proposal writing newsletter here.

How to Write Headlines, Summaries and Abstracts For Business Proposals

7 Request For Proposal Evaluation Guidelines

Editor — Fri, 24 Dec 2010 11:41:00 +0000

Your success as a Proposal Manager depends on your ability to respond to Request For Proposal documents, understand the procurement process, write compelling responses, and coordinate your team during the writing process. However, even with the best will in the world, unless you have guidelines, templates and checklists in place, you may jeopardize your own efforts, especially if you overlook one key requirement in the bid document. Here’s how to avoid this.

Request For Proposal Evaluation Guidelines

Unless you organize the Proposal development process, your success as a Proposal Manager will be severely under-minded.

One way to avoid this is to create easy to use checklists that your Proposal writing team can follow. And, more important, help automate the writing process as much as possible.

You can start on this by creating Action Plans that itemize the key steps, actions, and action owners so everyone on the team understands their role. Here’s a list of the items you need to capture:

1. Proposal – Selection

How to identify, review and select Request For Proposals.

Sales Manager schedules meeting to review new Request For Proposals.
Sales Manager & Bid Manager decides which Request For Proposal to bid for.
Review selected tenders in advance of Monday meeting.

2. Proposal – Meeting

How to schedule, assign and plan Request For Proposals responses.

Sales team organize meeting.
Review last week’s proposals, highlight issues, and plan week ahead.
Discuss Proposal Team members and who will write each bid document.
Contact staff members required to contribute to the tender, e.g. Developer.
Agree date for proposal to be completed, e.g. 48 hours before submission date.
Update the Proposal spreadsheet on the Intranet.
Take and share meeting minutes

3. Proposal – Team Actions

How to organize the bid team for each Request For Proposal.

Read the RFP before starting any writing.
Clarify any points that are unclear with the RFP issuer
Circulate the replies to team members.
Notify Project Coordinator if resources are required and/or impact existing schedules
Notify Proposal Owner of major issues, i.e. schedule conflicts

4. Proposal – Draft Stage

How to write, edit, and gather information for each Request For Proposal.

Use the Business Proposals template.
Confirm financial details with Finance Dept.
Confirm resumes with Human Resource Dept.
Team members return completed sections to Proposal Author for compilation.

5. Proposal – Review Stage

How to proof, review, edit each draft document.

Proposal Author circulates compiled Draft 0.1 to team members.
Team members review draft copies.
Proposal Author collates next draft.

6. Proposal – Quality Assurance

How to test, proof, and circulate the draft Proposal.

Send Draft to Proposal Manager 24 hours before deadline. Late documents cannot be fully checked.
Proposal Manager checks Draft documents. Resolve queries with contributors.
Proposal Manager returns Final Draft to Proposal Author.

7. Proposal – Production

How to print, proof, and product the draft Proposal, especially if you need a hardcopy.

Proposal Manager prints required number of hardcopies.
Inform Proposal Manager in advance
Proposal Manager checks quality of final print.
Prepare labels for large envelopes.
Create CD-ROMs with company logo.
Include cover letter from Sales Manager

and in case we forget, here’s number eight.

8. Proposal – Post Production

How to archive, share, and prepare status reports on the Proposal.

Proposal Manager files ‘Final Draft’ on shared drive.
File supporting proposal documents in a sub-folder for reference.
Update team members at Monday Meeting.

What have we missed?

About the Author: Ivan Walsh provides business proposal writing tips, tutorials, and templates on the Proposal Writing Course every week. Get his free proposal writing newsletter here.

34 Ways to Check Your Request For Proposal Submissions

Editor — Mon, 20 Dec 2010 11:30:00 +0000

If your next Business Proposal is for an important client, and you’re working under pressure to get the document submitted on time, it’s easy to get confused and forget something which determines whether you win or lose the bid. One way to avoid this is to use a proposal checklist to identify each requirements in the Request For Proposal.

Request For Proposal Checklist

Use this checklist when proofing your bid and, especially before sending your proposal to the printer:

Official Request For Proposal Documentation

Is the following information correct?

Request For Proposal Name
Document Owner
Request For Proposal Description
Received date
Closing Date
Date Submitted
QA Completed (Yes/No)

Proposal Writing team and Contributors

Do you have all the necessary information from the writing/bid team:

Content Required from:

Date Content Required by:

Content Required from:

Date Content Required by:

Content Required from:

Date Content Required by:

Content Required from:

Date Content Required by:

Proposal Quality Control Checklist

As the Proposal Manager, complete the following quality control checklist:

Identify contributors to the bid document
Confirm dates for receiving documents
Confirm Sign–off dates
Confirm File format e.g. Word, PDF
Confirm Number of hardcopy and softcopies required

Proposal Format, Style, & Grammar

The Proposal Manager can use the following checklist for each Business Proposal, when you check the bid for grammar, language, writing, technical details, cross-references and other information that relate to the bid:

Cross-Reference the Proposal against the Request For Proposal for:

Spelling
Grammar
Language (UK or US English)
Publication Date on Document
Each Chapters / Section has intro text.
Footer has Date & Time
Header and Footers have Titles
Header has Version Number
Graphic Layouts are correct
Figures/Tables are numbered
Correct Fonts e.g. Headings, Body Text etc
Supporting Docs are included, e.g. CVs
Remove Comments/Remarks
Remove Blank pages
Check Cut-and Paste data from other docs
Page Layout set to A4
Page Sequence is correct
Tables layout is consistent
Lists are consistent
Bullets, Diagrams etc print Correctly.
Print Draft Document(s)
Circulate copies for review
Collate all contributions
Monitor Version Control
Highlight gaps to Project Manager and/or Contributors
Highlight issues to Project Manager and/or Contributors
Make Backup copies of Working Docs
Make Backup copies of Finished Version
Graphic Designer Role in Proposal Development
Ensure the Graphic Designer completes the following:
Design/Print Request For Proposal Cover and Back
Design/Print CD ROM Jewel Case Graphics
Design/Print CD ROM Graphics
Package CD

Proposal Print and Assembly Checklist

Even when you have finished all these steps, you can still trip up if you don’t have material to print, assembly and post the Proposal.

Ensure you have the following:

Spare cartridges in stock
Correct Paper in stock
Check Spelling on Design Literature
Burn CD and Package
Check CD for correct contents
File Graphics in Project Folder
Check Printers are functioning

What else is needed to make sure each Proposal is submitted on time?

About the Author: Ivan Walsh provides business proposal writing tips, tutorials, and templates on the Proposal Writing Course every week. Get his free proposal writing newsletter here.

6 Mistakes to Avoid When Writing Deliverables

Editor — Fri, 01 Oct 2010 15:47:31 +0000

The next part of the Business Proposal to write is the Deliverables section. The Deliverables section should be simple to understand but many Proposal Writers fall over themselves here.

Where to start with Deliverables

Let’s play good cop, bad cop for a minute.

In the Request For Proposal, it asks that you deliver the following:

Understanding of project scope and requirements
Description of the proposed research methods and rationale
Project team and references (and that of sub-contractor if applicable)
Work plan and schedule
Detailed budget estimate
Final written report (expected to include an executive summary,
conclusions, supporting charts, analysis and recommendations).
Printed and electronic submission of proposal in both Spanish and English

What the RFP writers want to see if your response is two things:

Confirmation that you will do (deliver) these
Examples of how this will be done.

If you don’t give some examples, then it’s hard for them if you can genuinely do this or… are simply saying Yes to get your foot in the door.

Common Mistakes When Responding to Deliverables

One of the difficulties in writing the deliverables section is that you’re trusting the project manager to ‘deliver’ these requirements.

In some situations, this section is given to the PM to write. This makes sense up to a point. However, you need to be careful that the PM, in his/he eagerness to please the team lead will commit the following mistakes.

1. Too Much Detail

An inexperienced project managers may become enamored with his work breakdown structures. Instead of keeping things simple, they may design the WBS so it becomes almost impossible to manage.

For example, we worked on a project in Shanghai where the PM created 275 work packages; some were broken down into minutes rather than hours or days.

Unless you know a little about PM, it’s hard to know where they’ve gone wrong. This “micro-level” WBS is excessive. Not only was it impossible to manage but it made our partners doubt the ability of the PM to oversee such a complex project. The takeaway is that your Project managers must establish an appropriate WBS level from which to manage, otherwise get a second opinion

2. Lack of Experience

As above, if the PM is new to this area, consider getting another PM to check their figures. Many young PM will pretend they have worked in an area to avoid been exposed as inexperienced.

3. Ignoring Risks

All projects have risks. An inexperienced project managers may not see potential risks in the project. If the necessary contingencies are not put in place (or at least acknowledged) then your project costs could escalate if an unexpected event arises.

4. Agreeing To Unreasonable requests

Most project managers want to please the customer. But, there are limits. Make sure the PM is not bullied into agreeing to new deliverables without consulting other team leads. Likewise, make sure that scope creep is addressed upfront so the client does not try to squeeze in new features without paying the full price.

5. Not Understanding Stakeholders

It is critical that, as part of stakeholder management, project managers interview the stakeholders to learn what information they deem as important and then act accordingly.

They also need to understand the tracking metrics or key performance indicators (KPI) so they can design an different performance dashboard for each stakeholder.

6. Jumping to Conclusions

Novice project managers, with little hands-on experience, may jump to conclusions or interpret requirements based on a limited understanding of how these will impact the project schedule. You need to monitor these project manager and ensure that they consult with subject matter experts to get the correct figures.

How to Write Better Deliverables

The best way to write the deliverables is to:

Include descriptions of the types of reports that will be used in the project.
Show Status Reports and detailed information on risk, vulnerabilities, and the necessary countermeasures and recommended corrective actions.
Include sample reports as attachments to the proposal to demonstrate that you’ve supplied these types of reports to other clients.

Then, break out the key deliverables and work through each one individually. In other words, instead of agreeing to provide these deliverables, paint a picture in the reviewer’s mind so they can see how you will do this.

The key is to see every page on the proposal as an opportunity to build more trust with the reviewers. Use each section to demonstrate your competence and how your understanding is greater than the other bidders.

Remember, to add the deliverables to the project plan with an estimated delivery date. More accurate delivery dates will be established during the scheduling phase, which is later in the proposal.

Next up, we’ll look at how to schedule meetings.

About the Author: Ivan Walsh is a Proposal Writer who develops Business Proposal Plans. He also shares Business Planning Strategies on IvanWalsh.com. Follow him on Twitter & Facebook.

No related posts.

How To Guarantee Consultants Meet Their Goals

Editor — Thu, 30 Sep 2010 14:48:02 +0000

So far our Proposal Writing Course has looked at two things. How to create a central hub (the table of contents) and define your first pillar (the Exec Summary). Next up we’ll go through each section and ‘satisfy’ the folks who published the RFP that Yes, we do know what we’re talking about.

We’re using a Consultancy Proposal as our framework. In this proposal, we’re bidding for a services-based contract.

As the services will be performed by our Consultants, we need to persuade the readers that our team is reliable, dedicated, and experienced. We also need to discuss how we’ll monitor them. After all, they’ll be working offsite (i.e. not at our office), which begs the question, ‘How will you supervise them?’.

How to Ensure Consultants Meet Their Goals

To do this, we will add a Supervision chapter to the proposal. The purpose of this section is to outline the methods and tools we’ll use to monitor the Consultants and ensure they reach their targets.

There are a few ways to do this:

Identify who will monitor (i.e. supervise) the Consultant. In general, this is the Project Manager.
Discuss the role of the PM. For example, ‘This person is responsible for ensuring that the consultant meets their objectives and performs their activities in line with the Work Breakdown Structure.’
Show how the supervisor will work as the Government agency’s Project Manager, coordinating communications, budget controls and report generation activities. In other words, our PM and their PM will have joint meetings where they will discuss Status Reports and the performance of the project to date.

How This Appears in the RFP

In the RFP, the bidders may outline their requirements as follows:

‘A Consultant is required to prepare a Strategic Plan under the supervision of the Operational Group responsible for the implementation of the Waste Management Plan.’

And your response could be:

Our Consultant, being the lead authority for the implementation of the Waste Management Plan, shall be the contracting authority for the proposed service.’

This sentence is to acknowledge that you are bidding for these services.

Use the rest of this chapter to outline how that person will with their team in real terms. Avoid business cliches and referring to synergies and other such meaningless jargon.

Paint a picture for the Government Agency. Show them how the consultant would work with them on the ground.
Identify the types of issues that are likely to arise.
Explain how he/she will respond to these and pro-actively address them.
Outline the lines of communication and how the Consultant will highlight issues, risks, and contingencies to both parties.
Discuss contingency plans, for example, if the Consultant needs to leave in the middle of the project. How will this be managed? Who is the back-up? How have you addressed this in the past.
The point here is not to focus on the Consultant’s academic achievements (that’s later) but to show how they will work with the other team on a daily basis.
The reviewers may also be the on the PM team that will liaise with the Consultant. Put their fears to rest. Give them reasons to enjoy working with your colleague.

Make it personal. Make it stick.

In the next lesson, we’ll look at how to write the Deliverables.

Stay tuned.

About the Author: Ivan Walsh is a Proposal Writer who develops Business Proposal Plans. He also shares Business Planning Strategies on IvanWalsh.com. Follow him on Twitter & Facebook.

Pic Silver Season

No related posts.

Gmail Tips: 17 Ways to Read, Write, Respond, and Complete 75 Emails a Day

Editor — Sun, 27 Jun 2010 14:50:00 +0000

As someone who runs their own company, lost time is lost money. And, it’s no different if you work for someone else. Lost time = lost money. Every minute counts.

‘Help me answer every email in the same biz day!’ I got this from a good friend a while back and this is what I wrote back to her.

‘I get approx 75 emails a day. 120 is high. 50 low. I run 7 sites. Most of my customers are in the US but I have others in the UK, across Europe and in Australia. So, emails are always coming in.

Here’s what I do:

1. Don’t Park – I try to push each email to completion; that means no ‘parking’. Once I open it, I see if I can finish it then and there. I don’t want to see it a second time. Hat tip to Tim Ferris.

2. Guilt — Don’t feel guilty about writing short, accurate emails as long as you address the key points. Just because you get a 500 word email, doesn’t mean you need to write 500 words back! You don’t have to reply like for like. Knowing this made a huge difference as I felt free to write one line emails that answered the question and then moved on.

3. Word count – Aim to reduce your word count. Say it in one word, not three. Write use, not utilize. Move, not migrate.

4. Deadwood — Drop non-words such as actually, as a matter of fact, in the event of, due to the fact that, and other fillers. Also, remove oxymorons such as pre-meeting (meeting is fine).

5. Consolidate — I’ve closed down my Hotmail account and moved other accounts into one master Gmail account. Less time lost logging in and out. And more secure too. Here’s how to read your Gmail emails offline.

6. Touch Type — I learnt to touch type as a teenager (and do shorthand) so I can type fairly quickly. This helps me run thru emails that bit faster.

7. Microsoft Word — I write longer emails in Word, use the built-in features such as auto-completion, auto-correct and then paste into the email client. It’s so much faster. Word is great when you learn how it really works.

8. Delete Folders — I rarely use them. I don’t store emails for a rainy day. I used too until my account got deleted by accident. Most of what I had ‘collected’ was of zero use. If it’s that valuable, store it somewhere safe.

The more you have, the more you have to manage.

9. Train Customers — I ‘train’ my staff and customers to answer emails the right way. I know that may sound extreme but very few of us have been trained (really trained!) to communicate. It’s not their fault. And no one has shown them how to do it better.

Enter Ivan!

Here’s an example:

Instead of asking

“Will it be ready?”, (an open ended question)

I write:

‘Can you confirm it will be ready by Friday?’ (I’m looking for a specific date, time, or confirmation)

In other words, I’m training them to give me the information I need to push the task to completion. My goal is to get to completion as soon as possible.

10. Subject Line — I use the subject line in the email to ask, confirm or agree with the email’s request. Others have now got into the habit. Many staff ask/respond to emails in the subject line only. Really speeds things up.

11. Help the Reader — Don’t group several ideas/questions in the same paragraph. People read in a hurry. Help the reader reply to your email by:

Pulling out the key points,
Use bold when necessary, and
Red if it’s really critical.
Don’t go over-board but a single bolded in red will get the reader’s attention.

12. Use Bullets – for longer emails, I bullet point and/or number the key points. This makes it easier for the reader to see what I need answered.

‘Let’s see, Ivan has these five questions. I’ll start at the top and work my way down.’

13. Ignore FYIs – I rarely respond to or read FYIs. Most is information pollution and people covering their… Status Reports are fine; that’s where the relevant information should be. Also, if you ignore FYIs, and don’t respond, they stop sending them.

14. Meetings with Me Only — I book meeting rooms just for me. Then I spend an hour in there ‘processing’ emails. I really try not to check email when doing this (I’m human after all) but to process things and get them to the next step.

15. Good Surfing Habits — This is more to do with time-saving. I don’t surf the web without an aim (well, almost. Those ninja cats can be real fun). Instead, I use Google Reader, which pulls in (and shares) my fav sites, so I don’t have to go hunting them down. It also shows if/where there is a new article. And, I’ve setup folder/topics and read the most important sites first.

16. Team Effort — I also try to get the team into the same mindset. The best way to get them onside is to show them how this saves time and makes their life easier.

17. Use the Phone — finally, be creative. You don’t have to use email all the time. If it’s quicker pick up the phone or print it out and walk over to your colleague. It’s a nice way to network, look busy and get some light exercise.

One book I found really helpful is Alan Lakein’s ‘How to Get Control of Your Time and Your Life’. He wrote this in the 70s – before email – but his approach is very helpful. It’s a small little book but worth the read.”

How do you manage?

Out of curiosity, how many emails do you get every day?

Kate Winslet’s 7 Smart Ways to Read Business Proposals