Hey Project Managers! Let's Not Talk Tools.

I recently attended BADCamp where I had the opportunity to talk shop with project managers from a number of different agencies. I had some insightful conversations and a few really good takeaways that will help me improve project management at Metal Toad. But for the most part, the go-to conversation seems to be about project management tools. Do you use Basecamp? How about Trello? Jira? MS Project? Any of the other five hundred options out there? The tools conversation seems to come up over and over again because it's easy; it doesn't force the participants to get at the meat of project management.

PMs of the world, I challenge you to this:

Stop talking about the tools first. There are plenty of decent ones out there. They all have shortcomings. There is no perfect tool. There will not be a perfect tool unless you build it yourself and are willing to invest a large chunk development time up front to build it, followed by far more time to maintain it and modify it on an ongoing basis than you'd think.

Take a step back for a moment and ponder your role in an organization. At the absolute most basic level, your job is to facilitate and get things done. To do that, you have to coordinate to the extreme to keep clients, developers, designers, account managers, and any number of other people in the loop and on task. You also have to be able to provide clear directives and to-dos, and have mechanisms to follow up and ensure tasks are completed. This delicate balance, part science, part art, is your process.

But there is no perfect process either...

A perfect process for everyone would be like a women's sample size 8 shoe. It fits perfectly on a shoe model, but likely wouldn't fit you. You can't take a project management process that another organization has perfected, implement it step-by-step, and expect to see the same results. It fits their needs, but not necessarily yours. There is, however, the perfect process for your organization. It meets several key factors:

  • It's Lightweight: Your process should provide enough organization and structure to get things done without being overly burdensome to anyone
  • It's Accepted: It fits the needs of your specific team, and gets buy-in from everyone
  • It's Evolving: Your proces should be regularly reevaluated and modified to meet changing organizational needs
  • It's Flexible: Your process should never be set in stone to the point that process is followed in cases where a simpler solution exists (AKA progress before process)

Okay, NOW talk tools.

Once you've created a process that meets the above criteria, then it's worth revisiting tools. Figure out if there are tools that fit within that process. Talking tools with other project managers may give you some interesting leads to check out, but always think about defining a process first, and then selecting a tool. Be extremely wary of picking a tool and trying to build a process for that tool.

A Better Discussion

Next time you're comparing notes at a conference, here are some helpful alternatives to "What tool do you use for time tracking?"

  • How have you had success communicating effectively with developers and giving them clear priorities for what they should be working on?
  • How do you communicate timelines and budgets to your clients?
  • What do your internal project portfolio management reporting metrics look like?
  • How do you assign tasks to clients and make sure they get done?

If the response is, "We use [Tool Name] for [Purpose]," dig deeper. What is it about the way they use that tool that works for them? There is always an underlying process at work that centers on how to get things done and help others do the same. And when it comes down to it, getting things done is what matters, right?

As Tom's wonderful blog post put it recently, "It's Not the Pen."

Comments

joaquin's picture

Too true

Too true, Adam! I've come to see success come from proper application of project management skills and processes.

I've seen a lot of tools come and go, and I've also seen PMs succeed where others failed using the same toolset. It's not the pen, but the pen is easy to vilify. Project managers should be very careful when saying a project wasn't successful because something external to them caused them to fail. Here are some examples:

  • they had a bad customer
  • they didn't have the right tools
  • the developers didn't give them the right estimates

Even if something on a project puts a particular timeline or goal in jeopardy, a successful project manager will anticipate and speak the truth to the project stake holders before things go off the rails.

Could not agree any more! I

Could not agree any more! I've always contended project management is more black art than science.

Add new comment