Four Must-have Spreadsheets for Tracking Website Buildouts
After the honeymoon phase of web strategy and concepting is over, the nitty gritty begins. For big-picture thinkers, buildout becomes a tiring chore because it’s all about managing the minutia. It’s doing a lot of small tasks over and over again in a repeatable way. It’s tracking continuously the status of thousands of small, moving pieces.
For many folks, it’s overwhelming. And if you’re not organized well or tracking the right things, it becomes a big mess in a hurry. So how do you get (and stay) on track?
For me, it comes down to a few key spreadsheets.
Yes. Spreadsheets.
With all the sweet, zippy apps for web project management, spreadsheets sound lame. And I guess they kind of are. But when I don’t have budget or tools, I have to make do with the basics. Most of the time I find my spreadsheets actually track things in a way that incident bases or workflow systems often can't handle and my nifty grids end up complimenting these other project management tools.
Honestly, I live and die by these rows and columns, without which I would never make it through a large-scale web launch with sanity or confidence.
1. A Big Timeline of Tasks
Each project I work on is different. Different clients. Different technologies. Different goals. What I’m hired to do changes depending on the project and existing skill set of the team. Sometimes I spec out and monitor the build out of a CMS. Sometimes I prep and load tons of content. Sometimes I train folks in on best practices for content processes and management.
Whenever I jump into a project, I always start by making a big list of tasks that need to happen. Then, I look at how many weeks we have till deadline and prioritize everything based on their dependencies. What needs to happen before content loading can begin? What comes before testing? When do we need to start talking about SSL or production environments?
At the beginning, everything seems overwhelming. But once I have the tasks organized into a loose timeline, taking a step forward becomes a lot more manageable.
Here's a quick look at a couple weeks of my list from a recent web redesign and CMS migration project.
Once we got closer to launch, my big list of tasks evolved to look more like this:
Not the prettiest thing I’ve ever created, but this grid is just for me. I don’t show it to clients. I don’t project it at internal meetings. My timelines are a little messy, but they need to be fluid as I realize what’s missing and rearrange things to make it all fit.
Basically, my big list of tasks keeps me on the rails and it’s what I refer to when people ask “so where are we at?”
2. A Roadmap for CMS Buildout
If I’m on a project to help facilitate the build out of a CMS, I need a way to track functional specs and content structures.
To start, I talk with the content and design leads (maybe developers too) to create a list of all content types/templates/modules (whatever the preferred nomenclature). Then, I sit down with the development team and talk through everything. My goal is to identify which widgets will take the most time to build or need to be reconsidered. This conversation helps set our priority for buildout and raise red flags early.
Once I have a full development list and a priority order, I create a grid with lots of worksheets to define the functional specs of each template, module, or widget.
Here’s a snippet from a job posting template for a university during a new CMS buildout:
Taking the time to write down each detail not only helps me hash out development needs with programmers but also gives me a specs list to test against when I’m QAing what they’ve built.
3. The Loading Grid
For any website buildout, I need to track every page, content chunk, or asset we're putting in the site. I need a record of everything that’s being written, collected, optimized, loaded, and proofed.
I need to know the intimate details of these assets. I have to get crazy about these details. I have to fall in love with these details.
The loading grid is my holy grail.
While there are newer tools and apps to track a mega list of assets for loading, I still like to use a trusty Google spreadsheet. It’s simple. I can share it. Most people can pick up on it pretty quickly. I can see all my assets in one place, and I can easily add new columns when I realize important details I’m forgetting.
So where do I start? I take the IA for the site and plug it in like so:
Then, from there, I add columns.
My columns flex depending on the project, but here are some basics for most of my loading grids:
Status of asset - Where's it at in the process? Is it assigned to Jim for writing? Is it ready for loading? Is it loaded but missing some links to pages that aren’t built yet so we're going to have to update it?
Location in the CMS - Where is it going? If I already have my structure and CMS built out, I like to provide a link so loaders don’t have to dig through a potentially complex folder structure.
Content type or loading instructions - What template will the content use in the CMS? Any unique widgets or modules? Any other buildout instructions? Here is where I make sure my loaders know exactly what they’re building.
Link to content that’s prepped for loading - If my content is ready for loading, I place it in a shared location that’s easy to access. I often use Google docs so I can link directly and share them easily.
Images - Does the page need images? Have they been selected and optimized? If not, what sizes or aspect ratios do we need? Who’s providing the assets? Often, I end up creating a new worksheet just for tracking images:
Files - Any PDF or other documents going on the page? If so, where are those files?
Proofing link - If I’m using the grid to track proofing and my proofers don’t necessarily know their way around the CMS, I’ll provide a link so they have quick access to exactly what needs review.
Over time, the spreadsheet starts looking more like this:
And it grows appendages for anything that’s too gangly to fit into one worksheet. (I often break big sections of IA into multiple worksheets or create a separate worksheets for tracking forms, images, etc.)
4. Browser and Device QA Checklist
Not long ago, I wrote an article on how to plan testing and QA so I’m not going to regurgitate it here like a mother bird. I’ll let you read the article.
Basically, any tracking system for browser/device testing includes two things:
What needs testing (site functionality)
Environments where testing needs to happen (browsers/devices)
Again, I go into the full details and give you a peek at, yes, another spreadsheet in the article. So please give it a read if you’re struggling with how to find a testing/QA system that works for you and your team.
Your systems are only as good as your ability to keep them current
Ultimately, your tracking systems are only useful if you keep them up to date. So even if spreadsheets make you want to poke your eyes out, it’s important to update the status whenever you make a change (load an asset, prep a photo, test a widget in a browser).
If you die tomorrow, your teammates will thank you. If you’re having a fuzzy Monday morning, you’ll thank yourself.
And if you absolutely hate doing it, find someone who loves tracking the meticulous details of any successful website launch. Believe me, we’re out there and we can’t get enough of this stuff.