Here I've drawn what can be seen as a very rough diagram abstracting what it can feel like to work with an outside firm on a project, and the role that communication (its presence and absence) can play along the way. These thoughts are derived from my learnings as a graduate design student at IIT Institute of Design in Chicago, and may not necessarily reflect the opinions of, well, anybody else who is not me. With that firmly established, please read on!
Let's imagine for now that you are the "Client" of this story -- you have identified a talented outside team (here, known in the plural as "Provider") with whom you plan to work in order to generate a compelling new product or service. One day early in the process, you meet with the Provider and present to them a set of requirements you distilled from a series of user interviews and observations, as well as based on your team's best judgment of what this product/service could/should/might be. (These requirements are represented in the diagram by the "Client Need" circles on the left-hand side.) As the Client in the relationship, you feel strongly that these specific needs should be addressed in the final deliverable, and, as such, you attempt to clearly express your rationale and goals to the Provider. A cordial conversation ensues, and things seem to be moving along!
At a future check-in between you and the Provider, however, you discover that, while you imagined both parties were on the same page, it turns your Client Needs have meanwhile experienced a slight reinterpretation by the Provider (based on their personal "Lens of Understanding"). To put it mildly, surprises are not often the most desired element to uncover in the middle of a project, but they're also a fact of (working) life. Meanwhile, it's also important to recognize that, while you as Client bring your own valuable point of view to the table, the Provider in turn have developed their own way of seeing the world and approaching projects based on prior experience, an understanding of market trends, budget requirements, staffing needs, technical feasibility, etc. Perhaps most important of all is to recognize that, despite your best efforts as the responsible and diligent Client, you can't quite predict exactly how the Provider interpreted those key requirements you shared with them during your kickoff meeting. Lo and behold, fast-forwarding to the present day, you are bearing witness to just how those precious Client Needs you so distinctly laid out have since been transformed, greatly or slightly (but, either way, noticeably) from their original state to something, well, "different" (in the diagram, now represented as the light "Client Need" squares).
Before you let frustration set in at this blatant, or even subtle (but either way untenable), adulteration of your hard work, it's crucial to remember that a team project is just that -- work requiring the combined efforts and skill sets of a group of individuals sharing a vision of what the future might hold. In our example, you as Client presented ideas to the Provider, the Provider produced their interpretation of those ideas, and now a reconciliation must occur between these two disparate sets of expectations.
It's time to take out your "Client's Intention File Tool" and go to work on that pile of awkward rocks laid before you. Well...not quite. This is far from a call to bring sledge hammer to stonework. Instead, it should be an opportunity to identify ways of retaining the most compelling aspects the Provider has produced, while honing some of the edges that are currently obscuring the critical user requirements you need to support. Ideally, this should be a back-and-forth process between both parties, an objective and civil means of identifying and clarifying the best means of supporting the complex network of user needs you have set out to meet, while keeping an eye on the interwoven nature of the design, business, and technical challenges at play.
As a side note, while I think we can and should try to get all parties on the same page in terms of project goals, desired outcomes, and the like, achieving absolute and perfect alignment is neither possible nor, in my opinion, desirable. If you strip all the creative out of the creative process, you're left with nothing more than, well, you probably guessed it: a process. I've been taught that providing space for creative leeway within the bounds of reasonable constraints can foster the growth of ideas in a way not dissimilar to how agar can spur the growth of bacteria in a petri dish. (Well, the analogy part is my own.) Ideas might come eventually by following a rote set of rules with no room to breathe, but it's probably better to bring the party to life long before all your friends have gone home, thinking you're insufferably dogmatic and dull by making them sit at right angles to each other and discuss obscure economic theory using only Pig Latin, or something equally ridiculous. I digress.
"Now what of that exciting timeline parked at the bottom of the diagram?", you might be wondering. As one moves through the Client-Provider process described above, it can at times feel like our favorite amusement park cliche, none other than that gut-wrenching emotional roller coaster. Here, we can see the Client's enthusiasm ebb and flow during this short sliver of what is in actuality a much longer process. Joy at the "new project" starting gates gradually wanes to become mild disinterest in the middle, before plummeting to the depths of misinterpretation-driven disappointment, in advance of a rebound past the cusp of project goal realignment. Providers no doubt go through their own series of sentiment shifts as the present project proceeds. I imagine their timeline, when overlaid with that of the Client, forming a graph that resembles the movement of a pair of unfamiliar dancers as they shift back and forth between who leads and who follows.
Bringing our focus back up a few levels, what is the moral of today's story? Clear and ongoing communication from both parties in a Client-Provider relationship is essential in supporting creative, team-based project work. Things may get murky and frustrating, and misunderstandings will likely occur. But in order to leverage the best of both sides of the engagement, it's important to reserve space at the table for ongoing conversations between parties. This will, in my opinion, help to support the flexibility needed to adapt to the shifting sands of what is possible for the project as it moves from idea to delivery. The question of how best to do so is something that others more knowledgable than I can describe, in rough-hewn diagrammatic form or otherwise.