Web Project Debrief: A One-Page Document for Quick Post-Project Analysis (Free Download)

After hours upon hours of designing, coding, and communicating, the project is finally done. Whether the project’s a success or a failure, you can rest easy because it’s launched—complete—over.

But before wandering to the next project, you should take a moment to reflect on what you just spent the last few weeks or months working on.

What did you take away from the project? What errors did you make that shouldn’t be repeated in other projects? What did you do right that should be repeated? These are questions I posed to myself recently after wrapping up a project. I sat at my desk, wondering about the answers and trying to determine how best to capture my thoughts.

So I decided to create a quick, one-page Web Project Debrief document. The purpose of the document is to allow a project manager or freelancer to swiftly record the basic outcomes of a project. Anything longer than a page and I know I’d never fill it out. And keep in mind—I designed this document to serve as a sort of cover sheet for the data you should be recording in systems like Basecamp and Harvest over the project’s lifespan.

The Essential Web Project Metrics

Below are the fields I built into the document, which I felt were the most important metrics to log. With limited real estate on a one-page document, I had a tough time narrowing it down to the essentials, but alas, here we are:

• Total Project Hours: How many hours did it take to get the project done?
• Delivery Time: From the proposal signing to the website launch, how many weeks elapsed?
• Start Budget: What was the paid for budget of the project?
• Team Members: Who were the primaries on the project?
• Client Stakeholders: Who on the client-side was responsible for the project?
• Project Grade: Grade your project using a basic academic letter, or design your own grading system.
• Project Overview: What was the project all about?
• Client Frustration: At what points during the project did the client become most frustrated?
• Client Elation: When did the client become most elated?
• Major Delays: What items or events held up the project?
• Budget Add-ons: Were there any change requests during the project?
• Client Feedback: What did the client say after the web project was finished?

The Project Grade: Did You Pass or Fail?

Imagine yourself in grade school. The teacher hands back your term paper. It got a ‘D.’

You basically failed.

While you’ll be grading your own projects, choosing a simple symbol to show whether you succeeded or failed with a project is an exercise in honesty. But that honesty pays some nice dividends.

And just like that term paper you got a ‘D’ on, you’d want to take a second, third, and probably fourth look at any project you grade harshly. It’s a mark of failure—and an indication that you must improve.

Without this grade, you’re flying blind. If the teacher never graded any of your papers, do you think you’d have improved in school?

Avoid Client Frustration, Repeat Client Elation

Figuring out when the client was most annoyed versus when they were most happy should be an obvious metric. We want to avoid those frustrating moments in future projects. Likewise, we want to repeat the happy moments.

By recording the instances of these emotions, we can keep a log of what we’re doing right and wrong. Perhaps you keep noting the same frustrations over and over. Let’s say, for example, it has to do with too many errors with the website after launch. You know now that something with your process needs to change—and you have the documentation to back it up.

Or perhaps clients are constantly surprised (in a good way) at how fast your turnaround is on designs. You want to nurture that behavior. Reward your design team. Or see how you can replicate that success for other parts of your projects.

Using Budget Add-Ons to Increase Future Project Revenue

Budget add-ons—or change orders—is a great way to take the pulse of your client’s desires.

Maybe your base projects are selling well, which is always a good thing, but you could be leaving money on the table. By keeping a record of the various budget add-ons that occur during your projects, you’ll be able to gather a list of solutions clients are requesting in addition to your base projects.

For instance, if you note “Facebook page customization” as an add-on for five of the last ten projects, then you know immediately what clients want. Build that into your base project and charge more for it. Sure, clients may request it regardless later in the project process, but you could be missing out on larger deals if you don’t mention these add-ons upfront.

Download Your Own Copy of the Web Project Debrief

I consider this a working document, meaning it’s at version 1.0, and I plan on fine-tuning it as I discover new metrics worth tracking.

The document is available as a PDF download. You can fill it out in the PDF, or you can print out a copy and scribble your notes in with a pen. Despite being surrounded by computers nearly all day, I actually prefer printing a copy to write on. Nothing beats a tangible document that you can lift with your hands.

Also available for download is a sample document with a fictitious client and project in case you aren’t clear on what the fields mean.

• Download Web Project Debrief 1.0 (PDF, 1mb)
• Download Sample Web Project Debrief (PDF, 250kb)

What Metrics Do You Consider Essential?

Finally, as I continue to develop this document, I’d be curious to know what metrics you absolutely must know after a project is complete. Leave a comment, and I’ll consider including it in the next version!