Using an Inception Deck to Respond to Proposals

Posted by sroth

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.

Comments

  • Thank you for the comments sroth.

    You are right. The inception deck can be used for just more than software projects.

    It all stems from wanting to ask the tough questions early in a project, and make sure everyone is aligned before we begin.

    Thanks for you thoughts.
    Best of luck on your projects and RFPs.

    Cheers – Jonathan

    • Jonathan, your post led me to your book, The Agile Samuai. It is a fun read and just the right depth of coverage of Agile process and technique. I am using it in a talk I am giving management later this month. Thanks!

  • Scott,

    Good post. The idea of tying the Agile Inception Deck to the RFP process is definitely relevant given the amount of repeatable (yet not necessarily consistent) work that goes into developing these.

    The one key thing I would add to your list is a “compliance manifesto”. Unfortunately, the government (Federal, State or Local) has an insatiable (and you could say insane) need for a myriad of compliance items to be provided–most of which seem to have very little with either the solution requirements or the qualifications of the vendor.

    Further, if this Inception Deck could be tied into a structured authoring schema and associated tools (such as DITA and the DITA toolkit), then we could really be talking efficiency.

    I’m looking forward to your presentation! Thanks.

    Jim.

Leave a Reply