September 22, 2015

Project Drag

Have you ever taken a project where, along the way, you see that your client’s organization is not really setup for doing the kind of work required. You can feel the silos, you flip through the book-length spec documents, observe the handoffs, the pixel-perfect expectations. Often, it feels like you’re running into the wind.

Over the past few years, I’ve been observing what has worked as we’ve found ways to be successful in environments that don’t embrace the kind of flexible, iterative thinking required to do great work on the Web these days. The following is my attempt to explain how you can not only survive a large-scale, enterprise, responsive redesign, but how you can thrive.

Agree on the Goals

It’s our job to successfully drive a project from where we are, to where we and our client agree it should be. A start and an end. Simple. With this ultimately simple view of a project, the biggest challenge is that you and your client may not share an understanding of the goals of the project. So, as simple as it seems, you need to spend the time to agree on the goals—agree on what you’re building, where you’re going.

There has been a lot written about stakeholder interviews, user research, and clearly defining the goals of a project. So, I won’t waste time here explaining how to do this. Just know that, without this agreement, it’s nearly impossible to be successful in a client/vendor collaboration.

Measure the Project Drag

Once there is a shared vision of the goals of the project, you need to measure the project drag. Let me explain. Imagine for a moment that you are driving a car. It’s a beautiful day, so you roll the windows down and reach your arm out the window. You can feel the air flow, trying to slow you down, pushing against you. This is drag—“a force which tends to slow the movement of an object through a liquid or gas.” In this scenario, the object is your hand and it’s being slowed by the wind resistance as it travels through the air.

Project drag is much the same. It is all the forces that are trying to slow your project as you attempt to push it through the process and achieve the agreed upon goals. So, how to you measure project drag? Turns out it’s not as difficult as you think. There are two major factors that impact project drag. They are team size and organizational variance.

Team Size

Start by making a list of all the people who will impact your project. If you’re working with a small business, this might just be the CEO and the Director of Marketing along with two or three folks from your team. If you’re working in an enterprise environment, the size of the team can be massive. I’ve been a part of projects with over 50 people involved in the work. Stakeholders, Directors, Tech Leads, UXers, Designers, Developers, Security Leads, Sys Admins, Marketers, Web Producers, Brands and their Art Directors and Content Producers… The point here is that you need to understand the number of people who can make or break your project and the amount of influence they have on those around them. Generally, smaller teams will create less drag and larger teams have more potential for a high amount of project drag.

Organizational Variance

The size of the team needs to be considered alongside the organizational variance. What I mean by this is that you need to understand the differences between the organizations collaborating on the project (which is at least your organization and your client’s organization). This includes differences in company culture, process, approvals, communications, and the list goes on. What we’re actually capturing here are the expectations that each team brings to the project. The more variance there is between the organizations, the greater the project drag.

These two factors—team size and organizational variance—combine to help you understand the potential for drag in your project. It’s not that you’re bound to fail if you have huge teams with a great amount of organizational variance. It’s that you need to be intentional with how you shape the project.

Shape the Project

Put your hand back out the window. Turn it so that your palm is facing forward and feel the drag. Now, turn it flat, so that your palm is facing down. Notice how much the drag decreases.

We can use this to our advantage. If we know there will be a lot of drag, we can shape our project in a way that reduces the drag. Since it’s unlikely that you can greatly reduce the size of the team, we do this mostly by reducing the organizational variance. Look for areas of variance where neither side of the difference will dramatically impact this specific project and then be proactive about closing the gap.

Quick example: perhaps your team is fully invested in using Sketch to lay out static design ideas but your client’s designers (who will also be involved in the project) are using PhotoShop. Certainly, your team could probably work faster with the tool they love. But when you consider the impact this will have on the project—the drag it will create—it’s pretty easy to see how choosing to work in PhotoShop will reduce drag. You are closing the organizational variance gap. You are compromising. The same could apply with Sass or LESS, with Grunt or Gulp, with Slack or Skype. Even with something more fundamental like designing comps or designing in the browser. You get the idea. I’m not telling you to change how you work completely. I’m suggesting that selecting the easy variances and being willing to close them will help the project in the long run.

I was involved in a project once where we were not required to work within the client’s system for measuring progress. We saw this as freedom, so we jumped in and started working! We got a lot of work done in a short amount of time, but we were ignoring the organizational variance. Internally, our client was struggling because it didn’t appear that we were making progress. After some discussions, we shifted how we worked and fell into their system. This allowed us to demonstrate our progress and to start to build trust with our client. We got rid of an organizational variance and it decreased the project drag.

Another way to shape the project is to identify the project advocates and skeptics. An advocate is someone inside your client’s organization that believes what you believe about the project. They believe it strongly enough to fight for your ideas internally. If you’re just getting started with this client, chances are you have only one or two advocates, if any. And, don’t be fooled, if someone isn’t actively in support of your approach and involvement, they are a skeptic. Skeptics may actually work against the project, or they may just take a neutral stance, waiting to see how you do before the choose a side.

It doesn’t matter how good your work is, if you want to be successful, you need to convert the skeptics to advocates. Doing this is like adding an aerodynamic windshield to your hand. It lowers the project drag and gives you the opportunity to work faster.

So, how do you convert a Skeptic to an Advocate? Find out what they care about and shape the project to show value in that area. Demonstrate how your team and your way of working can help them. Pretty soon, you’ll have them advocating for your approach and you’ll continue lowering the project drag.

Repeat

The dynamics of a project change all the time. This kind of thinking works best if you are continually monitoring the situation. How many advocates do you have? How many skeptics? What is the influence of each? Are there areas of organizational variance which are causing problems? Find a way to close them. And, of course, keep a close watch on the goals of the project. If those shift, you could find yourself cruising 110 MPH toward the wrong destination.

Writing Process