Working at an Agency Doesn’t Have to Suck (Or, Rules for Project Managers)

A thread on Reddit last week titled “Does web development at an agency always have to suck?” ignited a lot of conversation about the difficulties of agency life for many developers and designers.

The poster cited how their agency seems to have a complete disregard for process, management, or good development practices. Their project manager just forwards email from the client, doesn’t properly scope out projects, and has a complete lack of respect for how long it actually takes to create a project. And, based on the comments, it seems like many other people experience this too.

As a project manager at an agency, it made me sad to read this and hear about the horrible management that most people have to deal with. A large portion of my day is spent finding ways and doing things that make my developers and designers’ lives easier. I like to say that I’m the shepherd of our creative team — I make sure they know what they’re supposed to be working on and remove any hurdles to their work, and also protect them from wolves in the form of out-of-scope requests or unreasonable deadlines.

So, to that end, I’ve laid out a few of my thoughts on project management at an agency, what I call Shepherding Your Creative Team. I should note that it’s a broad overview and there are many important elements of project management that would not fit in an article of this size. I encourage you to jump in the comments if I’ve forgotten something or to share your own thoughts about project management at your workplace, either as a PM, developer, or designer. I recognize that each agency has its own needs and workflows, but hopefully this should help you get in the right direction.

Far and away the most important thing is process. You need to create a process that respects each team member’s role, places prevention of future problems at the forefront, and is clear to all parties involved — client, upper management, creative staff, and client team. It should be adaptable to every project and, crucially, must be respected and enforceable. Once you have your process created, defined, and shared, the other elements will be easier to put in place.

The first step is to think about your team’s current workflow and what the bottlenecks are. Do you often have last-minute design changes? Are your developers unsure of what the elements are supposed to be on a site? Are your clients frequently late with content/hosting credentials/other key pieces of the puzzle? Now, think about what you wish that workflow looked like, and write it down. You won’t get it perfect the first time, or the second time, and that’s really not the point. Your process should be constantly adapting and improving.

One of my favorite ways of thinking about improving a process is to loosely apply Hegelian Dialectic. Hegelian Dialectic is the concept that every idea follows the same general path: an idea is proposed (the thesis), and there is an opposite idea (antithesis). They merge and become the synthesis, which then becomes the new thesis, which is opposed to a new antithesis, and so forth. Everything keeps building in this triangular fashion.

If you’re wondering how this relates to process and project management, it’s simple: there is always room to improve the process, and instead of trying to get to a “perfect” state, you should try to push things forward and get to the next step of the ladder. Processes should be living, breathing things that are constantly being refined and improved based on feedback, observations, and results.

You also want to empower your team to suggest improvements to the process and suggest them. Your developers and designers should ideally feel like they have a seat at the table rather than being forced into a process that doesn’t work for them.

Now that we have the philosophical underpinnings of our process, let’s talk specifics. The second most important thing you need is managing expectations. If expectations are clear among everyone involved, you will have far fewer problems. And the way to do this is to have clear communication on your team and with the client: everything on your team should be transparent, and communications with the client should be clear and frequent. (Some people may argue that this is more important than process, but it’s a chicken-or-the-egg argument.)

This encompasses a lot of different elements of the project:

Decision on type of process (Agile or waterfall) & clearly stated stages that are communicated to all participants and stakeholders

Many agencies are switching to an Agile workflow (more iterative with development sprints and concurrent work), but the vast majority of agencies use a waterfall process (sequential — design, then development, then QA). Whichever you choose, make sure your team and your client clearly understands the stages of the process and how they all fit together. (Since most agencies follow waterfall, this article makes some suggestions that assume a waterfall process. Feel free to disregard them where appropriate if you have an Agile team.)

Scope, scope, scope

Scoping out a project can be one of the most time-intensive parts of a project — and if it’s not, it should be. After all, if you don’t know what you’re supposed to be doing, you can’t know if you’re working on the right thing. At a minimum, you want to make sure you’re devoting adequate time to discovery and planning with the client (what do they want, what don’t they want, and why do they want it), and ideally distilling that into documents (like a Creative Brief) that are shared amongst your team and their team so everyone is aware of the scope of the project. You want to make sure that you’ve created a detailed site map and functionality requirements at the beginning.

Definition of — and respect for — roles

You need to make sure that roles are clear from the beginning on the project, on your team and the client’s team. On your team, make sure there are clear hand offs between individuals (for example, from designer to front-end developer) and that everyone has what they need to get their job done — and that they aren’t stepping on each other’s toes. On the client’s side, you want to make sure that all stakeholders, not just your point of contact, have the chance to weigh in and are included in the process from the beginning. This way, you can hopefully avoid being in a situation where you end up delivering a finished product that doesn’t reflect what the person who’s ultimately paying the bill thought they were getting.

