Responding

I have been working on a lot of large scale RFP's lately. I find the work interesting because it allows me to really think through the project life cycle and imagine how my team will best respond to the potential client's needs. My approach is to read the RFP two or three times and then basically plan the entire project in a pretty detailed way. Once I have the entire project plan established I then write an approach document which adapts my process to the specific requirements as defined in the RFP.

When an organization has gone through the process of developing an RFP they will often have well thought out ideas about how to approach the project. This does not always align with my own theories. For instance, the discovery process may already be mostly complete. If an RFP has detailed requirements this means I do not have to tease them out later on.

For the type and scale of projects which I typically respond there is usually a team of people involved. This is another interesting dimension I like to explore. I have found it very useful to treat the response like any other project, with a timeline and deliverables which address pre-defined requirements and expectations.

Something as simple as defining the styles used in the documents which are authored by different contributors before they are written and then assembled into the final 'book' will save the team a great deal of time. For this I use a tool I call a content deck template. I also share this with clients who will be delivering content for integration with their new CMS during real development projects.

The further I get the more appealing planning and good communication becomes...