Creating Consistency from Project Scoping through Implementation

Ways of Working

The fun thing about writing is looking back at where ideas began to understand the thinking and whether or not the original intent panned out.

In May, I wrote about better connecting the dots between Business Development and Client Services through more collaboration early in the process (read here). It has been amazing to see the progress since then, most recently inviting Dan, our Director of Business Development, to a daily standup that used to include only the Team Leads involved in implementation.

Bringing Dan into this touchpoint, along with many other changes in how we collaborate, has prompted some great conversations about how we scope projects and set ourselves up for success in implementation.

I'm excited about the continued discussions last week because I could see the vision clicking for the Team Leads. I thought it would be worth committing these ideas to writing to reference later and sort through them myself.


Over the years, we've learned one of the most effective ways to evolve our process is through the SOWs we create during Business Development. Why? It is the first time we look at the client's needs, figure out how much effort it will take to meet them, and then commit to a timeline and budget.

This fact underscores the importance for:

  • Projects to look the same when they get signed as when they begin
  • Clients to understand what they are and aren't getting in scope
  • Client and project team to speak the same language, specifically regarding process and deliverables

Close Business Development and Client Services team collaboration coupled with the seemingly subtle process changes outlined below will be a good step toward achieving this vision. We've come a long way already.

1) Scoping & Requirements Gathering

Our Business Development team has been running requirements workshops with clients for several months. In the workshop, they dig into the client's website needs to help formulate a proposal, using a spreadsheet as a guide. More recently, we've gotten our Strategy team involved in fleshing out the details of our requirements and even leading the call with the client.

In recent deals, we've seen a trend with clients looking for more details on the cost and effort for all aspects of our proposal, prompting us to think more about what other conversations we can have during the "requirements gathering" workshop.

As a first step, we've evolved our Requirements spreadsheet to capture the deliverables and milestones of our process. We can then estimate our time against these steps and get a better view of whether or not we can hit the client's desired timeline and feature set. We've seen time and time again how simple shifts in the process (adding or removing deliverables, extra revisions) can impact the timeline and budget.

The next iteration of our spreadsheet is mapping out common project types. The goal here is to have a base approach for different scenarios that we can begin with, cutting down the time it takes to get to a proposal.

Some examples of project types include:

  • Shopify Build: Custom (Design & Development to start)
  • Alternate: Sprint-Based/Phased Approach
  • Shopify Build: Theme Modification
  • Website Audit

Each scenario will include a rough schedule, process steps, requirements estimates, and a staffing plan. The key here is getting all Team Leads' input captured, so there is no need to reinvent the wheel after the project gets signed.

We are not saying that every project will be the same or that they'll fit into these buckets exactly. However, we already tend to categorize leads into buckets and often try using the last similar instance as a starting point. While this works to a degree, it is a reactive way of working and makes every shift feel like an edge case.

Relevant Reading:

2) SOW (Scope of Work)

With scenario-based scoping, the scope of work is the next area for standardization, taking base requirements for each project type and mapping it into an SOW. We recently updated our SOW to better outline our process with relevant details within each phase. Having this in place will make the process that much easier.

The goals here are:

  • Clients can more easily connect the dots between the requirements workshop and the scope of work, understanding what's within the scope and how we'll collaborate.
  • The project team can reference the SOW as a step-by-step guide for completing the project.

Relevant Reading:

3) Project Tracker & Asana

This year, we overhauled how we use tools as a team and with clients. These changes involved rolling out a Project Tracker (created in Google Sheets), highlighting the most critical information for clients: project launch date, a project schedule, and a change log. For those interested, we use Basecamp for client comms. Another shift was using Asana exclusively for team task management.

Building off the idea that the SOW is a guide for the implementation team, the Project Tracker will be another touchpoint to connect the dots to the various approaches outlined in scenario-based SOWs. We're imagining the Project Trackers could directly reference aspects of the requirements spreadsheet and SOW, so there's less upfront work to get it ready, speeding up the time it takes to get a project off the ground.

With tight scoping during the requirements gathering workshop, there is an opportunity to tie these tasks into Asana. This connection could cut down the time it takes a Project Manager to get an Asana board up and running for the team. I'm also curious to explore whether or not a CSV template could further improve this process.

Relevant Reading:

4) Requirements as a Guide

Requirements! Quite a hot topic lately. With the requirements workshop in place, we know a good deal about a project before it begins. The missing piece is how that translates to the implementation team.

Looking ahead, the Strategy team will be taking the lead here. Strategists will not only be helping lead the upfront workshops with clients but also be responsible for creating a JIRA board at the project start. The board will include tickets for everything we know at that point.

Throughout the project, these tickets will act as a "spec" for designers and developers. The only way this will be a success is if they're used in every discussion and updated when/if things change.

When designs get signed off, we'll be able to move more quickly into development since the tickets will already be up-to-date. When it comes time for QA and testing, we'll have requirements centralized for reference.

We've had some recent discussions around QA and how to make sure we're testing all use cases of a given feature. What excites me about this process is the clarity of where changes like this can happen, such as the requirements spreadsheet, which then impacts how we structure JIRA tickets.


Going Forward

There are aspects of our process I'm not covering here and many others to continue exploring. For instance, we've made strides in getting Client Services to run client orientation but are working on other ways to improve that handoff.

I chose to focus on the above areas because I believe delivering on them can improve delivery for our clients, increase efficiency, and as a result, project profitability.

I hope that these changes will also:

  • Reduce confusion and uncertainty at the project start and throughout the process.
  • Help our team see the many ways a project can get done vs. view anything that deviates from our typical process as an edge case
  • Surface more creative ways to get the work done efficiently, by taking the time to dig into requirements and processes for each scenario.
  • Help clients understand what goes into a project, how they can impact time/budget, and ultimately, have a clearer picture of what their scope includes.
Join My Newsletter

Every Monday, I share weekly themes and progress in running an agency business/team and doing my best to live a good life. Details