Put The Team First, Be a Flexible DPM

“Always and Never are two words you should always remember to never use” - Wendell Johnson

I recently had the opportunity to give an attendee talk at the DPM2014 Summit on a topic near and dear to my heart -- being flexible as a Digital Project Manager (DPM). As I’ve had the opportunity to connect with more project managers in the industry, I’ve heard more about PMs attempting to perfect the processes they use on projects —  from the number of meetings they have, to the tools they use, to the agile methodology they incorporate. These DPMs seem to be striving towards a formula  they can use to guarantee a project’s success. The problem is, projects are unpredictable. Most projects have different internal teams and different client teams. Because of that, I’m a firm believer there is no one-size-fits-all process.

No matter what the tool or "process", there will always be exceptions to its efficacy — and I think it’s important for us to keep an eye out for that. When we blindly follow the process or use the same tool that we always do, we can end up with our team members and clients repeatedly asking “Why?”. Why are we having this meeting? Why do I have to communicate with this tool? Why isn’t this piece of information in the status reports?

We shouldn’t get annoyed by these questions; we should instead answer them. And if we can’t answer them, then it’s likely the right time to consider being flexible and trying another process.

Opportunities for flexibility

Below are just a few examples of ways I try to be flexible when it comes to different projects and teams. It should give you an idea of what I am referring to and why I believe flexibility can help projects run more smoothly.

Changing up your communication tool when it makes sense.

We live in the digital world. We, as digital project managers, are most likely on our computers most of the day, and as such need a way to organize and keep track of our online communications. We want to be able to refer to old messages, add to or update messages we’ve sent, and easily share information with one or more people. Tools like Basecamp can be great for that. Some of our clients, however, don’t live in the digital world. They’re comfortable with email, but may still prefer phone calls. Other clients might live even deeper in the digital world than we do, and see Basecamp as being so 5 years ago; they’ve moved on and have a bigger and better tool they use. This can also extend to your internal teams — even when you’re using a company-wide tool, you’ll still have one or two (or more) people that resist it and don’t use it in the way that you’d like. They might not read the important details you’ve included in a message because it’s not their preferred way to communicate; they also may not respond to questions promptly because they don’t pay as close attention to that communication method.

If that’s the case, change what you are doing. Don’t be married to the tool...be married to what a tool allows you to do. Be willing to try a new tool, or go back to an old standby (like email). Meet with teams face to face (in person or via video chat) and communicate that way. Do what you need to do to get both your internal and client teams hearing what you’re saying, and responding to your requests and questions.

Letting the team pick the tool they use to track tickets/user stories

We have smart and opinionated developers and designers here at Viget so it comes as no surprise to me that not everybody agrees on all the things. I imagine the same is true where you work. As an example, some of our developers love Github Issues for tracking tickets, others dig Pivotal Tracker, while many of our designers (and I) enjoy Unfuddle.

Since I enjoy Unfuddle, it’s tempting to mandate the use of it on every project — after all, I’m the one writing tickets — but I’d be doing the project a disservice if I did that. Just as with the communication tool example above, we should focus on what the tool allows us to do. What matters when it comes to these ticket tracking tools is that they let me track status, progress, and backlog items. If I try to force someone to do that in a tool they struggle with, I’ll likely meet resistance and spend more time than I want bugging people for updates, or simply be out of the loop. Instead, let the team decide what tool makes the most sense for that project. If they understand together why a particular tool was chosen, they’ll likely use it with more regularity, and with less complaining.

Changing up UX deliverables

I mentioned earlier that not all clients live in the digital world like we do, and I’d venture to say even fewer clients live in the web design world. They won’t necessarily understand what we expect of them at times, or what they should focus on when reviewing a deliverable. One of the most common deliverables that confuse clients is wireframes. If we see the client just isn’t getting the concept of the wireframe we’re showing (even after a detailed explanation of what wireframes are and the feedback we are looking for), we should look for ways to change up the deliverable.

Use real content instead of grey boxes so they can visualize what we’re talking about. Or maybe you need to add less content (more grey boxes) to allow a client to focus on higher level content organization decisions. Perhaps you should just skip formal wireframes and do a quick whiteboard sketch session instead. There are endless options for changing things up. The only thing you shouldn’t do is ignore the fact that the client doesn’t get it — find a way to show them something they do understand. This is not restricted to wireframes; we should be paying attention to our clients’ comprehension, no matter what we show them, every step of the way. Doing so can go a long way in avoiding uncomfortable, “Oh, I didn’t understand that’s what I was agreeing to” conversations.

Putting the team first

Perhaps after reading the suggestions above you are thinking “that sounds terrible...my job is not to cater to each individual”, but I’m not so sure about that. When you boil down what the job of a PM is, I think you come to something like “ensuring a project is successfully completed”. The definition of “successfully” is always fuzzy, but I think most digital agencies would see a happy/satisfied project team and client as a key indicator of success. With that in mind, I think making things easier for our teams (internal or client) is a part of our job. We should be willing to do the slightly-more-annoying thing, or work in the more-annoying-to-us tool, if it will help our teams succeed.

I do have to add a caveat here: we have to be smart about what we choose to change and adapt. It goes back to being able to answer why we are doing something the way we are doing it. Often there are good reasons why we need team members to do something, and we shouldn’t back down from those reasons just because it annoys the team. For instance, am I willing to use the ticketing tool my teams prefer? Indeed. But am I willing to use no ticketing tool at all? No. My belief isn’t that PMs need to be spineless - it’s that we should be strategic about the way we do things and what we ask our teams to do.

Process isn't static

I think the bottom line is “process” is not a static thing that we must perfect, or something that must remain the same across all projects and teams to be useful. To me, our processes should be like lighthouses, providing guidance on where to start and in what direction to go. The lighthouse helps us along, but it’s our decisions and our critical thinking that actually get us where we need to be.

Pay attention to what’s working and what’s not working on your projects, and then be willing to change things up on the next one. It’s important to learn from every experience, and while we should be starting every new project in a better place than the last, every project will still be just a little different.