Discovery Done Right

We here at Kalamuna believe in the power in science, and aren't in the business of making leaps of faith in regards to web development.  We try to avoid superficial "let's hope for the best" scenarios with all projects, and aren't interested in putting ourselves or our clients in painful situations.

With that said, it's our opinion that it makes little sense to sign an agreement before both parties have working experience and knowledge of one another.  We think that executing a Discovery phase after you've signed a MSA and SOW is just a drunken sorrow-fest waiting to happen.

You don't really want to "discover" that you've already married Buffalo Bill, do you?

Think about it: why would either party want to embark on a web journey together before clearing the murky waters?  Why would a web shop want to find out, after they're locked in, that the legacy code and/or database is more of a mess than anyone previously thought?  Why would a client want to get in bed with a team who hasn't demonstrated its value in any way outside of a lovely-looking proposal?

Major stress is incurred by both parties during the RFP process.  Not to say that RFPs have no value, but the requirements outlined in the document may not be fully fleshed out, have best practices in mind, or even be possible.  There's always gray between the lines.  Web shops tend to make up for this by buffering their quote in fear of losing money.  I'm not even going get into the time spent crafting a proposal (chalk full of brilliant guesstimates) that will more than likely not be accepted.

There's got to be a better way, right?  Well sure enough, there is!

We've been responding to RFPs and client inquiries with Project Evaluation Proposals (PEPs) which offer a tangible Discovery deliverable related to the impending project.  Depending on the general need of the client, our proposal may offer a site audit, information architecture consultation, and/or a development plan. 

The benefits are many-fold for both parties.  For the development team, we can make more accurate estimates that focus on profit rather than survival and save a lot of valuable time writing proposals.  Also, we get to know what we're getting into and are able to make solid inroads with the client.  Clients receive a portable document that is useful even if they decide not to proceed with us.  As an added bonus, they get to witness how we operate and how well we execute the Discovery SOW.  Perhaps the biggest benefit to a paid Discovery is that the beginnings of a healthy, trusting relationship is fostered.  It is this relationship that will lend heavily toward the project being successful.

OK, so all that sounds great, but how does it work?

At the time of this writing we're a small (but POWERFUL) shop, so our methods are different than others.  We connect with clients using a PEP or a conversation about our iterative process, which includes a paid Discovery.  After considering the client's needs, we send them a brochure with...

• An executive summary of their project and how we can help
• A summary of what a Project Evaluation is 
• A list of initial questions and Discovery deliverables based on gray we found in their proposal
• A final pitch for starting a project and relationship the right way
• A fixed price for the Discovery, and a buffered ballpark quote for their project
• A portfolio of sites and projects that we've done

We've clocked our time for PEP construction and we can produce a solid document in under two hours.  A developer first takes a look at the technical requirements to generate a list of questions and comments.  After that, we curate the information into our Project Evaluation proposal template, clean up the grammar, and send it off.

The deliverable for the Discovery phase depends on the project.  For instance, if the client wants to migrate from Drupal 6 to D7, we will audit the modules and theme layer, provide a breakdown of our findings, and after discussion with the client, provide fixed estimates for the various paths to a successful port.  We interview the client about their goals and needs to set the stage for phase two: the actual project process.  Pretty cool, yeah?

Wait, there's more!

I've attached a (redacted and very old) Project Evaluation Proposal that we sent to a potential client, who we will call "Death Star Fathers of America."  This proposal, like many, was not accepted, but at least it didn't take us a day and a half to churn out!  Please feel free to use it as a guide to build your own PEPs so that we can spread the legitimacy of an open and thoughtful development process, and reduce the pain commonly associated with the website construction process.

Awesome Additional Resources: 

• Stop Writing Project Proposals by Jonathan Wold
• Put the RFP Down by Adam Mordecai