Show me a remodeler’s computer and I’ll show you a bunch of unfinished documents that were never put into service because the remodeler was scared to put something out there representing the company that wasn’t “perfect.” I’m talking about employee and customer/project handbooks, written scopes-of-work, CAD standards, purchase orders, policies/procedures, and even marketing materials.


Gen. George Patton, the legendary World War II commander, once said “A good plan violently executed now is better than a perfect plan executed next week.” The problem with waiting for perfection is that it never comes, especially if there’s no way to gather feedback from document users and then roll those suggestions back in to the end-product. I’ve examined documents from hundreds of successful remodelers and builders. Believe me, there is very little correlation with a successful, popular company and how slick their documents look. The best companies have those systems and are using them–warts and all.

Here’s the other problem with documents that are never finished: They create stressful mental clutter. Every time you turn on your computer, there sit the unfinished documents demanding your attention, stressing you out. That’s not proactive management of your time.

You can break that cycle by using a method I’ve learned from software developers. Most employing some form of “iterative development,” meaning the take a controlled approach to the features they include.

When software that’s being created reaches a state where it’s usable (but far from “perfect”), it is released as a “beta.” Developers use the beta period to gather information about problems from the users themselves. They’re looking for anything from spelling errors or formatting problems  to buttons that don’t click or that make the program crash.

Then, at some point in the future, they take everything they’ve learned from their users and roll the corrections back into the product, re-releasing the software with a new “Version Release Number.” This cycle repeats throughout the life of the software, at first to fix the bugs and later to create and issue new features and functionality.

Here’s how remodelers can take exactly the same approach with their document systems:

1)      Establish document naming conventions. How you name documents is a very important part of this system, and the key is to be consistent. For a “Framing Scope of Work” the document name might look like this:

011514-FRAME_SOW-0.95.docx

Note that the name consists of four parts:

  • The date issued (in this case, 011514)
  • The name/type of document (FRAME_SOW)
  • The version number (0.95), and
  • The file extension (doc.x) Note: You need this only if you're using a Windows-based system.

    (Note: We’ll do a complete column on document naming conventions in the near future)

2)      Create the document in question and save it with a “version number” that is less than 1.0. I like to use 0.75 (75%) for very early “alpha” versions and 0.95 for beta versions.

3)      Start using the document immediately, but make sure users know to leave suggestions if they find errors or items they want to add or change. You need a painless way to capture and store this. A special email folder or a dedicated Evernote.com notebook both work well.

4)      At first, you may have to do immediate correction on errors of fact or other serious omissions, but rest assured those will go away very quickly, allowing you to settle into the regular review schedule.

5)      At some point in the future–perhaps quarterly at first, but eventually just once-a-year—you’ll review all the input and make all the changes to all of your documentation at once. I like to do this during annual planning meetings. If you have department heads, they should be responsible for the documents their department uses.

6)      Finally, after the corrections are made, re-issue the document with the next “version” number. If the first release was named 0.95 (Beta) the next “true” release would be 1.00. Major releases (2.00, 3.00 and so forth) indicate substantial new features or sections to the document, whereas “point” releases (1.10, 1.25, 1.30) are used to document minor corrections.

Another side benefit of using an iterative approach for document management is that for most of the year, instead of having 200 documents in various stages of completion, and all nagging you for corrections, the whole issue of documents goes away until those scheduled updates.--Joe Stoddard is an industry consultant helping remodelers be successful with their technology. jstoddard@mountainconsulting.com