The team at Sitemap and I are tying the bows on a work management system for their agency. Their COO, Grace, reached out in June feeling the pain of piecemeal systems. It sounded like this:

“A team member sent me a Google Sheet with all of our in-progress work & work we had upcoming for all our clients, and it was the most clarity I’d had in months, I feel like we’re playing whack-a-mole.”

And Sitemap is a growing team; they just secured their offices inCincinnati, and currently have a small full-time team that they lean on to maintain their operations.

But, they’re largely a team of creatives, or at least individuals who should be making creative client work their primary focus. So that’s where I came in.

It’s common for your operations to bend (or break) as you scale, and it’s beneficial to grow them along with your organization. But, in this case, growth often means focus & simplicity. 

Here’s a breakdown of what we did at Sitemap over the course of two months to plan for, develop, and implement a company-wide system to manage both their internal work & their client work.

First, let’s look at the system itself, then we’ll work backwards highlighting the decisions we made to get there.

The system itself

The home base: ClickUp

When deciding on tooling, I often weigh existing familiarity with the team quite high, assuming it possesses the functionality we need it to (most do).

In this case, the team was already using ClickUp here and there, we were already paying for it, and it has the functionality of everything we need. Done.

The cogs: See for yourself

At its core, the system understands the desired outcome and process behind the company’s work, removes the recurring and repetitive work that doesn’t require our ongoing attention, makes it easier to understand the status of a particular project or client, and becomes the home base for managing work across the organization.

The 8min video below gives you a full walk through of the foundational nuts and bolts.

As you watch, you may find yourself asking, “I wonder if X, Y, Z is possible with this?” Or, “If only I could add X & Y on top of this it’d be perfect, wonder if I could?” Almost certainly the answer to both is yes. 

Ok, now let’s understand the decisions we made to get here, which are arguably more important than the final destination.

First, we aligned on how they’re working now, and how they want to be working in the future.

With bigger operational infrastructure build outs like this, this step in the planning process is vitally important because the goal is for me, and their team, to understand the gaps we need to be addressing.

And in many cases, the journey to finding those is an insightful one.

An unexpected but meaningful moment of clarity

In order to make this project impactful, we must get a good understanding of how the team is operating now, as well as what it we’re delivering and/or producing.

What does great look like in regard to what we’re giving to clients, and what we’re putting out into the world?

Once we have that picture, it’s easier to break apart the system, reallocate ‘human hours’, and automate the things that simply have little upside to a human focusing on them.

To help facilitate this alignment, I asked the Sitemap team to provide the following information to me:

1. A list of their service offerings & what comprises them.
2. Any kind of internal SOPs (standard operating procedures) they have around how they bring these services to life internally.

I’ve found this to be a powerful exercise in getting clarity around these aspects of your business as well, which was the case

The Sitemap team rightfully took an extra couple weeks in getting me this information because they realized two things:

1. There was a lack of clarity amongst the team around what’s required to deliver our outputs.
2. In the midst of that alignment, they saw an opportunity to simplify.

An unexpected but meaningful win along the way.

How we built our blueprint for the future

Once we all got clarity around how we’re operating presently and what’s required of us to deliver great work, I set out to take what’s working well for us now & intertwine that into new streamlined systems.

Luckily at this point in the journey I’m not taking stabs in the dark around what works, and so the puzzle becomes taking principles I know to be impactful & giving them life within Sitemap’s organization while considering their services, team, and business model.

For more on the principles behind getting shit done, see: How to Predictably & Repeatedly and Predictably Get Sh*t Done

We knew the system had to help us achieve certain outcomes, like:

• Provide visibility to leadership around the status of each client, what’s in play, what’s to come, and anything they need to jump in on.
• Allow leadership to see team-wide bandwidth and assign work effectively.
• Provide clarity for individual team members around who’s doing what, when, and why.
• Allow team members to easily track their time, & allow leadership to easily find time reporting.
• Provide adaptability for the team so that making a change is simple and doesn’t break the system.

Once we knew this end goal, we created a project plan that included my proposed shifts, represented by these tasks within our project:

Second, we brought our plan to life, and tested it.

Now we kick into execution mode which, in theory, is the more-straightforward part after effective planning.

As we were giving life to various aspects of our blueprint, I was duplicating our work environments so I was able to test these systems against real work without impacting the real work yet.

This work primarily involved:

• Building task & project templates for standardized work.
• Building automations into those templates for any recurring & standardized work.
• Building supporting / SOP documentation along the way.
• Coaching the leadership and project management teams around the principles we’re using to build these systems to empower them to own them moving forward.

Third, we established a ‘go live’ plan.

Once we built out new systems & tested them, we dedicated some thought to how we were going to replace our existing systems without needing to pause operations.

This is crucial because real-life work is likely in-motion, and a sloppy transition could produce sloppy outputs for clients, something we want to avoid at all costs.

Our ‘go live’ plan included steps like:

• Working with the team’s Project Manager to transition all active work inside the new system so the team can hit the ground running.
• Completing the supporting process documentation so the team could use it as a resource as they’re shifting some of their habits.
• Meeting 1:1 with team members to help them set up a ‘personal dashboard’ that shows them what they want
• Making myself available the first week of the new systems to make small tweaks or answer new questions.

Moving forward, we’re remaining agile in our approach.

At this point, the system is live within the Sitemap organization & team members are using it fully. But this doesn’t mean that project leadership, including myself in this role, aren’t keeping our finger on the pulse & being open to adaptations that better help us achieve our outcomes.

One of our original goals for this system was for it to be agile enough to make changes to easily, but account for a wide variety of work, some of which we may not even know the specifics of right now.

One way we accounted for this agility is to create Best Practices documentation along the way, both for individual team members as well as project leadership/management.

Here’s the start of one, with each toggle containing step-by-steps, walkthrough videos, and/or other helpful resources.

But, even more importantly, we didn’t over build and try to automate every step of our process. While this can seem like the most efficient route on the surface, it often leads to more work when you need to unwind and/or adapt the heaps of automations you built to account for a unique case (which probably aren’t as unique as you think), or if (when) something changes organizationally.

Lastly, I implemented an agile approach to the buildout project in and of itself, and attempted to show the leadership team the value in a test-and-learn mentality. I’d often leave project discussions with “…we’ll keep visibility on if this is the best approach for us and if we find it’s not, we’ll adapt.”

I hope you took away something useful from this breakdown that you can use to create a healthier business. If you’re looking for additional support in building your business thoughtfully, please don’t hesitate to reach out via my contact form, or at alex@alexcartmill.com. If I’m not the best fit for you, I’ll do my best to point you in a better direction.

And if you’re looking for a fantastic creative agency to handle (and scale) your organization’s marketing, check out Sitemap.io.