Dealing with six degrees of client separation

Since we specialize in web development, we work with many other agencies that pull us in to complete one piece of the overall project puzzle. This is great work for us but can get complicated the more layers that exist between us and the client. I recently learned some tough lessons about being too far removed from the client. It was a project with a huge company that you'd recognize but shall remain nameless.

We’ll call them Mega Corp.

Six degrees of client separationA common scenario for us is where a business hires a design studio to make them a new website. The designer creates the design and hires us to do the development. This works great for all parties.

  • The designer gets to focus on creative and strategy without having to worry about hiring or managing developers which plays to their strengths.
  • We get a steady stream of new projects from our design partners without having to find and close every deal ourselves.
  • The client gets a great outcome through the benefit of working with design specialists and development specialists. (It’s rare to find truly great design AND development under one roof.)

One of our design partners recently brought us an exciting project with Mega Corp. The project scope was well within our capabilities and we have a great relationship with this partner so we jumped in without asking too many questions.

We knew there was another agency between our partner and the studio. But it wasn’t until the project was well underway that we learned there was yet another agency between that agency and Mega Corp.

There were three other companies between us and the end client. I’ve worked in a lot of outsourcing situations before, but that was a record for me.

Challenges

The further removed we are from our clients the harder our job becomes.

Communication is harder because there are multiple parties involved. Questions and requirements get passed through multiple people before they get to you and often detail and nuance are lost in the translation.

Project management is more challenging because there are more people to involve in meetings and discussions.

Scope is harder to manage because each company has a contract with the other up the chain but may not have the same level of detail. It becomes difficult to get approval for something that is clearly outside the scope of our contract but more of a gray area of a contract between two other parties.

QA becomes more tedious. In our Mega Corp project 25% of development time in the project timeline was for actual development. The other 75% was for multiple rounds of QA because each agency wanted to make sure it was up to their standards before passing it on to the next.

Everything takes longer. Decisions, deliverables and approvals have to pass through multiple layers.

Lessons Learned

In the end, we successfully delivered the project on time. However due to the extra project management and QA that was required it took roughly double the amount of resources on our team as expected. That killed our margin. And since we’re at the bottom of the food chain in this scenario we can’t use Mega Corp’s real name in our portfolio.

It's not the end of the world, but we did learn some lessons that will make us better in these situations in the future.

  1. During scope definition identify all of the parties involved and clearly state their roles. Ask a lot of questions about who is the ultimate decision maker, who controls the budget, who has input on the process, who needs to approve, etc. Even if you’re dealing directly with the business owner sometimes there are consultants involved.
  2. Spend extra time up front adding additional details to the statement of work. This will help clarify scope issues that may come up during the project.
  3. Clearly define the QA process. How many rounds of revisions is the client afforded? Is a 3rd party QA service involved? Who needs to approve the work before the end client sees it?
  4. What level of white labeling is required? Does the end client know we’re a separate company or are we represented as part of another team? Will we be given another email address to use in our communications with the client? (I once had an agency print business cards with their logo and my name on it for a client meeting.)
  5. How are we going to deploy the final code to the client’s server? If we’re many layers removed from the client we may not have direct access the the client’s server or technical team.

Have you ever had a bad experience because you were too far removed from the end client? Share what you learned in the comments.

Posted April 10, 2013 by Jason Siffring

Jason has over 15 years of web development experience and is the owner of Surprise Highway. Follow him on Twitter or Google+.

2 comments  

Angie Herrera Angie Herrera
on April 10, 2013

Great post Jason! I don’t think we’ve ever been that far removed, but those questions are always good to ask. And from the other side, they’re good to ask if you’re the one contracting the additional individuals or team. Thanks for sharing this!

Jason Siffring Jason Siffring
on April 10, 2013

Thanks Angie! Good point on the flip side of those arrangements which is to find out if subcontractors are being used and ensuring everyone is adding value along the way and not just adding markup.

Add your comment

Howdy Stranger
How to deploy your code
← Previous
Chicago web developers
Next→
© 2017 Surprise Highway Inc.