A VPC can never replace all of the benefits of face-to-face communication, but it can make it feasible to go without it when you have to.

There are a number of different ways to provide web-based access to your proposal files. Unfortunately there is no out-of-the-box, one-size-fits-all solution. Most proposal groups kludge together a number of tools in order to provide the functionality they need. This rarely results in an ideal solution, but it may get the job done.

Examples of tools that can solve part of the problem, but won’t give you a full “VPC” are as follows:

  • Microsoft Office (Most people don’t use the full capabilities of what they already have)
  • Microsoft NetMeeting
  • Instant messaging
  • Webex
  • OnProject

Good platforms to build on, but “some assembly may be required” are these:

  • Documentum ERoom
  • Intranets.com
  • Microsoft Sharepoint
  • Groove.com
  • Plumtree.com

Relevant Technologies are:

  • Content Management
  • Document/Knowledge Management
  • Intranets/Extranets
  • Workflow

One big problem with a multi-product solution is that each has its own log-in and security model. Moving from one function to a function in another product is almost never seamless. Data migration can be an issue. Ease of use suffers. Training people to use one platform is hard enough, but training them in a collection of tools is much harder.

Often few, if any, of the tools are proposal specific. You might be able to use them to solve proposal-related problems, but they won’t be designed for it. This generally means extra steps that lower efficiency, and different terminology that results in less ease of use.

Keep in mind that people define “proposal” differently. For a product company, a proposal may be a catalog of line items plus pricing. For a services company the heart of a proposal is the technical approach and a management plan. For some companies, most proposals are similar. For others, each one is unique. Some have single authors; some have huge teams working on their proposals. The result is that, designing proposal software is very difficult — everybody has different, often conflicting, needs. Thus, even with software designed for proposal development, you often have to tailor it to your particular environment.

Looking At VPC Functionality

Consider some of the things you might want a VPC to provide:

  • Boilerplate storage, access, search, and retrieval
  • Document templating
  • RFP requirements allocation
  • Scheduling
  • Assignment tracking
  • Lead tracking
  • Proposal planning
  • Proposal reviews
  • Collaboration
  • File exchange and management
  • Version control
  • Configuration management
  • Status tracking
  • Reports
  • Notifications and approvals
  • Contracts management
  • Estimating and pricing
  • Access controls
  • Access inside the firewall
  • Access outside the firewall

While the list above will appeal to most proposal groups, the devil is in the details. Each may want to do the above in different ways. Thus even a package that did everything on the list might not do it the way you need it done.

Creating a VPC Requires Making Trade Offs
Low cost, full functionality, ease of use — Pick any two. The trick is to make informed trade-offs. If you sacrifice some functionality, you may be able to get good coverage from a combination of low cost easy-to-use tools. The odds are, however, that all but the most simple of VPCs will require a certain amount of custom software development.

  • Nothing can do all of the above “out-of-the-box” in all the different ways that people do “proposals”
  • Even if you achieve full coverage through multiple products, you’ll need to some construction to “glue” them together.

Understanding how much time and money you have to invest and what will be required to do what you want is critical to a successful VPC implementation. The lack of time (to define the requirements and design the solution, let alone build it) and money (most proposal shops are overhead expenses with lots of pressure to keep budgets low), are why most people use a set of tools without ever linking them together to form a VPC.

How Much Should a VPC Cost?
There are typically two components to the cost: software and services. Let’s look at the service side first. Services typically include design, development, installation, configuration, training, and maintenance. The cost of the services is ultimately based on the cost of the labor times the level of effort. Some of this you may be able to do in-house, and in-house hours are accounted for in different ways. In-house effort may or may not impact your budget and totally change the equation.

In order to establish a baseline, let’s try an example. If your firm sells services, you can look-up what it charges for services to get a range. I’ve seen rates that run from $50/hr to $250/hr. We’ll use $75/hr or $600/day just to provide a baseline. If you anticipate 30 days of effort to build your VPC, you’re looking at $18,000. If you anticipate 90 days of effort, the cost would be $54,000.

That is before you add the cost of software licenses, servers, parts, connectivity, consultants, travel, etc. Let us assume that these costs are comparable to the service costs above. Also, there may be on-going costs for software maintenance, version upgrades, connectivity, etc.

The result is a range that runs from $20,000 to over $100,000 for a full-blown VPC. If you survey the market, you’ll find most solutions fall into that range. If you don’t like those numbers, you have to change the rate or the level of effort to get a different result. You can build a VPC for less, but you’ll have to sacrifice to do it. Low cost, full functionality, ease of use — Pick any two.