Developers - What RFP Formats do you prefer?

Hi Patrick,

First of all, let me say that it's quite refreshing to see that you've spent some time researching this 'problem'. While I don't have a particular format to share, I would like to add a comments to this discussion, which will hopefully give you a better idea for what you need to provide.

The first issue with regards to a RFP for a theme is whether the theme developer will also be responsible for the initial visual/graphic design, or is this being provided. If it's being provided, I've found that its important (though not always critical) for the designer to have a sense of how drupal works, what features (modules) are being utilized, and what the the clients expect/desire with regards to end-user experience. It's always helpful to give reference to other sites or example of work flows that meet those expectations. The more examples or references to how something should look, the better. Therefore, when a designer is providing the visual mockups to a theme developer, its important that they provide a compete set of (ideally) annotated graphics which explain in detail what should happen when user clicks this, or slides that, or presses this button, etc.

Another thing regarding theme development is that it often overlaps with site development, in that a particular module is responsible for providing a visual element, and therefore the theme developer must work with, or be in sync with the site's developers. That is, they can't theme what doesn't exist. As you've read, this issue accounts for a huge gap of understanding in that clients often think that a theme alone can provide the user experience they're looking for, when in reality there is need for consistent coordination between theme developer and site developer.

With regards to delivery and timing, I've found that the breaking every chuck of work down as small as possible is beneficial for everybody. I try in my proposals to offer a task by task breakdown, with an associated range of time that I guess it will take. For a decent sized site, this will translate into hundreds of line items, each with an time estimate range. From there, its rather easy to contractually tie payment to meeting of a particular milestone (group of tasks). I've also found it helpful to offer bonuses for early completion of milestones, and penalties when a client changes specification mid-development. The penalties part is never liked too much, but without that, we all know what happens- people change their mind about something once they see it, ask the developer to change something, and voila, you're behind schedule.

Much of what I said above also relates to developing a site or module as well. Well, I hope some of this is helpful...

As an aside, a client I once worked for recounted a good rule of thumb with regards to engineers/developers. He said that every engineer has number on their forehead, a number that they can't see, but everyone else can. That number is the multiplier that you must times their initial estimates by in order to have a accurate estimate of how long anything will actually take. The most professional developers will a) have a number closer to 1, and b) have a sense of their number and build that into their original estimates.

Good luck with your project, and try to give back anything useful that you might come up with...

regards,

Noah

Noah - thanks for the insightful reponse...very well said!

Patrick - to echo what Noah mentioned thanks for taking the time to do some initial pre-planning.

I work for a boutique Drupal shop and do almost all of our proposals and bidding on projects. I will first give you the bad news - my experience has been that many Drupal firms simply ignore RFPs...the risk (time/energy to answer) is not worth the reward and there is lower hanging fruit available. Keep in mind, the largest Drupal shops in the world may have 20-30 employees and most are probably in the 5-15 headcount range. RFPs are usually better suited to be answered by much larger organizations - a lot of RFPs are also viewed as nothing more than fishing expeditions and a way to get free advise. Instead, I would identify a short list of shops and come up with some qualifying questions to interview them. You can can compare responses, and the right vendor will probably surface.

To reiterate what Noah said, I usually breakdown a Drupal project into bite size chunks. These line items will include:
* Who is handling creative - do you already have PSDs that you can hand off or do you need us to generate?
* Is there a roadmap in place - are you completing the site architecture documentation or need us to? This would include user/system interaction, taxonomy, a module list, site map, etc. I know my biggest pet peeve is when I get calls from prospects who say I want to clone site "x" - how much will that cost? It's good to do competitor profiling, and tell us in as much specificity as possible what you like about the various sites.
* Are there any unique requests that we need to account for (i.e. migrating an existing database of users, custom modules need to be created, etc.)
* What are your SEO expectations - is this a site where page ranking is critical?
* Who is handling hosting?
* What kind of technical acumen does your staff have (i.e. how much training will you need post launch to administer the site)?
* Who are the stakeholders that will be involved in decisions - is there a committee in place, one person, etc. - how fast can we expect feedback?

Finally, be up front with your budget! I know the thinking is usually that if I tell a shop my budget then they will come in $1 under what I tell them, but the reality is any reputable shop should be able to justify the level of effort they propose - we've all bid on projects only to later learn that the client's expectations were completely unrealistic given the scope of work they wanted. However, one of the beauties of Drupal is that it is highly scalable - you can always take a phased approach to your site build out if you have a sensitive budget and most firms will work with you. I'm sure you will see that Drupal rates runs the gamut, but in the end I do believe in the adage "you get what you pay for." Again, do not let price be the sole factor in your evaluation process - it's a formula for disaster.

Hope this helps,
Dave
Mediacurrent

Subscribe