The Importance of One-Pagers

by Jason Golden 6. October 2011 16:15

At Exsilio Solutions, we use the Agile project management methodology for software and solution development projects. Where the traditional Software Development Lifecycle (SDLC) waterfall approach requires extensive design and documentation before a single line of code is written, we find our clients are better served by the Agile approach, which allows for shorter iterations, and changing requirements as development progresses (within reason!). Particularly for our tech clients, business changes fast, and we offer exceptional value responding to those changes with them. In fact, it’s consistently positive feedback we receive from our customers.

But you can only make changes so much, and it does have to be managed to keep from being randomized, as well as knowing when you’re done with a deliverable. Additionally, tweaks to scope usually happen in phone conversations, and sometimes in deep e-mail threads, which are both hard to trace when development is done.

Realizing we need to bridge the gap between being as Agile as possible, and risk having no documentation, we believe strongly in the use of one-pagers. What’s a one-pager? First off, it’s never just one page. But when a new feature set is outlined verbally, or extended from the brief form in the contract, this document is where we expand and detail exactly how the feature will work. Usually they start as a few pages, a narrative into the user behavior when it’s done. We include early mockups, and are careful to call out not only what the feature will do, but also what it will not do. Using the Review features of Word, we can easily collaborate with the client to refine or adjust the one-pager to meet their expectations up front, iterate with it as the project unfolds, and document in one place when those changes took place, and what they were.

By the end of a project, the one-pager typically evolves into a multipage document, more resembling a functional specification, but not quite as detailed as a technical specification.

There are many ways to create these; we find good one-pagers contain the following:

  • Title of the project and feature set                                                                                            
  • Date the document was created, and last updated
  • Changelog of date and what was updated between drafts, in a summary table for quick viewing
  • Overview of the feature (one more than one paragraph)
  • Background on why we’re building the feature, typically the business problem being addressed
  • Details, with a section for each component of the feature. Include mockups or screenshots, if available.
  • Appendix with supporting tables, code snipets, etc.

We hope you find them as useful as we do, let us know if you have any examples to share.

Tag cloud