We’ve come very close to banning the phrase “kick-off” from our Sparkbox cultural language. It insinuates an expectation that a project can begin with the blow of a whistle, the team naturally and immediately acting as one unit, progressing on target toward a definite goal.
This does not happen.
The beginning of a digital project is an exciting and sometimes ambiguous time. It is a marriage of the disparate expectations, contexts, and challenges of many individuals. The possibilities are endless—but so are the unknowns. At Sparkbox, we’re shifting away from the expectation that a project can be “kicked off”; instead, we are embracing a process of discovery with our customers.
In this article, I’ll walk you through a narrative of our work with Shoes for Crews, a recent ecommerce partner whose successful project was served extremely well by a nimble and collaborative Discovery—an initial engagement with a smaller budget and defined, shorter timeline with a focus on defining the right problems.
Putting The Right Foot Forward
Shoes for Crews (SFC) has been an industry leader in footwear safety for more than 30 years. This team knows shoes. Their slip-resistant shoes are in the finest restaurants, the greasiest kitchens, most hectic medical facilities, and industrial manufacturing operations. They are a leading brand, but they were in need of a revamp. SFC began reworking their entire product line, realigning their brands, and looking for the next generation of their ecommerce platform.
Like many longstanding online sellers, SFC was selling through a fixed-width large-screen website accompanied by a separately managed mobile-specific website. Not only did the SFC team wish to refresh their online appearance to align with refreshed brands and products, they wanted to consolidate these separate code bases into a single, modern, responsive platform.
When we began conversations with SFC, they already knew their scope was ambitious. A new website, built in a new way, all while releasing new brands and new products. That’s a lot of “new” at once. They also needed the new site live in around six months to align with their product relaunch. The tall order kept getting taller.
But SFC started off on the right foot. When they contacted us, they were open and transparent about their situation, foundational for a successful engagement. Challenges were laid on the table. Capacity and capabilities were openly discussed. When we outlined a need for openness, creative solutions, and true cross-team collaboration, they were immediately on-board.
The Purpose of Discovery
There are many risks involved in enterprise software projects, but the largest risk is building the wrong thing. All too often, large projects are started based on a list of feature requests and a load of assumptions. However, every project has unique needs and challenges so no assumptions should be made about the best path forward. We are very open with our customers that this is the case, and we were clear on this with SFC. We agreed that, despite an urgent deadline, the right first steps included a Discovery. The goal? Make sure we build the right thing by solving the right problems.
In Discovery, we work with our customers to understand the project landscape to identify and define the right problems to solve. What’s happening in the business? What technology do they already work with? What capabilities and capacity does the internal team have? What is driving the deadline? How is budget best handled? Exploring these things will uncover the most relevant and pressing problems.
Collaboration also begins in Discovery. We are quick to tell our customers, as we did with SFC, that working with us is a major time commitment on their part. We cannot define problems and plan solutions without the ready input of our customers. This early collaboration builds a model for how our teams will work together in later phases of design and development. Trust—in both directions—is key to successful partnerships, and trust is born during Discovery.
Ultimately, this Discovery engagement could produce artifacts such as a technical strategy, experience strategy, and content audit, which would serve as guiding lights for subsequent design and development. Every Discovery would also produce a project brief and collaborative estimate designed to outline the future work based on knowledge gained during the initial engagement. All of these things result in a more defined project as a product of more defined goals, leading to less risk.
The Discovery engagement begins immediately upon project agreement. In the case of SFC, we began with stakeholder interviews. From executives to developers and marketing to infrastructure, we sought to understand the current state of the ecommerce platform, the vision for its future, and its place in the business.
What we learn in stakeholder interviews varies. Direct access to these key influencers, however, benefits the project immensely as we are able to ask direct questions from an outsider’s perspective, providing the project an even more direct path. Stakeholder feedback is factored into all of the work that follows.
Depending on project needs, there are a variety of other activities that might occur in the early days of Discovery. Content audits, user interviews, user flow documentation, and performance benchmarking are all good examples of work that can be done early and with few dependencies while providing valuable context for what’s to come.
For examples and further explanation of Discovery artifacts and documentation, check out this article from our KUB Utilities case study.
In-Person and Hands-On
This is the fun part. With every Discovery we have an in-person, collaborative strategy meeting, preferably at our client’s location and with key project participants in attendance. Every one of these strategy meetings is different, designed to fit the needs expressed by our clients and evidenced in the previous stakeholder interviews. They last anywhere from one to two days and, though they require a major commitment of time and energy, they are always well received and found valuable.
For SFC, this strategy meeting lasted just shy of two days, focused on recovering unknowns, prioritizing needs, and engaging our two teams to begin working together as one. As SFC found, there are no spectators in our strategy meetings. We are hands-on, out of our seats, and adjusting on the fly. It’s our goal to squeeze every ounce of value out of our time together, and that requires active participation from everyone involved.
After introductions and icebreakers, we spent time with SFC defining the project. This does not mean scope definition. This is high-level nomenclature work: Is this seen as a “redesign?” Is this a “rebuild?” Is this “the responsive web design” project? The goal is to understand how the project has been discussed and defined inside the client’s organization to date. These high-level labels and definitions mean something—there are expectations behind these words. Our goal is to work through these definitions and find a new normal for the team to agree upon.
We might work through exercises such as having everyone in the room write down their definition of the project on individual pieces of paper, passing them to the front, then reading them off and discussing the similarities and differences among them.
We might ask the room to fill in the blank. “This project is ______.” Or perhaps, “This project is not _______.” These open ended exercises can provide a wide range of results, but they all lead to one very useful place. Expectations and assumptions are laid out on the table for discussion. Disagreements happen. The group is one step closer to collectively understanding the project, its challenges, and its opportunities.
After gaining some valuable insights through project definition exercises, we had the SFC team comb through their entire website to create a rough catalog of every feature included in the user interface for their ecommerce platform. This exercise is not necessary for every project, but for those that include a redesign and rebuild of an existing feature set, it is immensely important to understand what is exactly included in the existing feature set. This allows for conversation around feature requests and enhancements to be clearly recognized for what they are. It helps to visualize the work, uncover little-known features, and it informs other exercises that will follow in our strategy meeting.
Every Discovery includes a thorough audit of a client’s existing tech stack. What platforms are currently being used? How are they written and maintained? How are they interconnected? Are outside services being used? How is source control managed? How is the site currently deployed? What testing frameworks and practices are currently in place? What are the current stress points for the internal development team? These are conversations that flow so much better in person—diagramming relationships, pulling in subject matter experts, and sharing screens.
These technical conversations are critical, but they are not only for the development team. At least at a high level, we believe it is wise for the entire project team to have a basic understanding of how their product works. This creates empathy and understanding when priority decisions must be made throughout the work.
Upon initial exploration of the tech stack, we’ll oftentimes break out into subgroups to explore subsets of the stack in more detail, perhaps without the whole project team. With SFC, however, we remained as a full group, outlining and prioritizing tech stack expectations to meet in the future. All of these things were eventually captured in a Technical Strategy document provided at the end of the Discovery.
As mentioned previously, SFC had a non-negotiable timeline to meet. Aligning the site relaunch to the brand and product relaunch was a necessity. We took the team through a simple but powerful timeline exercise to set realistic expectations about how scope or budget might be impacted by the specific timeline.
We believe in working realistically, not optimistically. Through this exercise, we walked backward from the given deadline, including all of our expectations and experience for best-practices around testing and deployment. This grounded the project in reality, allowing participants to lay the timeline against personal and team calendars. It also helped us arrive at a very rough outline against which we could weigh other decisions.
“Is he really going to highlight dinner?” you might be saying. Yes, I am.
We aren’t going to get very many chances to sit down and break bread together. We believe that sitting down for an informal dinner is as crucial a part of Discovery as anything else. This is part of the “squeezing every ounce of value out of our time together” that I mentioned previously.
At Sparkbox, we believe in deep collaboration. We will be working very closely with one another. We wholeheartedly believe that the more we know and understand one another on a personal level, the greater our working relationship will be, and the greater our work product will become.
Every Discovery needs to include exploration of brand, design, content, and user experience. These topics are a mixture of objective and subjective requirements, so we’ve found that real-time, in-person conversation is key to establishing a good understanding for moving forward.
These conversations might include a group wireframe sketching exercise or a 20 Second Gut Check. We choose different activities based on a project’s specific needs. In general, however, our goal is to extrapolate from stakeholders’ feedback on these issues which can be more fluid and perception-oriented. These exercises can also be a lot of fun. They allow the team to direct some pent-up creativity and problem-solving at problems that have often been bothering them for a while.
Given SFC’s major brand relaunch, we spent this portion of Discovery exploring the direction of their new brand. In this case, our customer was doing the presenting, and we were doing the listening. It gave us an opportunity to understand how the brand was changing, what aspects of the brand were still in flux, and how it could impact the project.
Goals must be specific. The team must be able to take questions and problems that arise during the project and weigh them against these specific goals. The results can be hard to accept, but if a feature request does not support project goals, it’s out—at least for the time being.
Our philosophy of project management at Sparkbox is never to get in the way of our customers owning and driving the course of a project. This is one reason we work hourly. It’s also why we work hard to surface as much information as possible for transparent project decisions. With that in mind, we are not making decisions on an island determining what’s “in” and what’s “out” based on goals set at the beginning of a project. However, we _wil_l constantly present the goals to the team, ask how today’s decisions impact those goals, and let our customers make informed decisions for themselves.
For SFC, the project goal was so clear that it could have been easily missed, written off as “obvious,” but it was important to state. Above all else, we had to meet our April deadline with a deployed, responsive website featuring new brands and products. Our scoping, prioritization, and resourcing recommendations would all be built around this primary requirement. And although the goal seemed obvious, it allowed us to be very creative in our solutions, planning a project that was destined to meet that goal and more, despite the scale and challenges.
In addition to the primary goal, we did define some secondary goals around modernizing the codebase. These secondary goals, however, all were subject to the requirements of the primary goal.
My favorite exercise…
In Day One, we spent substantial time outlining, cataloging, and categorizing existing and potential future features of the project. In Day Two we prioritized these features. Cards representing features or groups of features were created and handed over to the SFC team. The exercise requires all cards be put up on the wall, in a single line, in order of priority, no exceptions. Sounds simple enough, right? It’s easier said than done.
This exercise is so powerful because it is so simple, and it is rooted in reality. Features aren’t completed in groups or sets or categories—features are completed one at a time, no matter how big your team is. When time or budget is tight (which at least one always is), clear prioritization is the lifeblood of a successful project, and customer ownership of that prioritization keeps that lifeblood healthy and flowing. That’s why we go so far as to literally put the cards in our client team’s hands and back away.
Defining the Relationships
We tend to close our Discoveries with discussion on inter-team relationships. We work further to define roles and responsibilities. We identify tools for communication and collaboration. We determine some short-term next steps.
When the research and interviews are complete and the jetlag wears off, the final round of discovery work begins. Our goal is to distill the effort into digestible strategy documentation, ready to guide the next phase of work.
As mentioned previously, Discovery allows us to work with our customers to understand their project landscape and identify and define the right problems to solve.
All discovery projects net a handful of deliverables, including a project brief and a collaborative estimate. The project brief captures a summary of our findings and recommendations before it breaks off to more specific recommendations, which could include documentation around technical strategy, content strategy, user experience strategy, and/or design strategy. The collaborative estimate seeks to communicate an estimate for the next defined phase of work in a transparent and open way. We call it “collaborative” because it is intended to be discussed and refined openly, Sparkbox and customer, in order to achieve the right balance of scope, budget, and timeline in context of the value of the project.
Our work with Shoes for Crews netted most of the previously mentioned documentation, and it proved invaluable in the life of the project, aligning our teams on a unified trajectory and providing the principles to adjust as progress was made. We are immensely proud of what we accomplished together. We believe it was the right work, made possible through transparency and discovery.