originally posted by Paul Alexander: (link) - please comment at original post
Nothing brings resources together closer than an RFP Response team. Team members are hounded, questioned, examined, challenged, corrected, but most of praised for a job well done. In the end, a solid RFP Response shows critical thinking and experience in the craft. It's not easy, it's not even always fun, but two-thirds of the way through one of these, I get jazzed and the puzzle seems to fall in place. Quarrels and sleeplessness abound, it is a part time job for most of us, but we need to make the most of our time and impress our customers.
Still learning, but here are some takeaways to share?
- Force engineering and integration teams to work very closely together in the estimation - Siamese would be best :-). Challenge the level of innovation, the complexity of design, and the overall spirit of the completed solution since if these two teams get it wrong, we're doing something w/o a paddle.
- Rely on SME's to assist in the estimation, but don't assume and request the entire org get involved. It's too expensive, and context switching for resources makes it worse. Define an RFP Reponse Team (RRP) and don't alter resources since learning curve is usually very high.
- Just because there's solid RFP details doesn't and shouldn't limit the need for scrutinizing everything - RFP owners expect to answer questions as long as they're posted before the deadline. Put 'em to work!
- Run a tight ship as a PM and consider this a project - a far more critical project than others perhaps since a) you're sucking bandwdith from the org, and b) a painful, incomplete response can lead to dissatsifaction quickly.
Remember to please comment at original post: (link)