Development03.26.13

Being A Slave To Process Will Kill You

Dark
Light

As an agency, we believe in process. The goal is to streamline. The goal is to remove ambiguity. The goal is to become more efficient, but, most importantly, the goal is to foster a more collaborative workflow between the different departments.

And that’s why I spent the majority of last week looking at our process for developing websites and web applications and, alongside our other departments, made some significant modifications to our workflow.

There’s a problem in a majority of high-volume production agencies. We partition our designers, our developers, our content creators… and they only come together when 1) it’s time to ‘hand off’ a project to another team, and 2) one of the teams doesn’t do what another thought they were going to do, and 3) everything breaks.

The problem with this workflow is that inevitably scenario three happens – everything breaks. Development didn’t understand fully what the functionality of a UI element was going to be. Design didn’t take into account the data manipulation or programmatic logic aspect of a feature. Content writes a lot of paragraphs that don’t conform to the design layout.

These problems happen. All the time, at tons of agencies throughout the world. Clients may never see this, but those of us who work at agencies have to deal with this all the time.

When we sat down to reexamine our workflow and change our internal process, one key thing kept nagging at me:

Flexibility.

We come up with processes to prevent chaos, to tame the world around us. We tweak and we modify, and then we sit back and marvel at how we’ve made the world make sense.

Until something happens that breaks the process. Then we freak out and even start believing that the process is broken. The truth is, it might not be… you just might be a slave to it.

Being a slave to your own process will destroy you. And it will destroy you faster than not even having a process at all. If you’ve ever found yourself saying “but… This is how we do it”, ask yourself if you even know why. Unless you’re singing the epic Montell Jordan anthem. Then just carry on.

Knowing when the process works is an amazing asset – and having that process in place to fall back on is key in being successful. However, knowing when the process needs to be interrupted, or even just thrown out altogether for a specific scenario is just as critical.

Build Margin Into Every Process.

We build processes based on our idea of the best case scenario. Problem is, that rarely happens, and when it doesn’t, we still try to fit these into our ‘best case scenario’ process. I’m a big fan of building margin into every process. I’m not planning necessarily for the process to break, but I’m allowing the flexibility in case it needs to be broken. If I need to pull a developer from one project to provide service to another, I can be sure – if I have margin – that the original process doesn’t just come to a screeching halt and ripple through the entire organization. This isn’t just about time – although that’s a part of it. This is really about knowing where in the project lifecycle it can be interrupted without derailing the whole thing.

Don’t Be Reactive.

In the same vein, if you know where every project stands within the process, you can then take an unexpected event and plan for the interruption to happen. The point is to take control of the unexpected, and plan for it. Most of the time, unexpected or small jobs don’t have to be completed immediately – they can wait a week. Or two. If you have margin built into the process, you’re able to much more comfortably accommodate. But if all you’re doing is putting out fires and trying to take every item and address it immediately, you will sink.

Address an unexpected event by taking control of it.

Listen To Your People.

I had a developer on my team working on a project long term when he and I started answering a question that a client had on another project. The task the client wanted was small, and would only take a few hours to complete. He turned to me and asked if he could just address real quick, while we had the site open and the code up on the screen – rather than assess the problem and return to it at a later date. The flexibility that he sensed in the process gave him the empowerment to manage his own time. No deadlines were changed, we didn’t have to panic about the situation, we just knew what it would take to address, and knew when to deviate from the process. We used our common sense.

So, Yeah… Use Common Sense.

We tend to throw out common sense all the time when building processes. We plan for every contingency, then go crazy and become reactive when these unexpected things occur. Don’t panic. Use common sense. Assess the situation, determine what the best solution is, then determine when it can be addressed. If I know that a developer is working on a larger project, but has some margin coming up (eg. waiting on assets from design, waiting for client approval on a critical piece), I can schedule that smaller item in.

Know When The Process Won’t Work.

Seriously. This is a huge thing. Sometimes, our processes just won’t accommodate something. It’s at this time that we have to take a step back and reassess – not the whole process – but the specific scenario, project, whatever – that doesn’t fit into our process. Sometimes, you have to let the project dictate the process. This can be scary. It’s unknown. It’s necessary. Knowing when to throw out the process and let the project organically come together is more a matter of intuition than science. It can be because of a number of things – project scope, client relationship, schedule… There’s not one determining factor. Try to get the project to follow the same basic skeleton, but stop trying to fit the project into the preconceived framework you want it to fit in. You’ll likely fail, and that ripple effect through the entire organization will be felt hard.

Flexibility is the key, and understanding and knowing where everything sits in the process is critical. Believing that you have the answer in your process as to how to approach everything will be a huge failure point. Plan for some chaos – but also know how to control that chaos. Don’t be a slave to your process, let your process work for you and allow you the flexibility to no longer stress.