This article was originally written as a stream of thought “brain dump” roughly one year ago as a way to purge my thoughts after losing the reigns on a large UI design and development project. Below, I recount that story, both as a narrative and as an education to others in a similar field.
Before we take on any new project, whether it be from a repeat or potential client, the conversation of scope is one of the very first things we bring up. It’s mentioned early and often to hammer home a very simple point: we can’t (and won’t) design and build based on an incomplete* roadmap.
If we did, it could open up everyone involved to confusion, misled expectations, and in many cases, an early exit by one of the parties. We work hard to avoid placing ourselves in that position.
Recently, we had the opportunity to work with an agency that I’ve respected for a decade. The kind of shop that’s been on my radar since first moving out west. When we were given the chance to work on a large and auspicious project with their team, it was simply impossible to say no. We were honored! And like any other project, we began speaking of the project scope and estimate from the beginning.
What are we building? What is the budget? What is the timeline?
However, it became clear that the agency had sold the project without consulting a team that develops large web applications on a regular basis. In essence, we were at the mercy of what they’d sold both in anticipated functionality, but also in cost.
That facet wasn’t ideal for our team, but the prestige of the opportunity outweighed our concerns: we were willing to go with the flow in order to make it happen. The budget wasn’t off base for what we knew of the project, either, so we cautiously indicated we felt it could be enough to get the job done, but that we’d need to finalize scope discovery quickly.
The agency’s talented digital lead decided to tackle wireframes, which proved to be extremely helpful. But as we observed, these wireframes changed weekly—v1, v2, v3a, v3b—rendering any visual design progress slow.
At times we were told to hold off until another client meeting was had. As you might imagine, these meetings would inspire clarity as well as significant changes, too.
What wasn’t happening, however, was final signoff on scope. The scope would evolve, change, slim down, and grow larger which each passing client meeting. It was the great amoeba of scope, and we realized we were never going to be able to speak directly with the client.
I could tell the agency became weary over our use of the word scope. They couldn’t grasp that what we needed was a roadmap to work from. While the agency would use the word “agile” from time to time, the bottom line is that we were given a fixed budget and the scope hadn’t stopped evolving.
In the waning weeks of our roughly two month stint with their team, they remained deep in project discovery with wireframes, slowly becoming clearer and in-line with client requests.
In an effort to save on hours (an initiative inspired by their team and understood by us jointly), we provided mostly hands off guidance. At the same time, we felt an increased pressure to be delivering.
What needed to be delivered, however, was muddy.
We hopped on a late week call with our point person, their digital lead, ahead of his week-long vacation to gain clarity on a roadmap: we would wrap the scope document for the client’s expectations, I would begin tackling visual designs, and we’d get into reviews of these designs after the vacation.
We felt like we had a tangible next step, and were pleased to hear the client revisions seemed to be grinding to a halt. It felt like the project was where it needed to be! Progress would come quickly now.
Then we received the Monday morning email.
A deadline, for a working version of the app, to be delivered in less than 3 weeks. We were told to push through where we could, to hard code aspects to save time, to worry about any database connectivity later. The client “just needed to see something working” they said.
We were caught off guard. It was clear their interactions with the client contained little push back and no adjustments to the timelines they’d suggested two months prior.
The requests were not possible, and their deadline schema was entirely out of focus. The agency’s owner was very disappointed and unclear why their suggested timeline wasn’t possible.
At the same time, we were scratching our heads while trying to explain what the previous weeks had been, while also taking into consideration the weekly invoice updates we’d been providing: all of which contained very few hours in the big picture. The fact was, we hadn’t done much work yet. We hadn’t had the chance to get off the ground.
It felt like a punch in the stomach. Like an optimistic college relationship gone bad, where you find yourself explaining to friends how, Yeah, we had some problems, but nobody’s perfect. Trying to make intelligible, with as much tact as possible that, Apparently they don’t like me as much as I like them.
In the end, we were dropped from the project unceremoniously and without much emotion. As I sent our final invoice and a few words on where we feel we landed, it became clear that the idea of floating scope isn’t something we will ever do again.
Scope is gold. Scope, in this case, trumped open communication, too.
Our company prides itself in its approach to be one that is both empathetic to client requests, but also stern in the way we approach a project. We’ve seen what works and doesn’t work over the years.
In tech, in design, in digital, throwing work and hours at the wall in a fixed bid (and hoping things stick) isn’t the way we work. It simply can’t work that way.
What we learned from the experience is that we have a collective duty to educate the client, or the liaison to the client, that scope brings focus to a project. I don’t believe we failed in this instance, but we certainly could have done more.
Also, that communication about that scope provides a very stable infrastructure to work from. We learned that not having both, or a little of one and a lot of the other, can still lead to trouble.
Finally, we learned that some things don’t work out for a reason. This was a tough project to lose, both in expectation of working with their team and for the time we carved out in the months ahead. We passed on other sizable design and development opportunities along the way because of the this project’s clout.
But after hanging up the phone on our last call and observing the way the disconnect was handled on their end, it felt for the better for both parties. We wish their team the best of luck moving forward, and thank them for helping us better understand our own client-relationship process as we look towards what’s next.
Ultimately, it all informs what’s just beyond the horizon line.
*When we discuss the scope or roadmap with a client, everything doesn’t need to be in place before we proceed. But if a project is setup with a fixed bid and the budget is of importance, we make every effort to understand 90% of what we’re building before we commit.
Unlike the “agile” process, where a team may run through numerous iterations in design and functionality—where the budget is fluid and of less concern—the process of working with a fixed bid forces us to understand the project’s requirements from the start.
We can always move “wants” or “nice-to-haves” to a future phase, but the scope of what we are building in the now is of paramount importance. The client must be educated that their decisions have direct implications on the project. And the team must educate the client.