Do You Need a Formal Document?

One of the most common questions we get is “What kind of document is best for this project?” As with so many things, it depends; but we know that’s not a very satisfying answer. So here’s a quick primer on the Project Connections approach to this question. This isn’t the only way to think about it, but it has worked well for us over the years.

How Critical Is the Project?

In general, a game-changing, life-altering project calls for more documentation than kicking the tires on a cool idea. Another way to phrase this question might be, “How important is this project to my goals?” Alternatively, weigh its importance to whoever is writing your paychecks, or to your key stakeholders, or to your career growth.

Another possible factor here is regulation. If you feel like someone always watching what you do and wants updates on the project, it’s obviously critical to someone. That being the case, you have to decide how much you care about those watchers, and thus how critical their needs (and your project) are.

Either way, projects that matter require decisions that matter, and that requires at least some recordkeeping to ensure that you’re covering all of the important angles. Project documentation can provide valuable history (how much did we decide to budget for this?), reminders about decisions and risks, and commitments to specific actions or deadlines.

But none of this speaks to how formal a document needs to be.

How Complicated Is the Project?

Over the years, we’ve had requests for assistance with everything from redecorating projects to building nuclear submarines. (Yes, really.) The range amusing, but it illustrates something we’ve said all along: Everything is a project. What really matters is the complexity of the project — and, accordingly, the complexity of your approach.

No matter how much you crave project discipline, it makes no sense to bog down simple, definitive projects with formal documentation and rigid structures. You’ll spend more time on paperwork than you will on accomplishing your goals. Likewise, trusting complex, months- or years-long projects to collective memory is just asking for trouble.

Usually, simple projects are completed quickly and with less documentation. You might need notes for personal reference, to keep track of decisions or tasks. You might need a memo or a few scribbled notes on what success looks like, but you probably won’t need a full-blown specification or a detailed statement of work. The more complicated a project is, the more likely you are to save time or money in the long run by writing thing down in the short run.

So What Kind of Document Do We Need?

If you weigh your project against these questions, you’ll end up in one of four places.

Complex, Critical Projects. These will require formal documentation, regular team meetings, detailed reviews, and all of the usual project management controls. Keep in mind that this doesn’t necessarily imply you have to use waterfall project management techniques; there’s plenty of room for Agile project management when you commit to the related mindset. (Don’t just claim agility in an effort to get out of documentation and planning. Agile projects plan a lot more than you think.) Whether it’s traditional or agile, your approach to these projects will be — or should be — more considered and careful than other efforts, with an emphasis on risk management, understanding requirements and specifications, and clear buy-in on timelines and goals.

Complex, Non-Critical Projects. These are the complicated projects that aren’t necessarily tied to anyone’s key objectives. If your project falls into this category, your first question should be whether your time is better spent elsewhere. If a project doesn’t matter to someone, why do it? But maybe you’re trying to pull off something new in a skunk works, or working on a hobby project. Maybe it’s an executive’s favorite windmill. Maybe it’s a low-priority or flywheel project with simple objectives and many participants. You won’t be focused on these projects all the time, so documenting decisions and tradeoffs makes sense; at the same time, there’s no point in building in complex, formal documents and structures because they’ll probably be abandoned at the first opportunity. Memory joggers that document major decisions and key action items for easy team reference are perfect for these projects.

Simple, Non-Critical Projects. These are often personal projects, whether at work or home. You might be planning holiday dinner, or just going on vacation. The world won’t end if something goes wrong; decisions are easy to change, and the stakes are low. The project matters enough for you to want to do it, but not enough for you to lose sleep over it. For these projects, maximize your time and effort with thinking tools that help you make the right decisions, then do it and move on. Belaboring the issue is almost never worth it on these projects. (And if you find yourself doing that, maybe it’s more critical than you thought.)

Simple, Critical Projects. These may be personal or work related, but they have higher stakes. In the personal category, think of something like remodeling your bathroom or moving to a new home. You need to know what cabinets and appliances you want, when they’ll be installed, and how long you’ll have to order take-out. Similar work projects might be landing a new client contract or buying a new piece of equipment. The outcome is easy to envision, and there aren’t that many moving parts when it comes right down to it. Doing it is fairly simple; doing it wrong could be a nightmare. For these projects, personal notes are usually enough. You need to keep track of your work — your conversations, your decisions, your ideas — but you’ll probably be the only one to see them. As such, your notes don’t have to be pretty, or even organized. They just have to work for you.

What It Looks Like

By way of illustration, imagine you’re developing a new mobile app, and you’re trying to decide how formal your specifications should be.

  • Simple, Not Critical (Thinking Tools). You want to develop the app for fun, but you’re not emotionally invested in it. You might scrawl your general scope idea on a whiteboard or to-do list as a thinking tool, along with a few notes about features or views you’d like to create.
  • Simple, Critical (Personal Notes). You want to develop the app as a way to market your skills and attract attention from potential employers. You might create specs as a list of Is/Is-Not criteria for personal notes — more formal than scrawling a few notes, but nothing that anyone would consider disciplined.
  • Complex, Not Critical (Team Memory Joggers). You’re working on the app with a few colleagues at work over the next several months. You’ve been given a work space and a bit of company-sanctioned time to develop it, but it’s only for down time. You might generate a brief vision document, maybe even a light spec document, but you wouldn’t go full-bore on documentation.
  • Complex, Critical (Formal Documentation). You’re developing a customer-facing transactional app as part of your company’s pivot to digital, and the CEO expects monthly reports on progress. Anything less than a formal project scope statement, complete with executive sign-off and budgeting, is foolhardy.

All of these documents would be described as scope statements, and none of them would be wrong. But you wouldn’t use a multi-page formal sign-off for a personal project, and jotting notes on a whiteboard without formal management endorsement would be completely inadequate for a critical long-term development project.

Good Enough

This isn’t the only way to think about these decisions, of course, and your project environment also matters. But as these examples illustrate, the right documentation for each project depends on your goals, your team, your communication requirements, and more. You have to weigh the need for project discipline against the need to get things done. There’s no right answer, just the right answer for your project.

Leave a Reply

Your email address will not be published. Required fields are marked *