Waterfall. Agile. Lean. Extreme. Kanban. If you think I’m naming new exercise fads, you’d be wrong. These are just a handful of different Project Management methodologies and processes. Some companies let their process define what they do. At T+L we want our values to define how we work. I realize the difference between the two approaches isn’t extremely apparent, but as a Project Manager, I assure you they are not the same.

Take for example the Waterfall methodology. The team is briefed on a project and the work begins. There might be some preliminary planning and strategy exercises, which will inform the wireframes that the IA then creates. The designer will take these wireframes and apply the aesthetics. Lastly, the developer takes the designs and implements them. Through each step of the process, the agency waits with baited breath for client approval before moving on. And at the end of the project, we have a fully functional, beautifully designed platform or product. Right? Well, not always.

What do we do at T+L?

The team gets briefed on a project and then, through a number of exercises and collaborative working sessions, we refine and prioritize our approach. We allow for the possibility that we may throw out the original objective because we’ve found a better one. And what’s really weird is that the whole team is involved. Even the client (because from day one, they’re considered an integral part of the team).

Then, once we’ve settled on what we’re delivering, we begin making it together like one big happy family. The architecture isn’t completely nailed down before work can begin in design; planners are involved throughout the process; design decisions aren’t always made by designers; and developers aren’t just waiting to be handed some final, approved designs.

Collaboration every step of the way is non-negotiable. Because epic shit comes from the right team making decisions by using the product and not being afraid to change things or throw them away. As a PM here I’m not enforcing a set of rules and steps in order to keep things progressing; instead I’m keeping a close eye on the natural progression of the project and making sure that the road ahead is clear so that we can work without restriction.

How?

There are a few key things I’ve learned.

1. Educate the client and set expectations

Sounds simple enough, right? Well, there are some things that can easily be taken for granted that will throw up huge roadblocks. Educating the client up front on how we will be working and where they fit in cannot be stressed enough. I can’t expect that the client will know how to respond to a framework prototype with no design. I can’t expect that they understand that building something we may not use isn’t a waste of time. I can’t expect that they know when and how to give feedback so that it doesn’t interfere with the flow of the things.

2. Daily meetings are THE BEST

This sounds like I’m lying, but I’m not. And I’m not just saying that because I’m a PM. We have a team meeting every day. We spend no more than 15 minutes going over what we’ve worked on, what we’re going to tackle next, and what are the blocks. It’s amazing how much can change in 24 hours, and if I wait too long to get everyone in a room we could be looking at a week wasted with nothing to show for it.

3. Know the difference between wasting time and wasting opportunity

If I wanted my job to be easy (read: boring), then maybe I’d insist on using Waterfall because I only have to keep track of one thing at a time. But as we’ve seen, projects where processes are siloed and things are created in a vacuum don’t yield the best or even the right results at the end of the day. We may build something based on the wireframes that we don’t realize is “wrong” until it’s been developed – and at that point it’s already client approved so backtracking can be a nightmare or even impossible. My team has to be able to create things without being married to the work and without fear that changing their minds will result in catastrophe. Educating the client plays a huge role because I have to set the expectation that we can, and probably will, change our minds. But I also have to make sure the team has a platform for collaboration so that we can spot issues or discuss alternatives quickly and without major consequences.

We create epic shit, and how we do it isn’t defined by any process you’ll find in a textbook. But that’s because we believe that what we value, making products that customers will use, means that the entire team decides how best to create something by building it and using it together.