I came across a very interesting blog post by Jonathan Rasmusson. This post discussed The Agile Inception Deck, a project chartering technique that a co-worker created to help agile software development teams get their projects started off on the right foot. Like all things Agile, it is light-weight, easy, direct and very practical. As I read through the ten points of the Inception Deck, I couldn’t help but think that this technique would be a great way for teams preparing to respond to a request for proposal (RFP)* to get started also. The ten points of the Inception Deck are not applicable solely to building a software solution. I can see their applicability across nearly any variety of project you are trying to plan. See what you think, here are the ten points of the Inception Deck:

1. Why Are We Here? – Succinctly describe why the customer needs this project. Identifying (or assuming) the customers drivers for this project will better position you to make insightful and balanced decisions later in the process.
2. The Elevator Speech – In thirty seconds or less (the time it takes to ride an elevator a few floors), describe your solution – the who, the what, and the why. Mr. Rasmusson includes a nice template to help you get started.
3. Design a Product Box – The purpose of this exercise is to describe the top three most beneficial aspects of your solution, and perhaps a slogan or catchy phrase you can use repeatedly throughout the proposal (i.e., a theme).
4. Create a NOT List – Creating a NOT list helps identify what is in scope and what is out of scope, and helps set expectations for the solution.
5. Meet Your Neighbors – Meeting your neighbors is all about identifying your delivery team; PM, engineers, analysts, developers, testers, trainers, writers….
6. Show The Solution – In this exercise you architect the proposed solution — but simply. In the proposal you might have a very detailed and elaborate depiction of the proposed solution. Here we just want enough to talk about so everyone is familiar with the basic components and concepts when they start researching and writing.
7. What Keeps You Up At Night? – You should approach this section from your customer’s perspective and identify the risks they assume or perceive. The risks might be operational risks that your solution will mitigate, or risks with the project you are proposing. The more risks you can identify, the more they can be addressed in the actual proposal.
8. Size It Up – Develop a rough timeline for the proposed solution. Will the project take 6 weeks or six years?
9. Be Clear On What’s Going To Give – This exercise will help the proposal team identify trade-offs and develop strategies around them. These trade-offs might be technology-oriented or project-oriented.
10. Show What It’s Going To Take – Finally, taking it all into consideration, what will it cost to deliver this solution? Again, this is not a detailed analysis, just a SWAG to help focus and orient the writing team.

The intent of the Inception Deck is to get the customer and members of the development team on the same page at the start of a project. Well, isn’t that also what you are doing with your proposal writing team? Obviously, you won’t have a true customer to participate in these exercises with you, but you have the solicitation, which usually contains dozens (hundreds?) of requirements that speak for the customer, as well as a proposal leader who should have a vision for the final solution. Also, it is probably clear, that practically none of this material will make it into the final proposal; however, the thoughts, ideas, and vision will.

I encourage you to read Mr. Rasmusson’s post and reflect on whether this technique could help you harness and focus the energy and talents of your proposal writing teams.

* RFP – In the government sector, where I work the majority of time, projects are announced through a very formal process called a Request for Proposal. The RFP usually contains a set of requirements or statement of work with enough details for respondents to craft a proposed solution and cost. The process for crafting the response is usually long and tedious.