How to break proposal software

When purchasing software it really helps to know how to break it. You might decide to buy it anyway, but at least you’ll know its limitations …

Change the process

An automated process is like an assembly line, with predictable repeatable steps. A smart automated process may allow for contingencies, and customizable processes. However, developing proposals (at least certain types of proposals), often involves process changes made on the fly, based on circumstances like amendments to the RFP. Proposals written by teams often have different people playing different roles depending on who is in charge of that particular proposal. Try backing up and repeatable a step in a different way, as often happens in the real world of doing proposals. Some software packages designed to automate the proposal process won’t let you back up at all! Granted, nobody wants to back up and repeat steps, but the real world of proposals can get ugly. If the software can’t keep up with how you want to do a particular step in a proposal at a particular moment, you’ll end up working around the needs of the software instead of the software working around your needs.

Change the outline

Any software that establishes a link from the outline to individual responses is vulnerable to changes in the outline. Sometimes the outline changes because someone in the chain of command wants it that way. Some changes to the outline may be required by an RFP amendment. Changes to the outline can involve changing a section, deleting sections, adding sections, and moving sections. Maintaining the links between the outline, the assignment, and the response through these changes will often break proposal software that links the outline to the response.

Receive an amendment

If you really want to muck-up an automated proposal system, throw an RFP amendment at it. Think of everything that can change as the result of an amendment — requirement contents, response contents, outline, process, schedule, resources, writers, team mates, etc. Can the software you have in mind keep up?

Incorporate unwritten requirements

Make sure any software that supports written RFPs also provides for unwritten requirements. A good proposal capture plan will generate requirements intelligence long before the RFP is actually issued. Ideally, a proposal automation platform should be able to begin supporting a proposal before the RFP is issued and apply the data collected to the RFP once it hits the street. Another possibility is that the proposal may not have a written RFP. Can you emulate a written RFP by documenting verbal requirements and customer understanding? Can these unwritten requirements be allocated to the document?

Review the document

Most proposals go through informal and formal reviews. Will the software support both types? Does it support any type of review? Will it facilitate the collection of comments and their redistribution as writing assignments. Reviews can also lead to changes in response requirements, outline, assignments, schedule, and even process?

Switch roles (Sub vs. Prime)

When we think of doing proposals we often think of doing them as a prime-contractor. Yet many companies do the majority of their proposals as sub-contractors. As a sub-contractor, the proposal may not live within your system. However, the re-use material and other features of your proposal system may be still be of assistance. Will the software provide the support you need when in either role?

Team with another firm

When you are the prime-contractor, you may have sub-contractors working on the proposal with you. If this is the case, how will access be provided and what security will be in place. Even if you don’t provide remote access, you don’t want a sub-contractor working at your facility to have access to all proposals when using the system.

Web browser issues

If the software is web-based, there are technical issues to consider. The various web-browsers are not feature-for-feature compatible. Spacing, colors, and other details may change depending on which browser you are using. There are also differences between browser versions. This is most important for web-based systems that using the features of the latest versions of HTML, Javascript, or Java. Each browser version has features that can greatly improve a web-based system — at the expensive of users of previous versions who won’t be able to take advantage of them. Even if all users within your company use the same browsers, teaming partners, home users, and onsite users may not. Pay attention to browser compatibility.

Also pay attention to any scripting languages required. These include Javascript, VBScript, and Java. Java is a completely different animal from Javascript. Java is a complete programming language that can do many wondrous and powerful things. However, this power comes at a price. Java based systems tend to be slow, and often have significant download requirements before you can use them. Think of how much disk space a program like MS-WORD takes. It’s not megabytes, its tends of megabytes. Now imagine if you had to download that code before you could run it. Most Java systems severely limit the amount of code (and therefore the functionality) in order to shorten download times. But a download time measured in minutes before you can access your page may not be a useable solution, especially if you have users who dial-in using modems. Also, Java is not as platform compatible in real world usage as promised. There is a trade off here, and the use of Java in a system may be worth it — but test it before you commit.

Another to check with web-based systems is whether a browser “plug-in” is required. A plug-in extends the functionality of the browser and can help get around problems with web-based systems. On the other hand, downloading a multi-megabyte plug-in prior to being able to use a system may not be practical. It depends on your user population and proposal environment.

Copyright © 2012. Please review the Terms of Use prior to copying or distributing.