Clearly stated timeline & respect for time

A key part of the project planning process is setting a timeline — and discussing things that may affect it. When building out the timeline on your end, include the key milestones (wireframes complete, design complete, etc), the deliverables you’ll produce (wireframes, integrated site, training, etc), and the deliverables you’ll need from the client (content, hosting credentials, etc). Similarly, your client team needs to know that they cannot promise any timelines without checking with the creative team first — whether it’s for something “simple” that, to them, seems like it would take 15 minutes or a six-month site build. Since you have the big picture of all of the other projects going on (and it should be, at the end of the day, your developers who determine how long something takes), any commitments about time should be made by the creative team.

Related to this is respect for your team’s time. If your team is regularly working 10-hour days or weekends, you, the project manager, are not doing your job. Your timelines should leave extra space for contingencies instead of being idealistic. You also need to make it clear to the client what your expectations for feedback are and how that impacts the timeline. For example, if your timeline assumes assumes 12-hour feedback on designs from the client, you need to state this in the beginning, make sure it fits with the client’s reality, and make sure they understand that if they take 36 hours to get back to you, the project will be delayed. Which leads me to the next point…

Signoffs — or, Enforcement

None of this matters if you’re not going to enforce any of it. If you tell the client that you expect a 12 hour window for feedback and they take 36, the launch date needs to be moved back a day — and they need to know this from the start. (Though, ideally, your timeline should leave enough room for contingencies like this.) Similarly, if you follow a waterfall process and say that features, functionality, and look & feel are locked in after design is complete, but they come back to you with a feature request during integration — you need to be able to tell them that it’s out-of-scope and will add additional time and cost to the project. To prevent these situations, you want to have clear points of signoff established during the project planning phase. Make sure that the dates for signoff are made clear in the project planning documents and that your expectations for turnaround are known to everyone on the project.

You may be saying to yourself, well this is all well and great, but how do I make this work day-to-day? And we’ve spelled out what we expect of the developers and the client — but what about me, the project manager?

First, you need to be on top of all of your projects. Using a project management app — like Basecamp or Trello — is the first step. Unlike the Reddit poster’s PM, don’t just forward emails from the client. Things need to be translated into granular to-dos or stories that are actionable. Remember, you’re the shepherd of your team. If you’re lazily forwarding emails with requests from clients all the time, you’re not doing your job, which means your team can’t do theirs. You should also be hosting short scrum or standup meetings every morning so that everyone knows what their priorities are for the day and has a chance to bring up any issues. (We’re a punny group and call this morning meeting Kitchen Sync.)

You also want to use tools that let you stay on top of the projects and how they all fit together. Even though everyone hates it, time tracking is key to making sure you’re staying within budget (I like Harvest). You also need to make sure you’re on top of how the project timelines fit in together — what I call Project Tetris. Many people like to use whiteboards with sticky notes for this, but Forecast does a great job of this too. I would suggest putting the timeline in Forecast during the project planning phase before sending it to the client to make sure it jibes with your other deadlines.

At the end of the day, the most important thing to remember is that you are the shepherd of your team and that the buck stops with you. If your team is working late, it’s your fault because the timeline wasn’t properly created in the beginning. If the project is launched later than the original deadline — and the client is upset about this even though they were delayed in getting you key items — it’s your fault because you didn’t make their role and deadlines clear in the beginning. If the developers develop the wrong features for the site, it’s your fault because the project wasn’t adequately scoped and the requirements communicated.

With all of this said, it’s important to note that there are always exceptions. Maybe you get a last-minute contract for a site that needs to be done in an extremely short timeline but the agency is receiving a generous fee in exchange or could receive a significant amount of work in the future because of it. Maybe there are times when the client has a last-minute feature change but the relationship is more valuable than holding your ground. But generally, these exceptions should be few and far between. And even when there are last-minute projects, your process should still be followed — adequate scoping, clear roles, clear communication. Fire drills should not be the standard operating procedure.

Remember, you are the shepherd of your team. Be their guide, protector, and leader. And if you keep running into these problems despite your best efforts, it’s time to look for the antithesis of your current process and make that new synthesis. Always be working towards the next synthesis.

PS. I should note that I can’t take credit for this advice. Everything I know I’ve learned from my boss and mentor Erik Rapprich.

P.P.S. If you want to work at an agency that functions like this, Engage currently looking for a Web Project Manager.