Typically large organizations like Lullabot approach projects with either an Agile or Waterfall approach, but both have drawbacks and pitfalls. In addition, both require quite a bit of project management overhead. For Waterfall projects, that investment comes up front. With Agile, it happens throughout with frequent communication and meetings, sprint kick-offs and reviews. I've always been fascinated by an approach described by 37 Signals in "Getting Real"

Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.

Getting real is less. Less mass, less software, less features, less paperwork, less of everything that's not essential (and most of what you think is essential actually isn't).

Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.

Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software.

Getting Real delivers just what customers need and eliminates anything they don't.

-- Getting Real

In order to put the theory to the test, Lullabot recently employed a small, three-person strike team to design and create a significant site for MIT in less than four weeks from inception to launch. This presentation is the story of what we did, and, more importantly, what we didn't do in order to meet this aggressive timeline, and keep our team small and lean.