Case StudiesGeneralPM Best PracticesTopics

Why Our Project Management Tools Don’t Matter

By 12/09/2017 April 23rd, 2021 6 Comments

As project managers, it’s easy to fall in love with one tool and let it define the way we manage projects. Perhaps in the rush to support a big project, we pushed the tool we were using to its limits, using advanced features and becoming a power-user in the process. We inserted structure and process into the tool and made it work for us.

However, despite expertise with our project management tool of choice, our team isn’t experts with our tool, nor should they be.

The agile manifesto states, “Individuals and interactions over processes and tools.” It’s easy to fall into the trap that processes and tools guide individuals and interactions; however, we know that’s not the way things work out.

As digital project managers, creating and guiding process with tools is an inherent and crucial part of our role. We should strive to master our tools, and at the same time ensure they don’t have the final say in dictating the way we work.

A Personal Case Study In Pursuing Alternative Tools

When I joined the talented team at Crema over four years ago, we were engaging primarily in waterfall-style projects. At the time, this worked best for the projects we were pursuing. To manage these projects, we were using Asana. Previously the team had explored a handful of other tools, but ultimately settled on Asana due to its incredible flexibility.

Our team flourished and continues to perform in Asana. Our team is passionate about process and experimentation, so setting up custom processes in Asana was something we enjoyed and continuously pursued. We created workflows within Asana to fit our team and our clients, all of which was very well received.

However, Asana broke down for us over the long-term due to the significant time investment in custom training. As a team, we had crafted many processes that dramatically improved our work; however, these processes added to the mental overhead required for each user of Asana.

Where other tools integrate process guidance into the tool itself, Asana put the requirement of process creation on the user.

We’ve routinely explored new tools over the years, but shied away from using them due to their lack of flexibility compared to Asana. We felt empowered by Asana’s customization. Yet, we also knew its level of customization was a growing impediment for our multi-disciplinary team. While some of these other tools were more well-suited for the work we do, we didn’t want to lock our team into a forced standard.

Over time, our team began to pivot from primarily supporting waterfall processes to agile processes, particularly Scrum. Recently, our project management team became Certified Scrum Masters, which increased our company’s emphasis on supporting agile processes. We knew we needed to change tools.

We’re currently migrating our software development projects over to ZenHub. It provides a stronger, leaner and more effective platform to do our work. By design, ZenHub is incredibly intuitive, reducing training to as little as 5 minutes. Because it is built on top of GitHub issues, it’s fundamentally integrated with the actual work my team members are doing — the code.

In light of this transition, we’re continuing to use Asana for internal operations, strategy and non-software development projects. We are also supporting some of our clients in their tools of choice, such as Jira.

Our team has arrived at a point where our focus is not on our tools, but rather on supporting our team and clients.

Our Tools Have To Serve And Support Our Individuals

When working with various individuals in and outside our teams, we may be forced into using various project management tools. We could be crafty and dive into using advanced capabilities of these tools so they can talk to each other. We could ask our teams to report on their task status in multiple tools. We could build time into our own schedule to copy and paste data between the multiple tools. Yet, all of this is simply added overhead that gets in the way of what our teams do best: develop great software.

As a digital project managers, we have to be adaptable and not wed to one tool or process. This is ok.

There are 4 key components to ensuring tools don’t matter in our success as digital project managers:

#1. Be Comfortable With The Processes That Our Teams Use

Our teams likely engage in a few project management processes to develop great software. We need to ensure that we are intimately familiar with these processes and continuously stay up-to-date with them. As digital project managers, it’s up to us to keep our team informed to ensure buy-in and understanding of these processes. Some great ways to do this include:

  • 1-on-1s to onboard team members to a new tool or process (my personal favorite).
  • Run company training sessions.
  • Follow-up with individuals on observed challenges.
  • Create and share screen-recorded tutorials that can be easily referenced.

It’s important to remember that our process or framework should be as simple and as clear as possible.

#2. Be Adaptable When Experimenting With A New Tool

As digital project managers, we must be comfortable when diving into a new tool, poking around and becoming adept in it. Along the way, we should be thinking about how to apply our processes to this tool in order to effectively support the team and other stakeholders. To effectively explore and learn a new tool, try some of the following tactics:

  • Migrate some existing project data into it.
  • Reflect on how current projects would run better (or not) in the new tool.
  • Ask some specific team members to dive in and provide their feedback.

When we start using a new tool, we should be able to train our teams in it (in person or remote 1-on-1s are the best), answer questions and provide solutions that support individual workflows. It’s up to us to educate our team with each tool.

#3. Choose A Tool That Works For Our Team

When we identify a project management tool, we should choose one that:

  • Matches the culture and style of our team.
  • Matches the type of project.

We shouldn’t get too excited about functionality that may get in the way of our process and add undue overhead to our teams. When setting up the tool, we should think through how our teams will use it. It’s important that we consider the individual styles, workflows and culture of our teams. Most crucially, we should configure the tool in a manner that doesn’t get in the way of our teams and empowers them to do their best work.

#4. Be Empathetic.

Most importantly, we should always be empathetic. When setting up new project management tools, our teams’ perspective should be primary. In most cases, our developers just want to code and our designers just want to design. Our goal, as digital project managers, should be to minimize overhead so our team can focus on their craft.

When we train our team members on new tools, we should only train on the relevant features of that tool, specific to them. We can help our teams focus by only focusing on what’s important.


While tools help empower us to get the job done, it’s important to note that standards are good, albeit to a certain extent. No two projects are alike but if we can have a shared standard for our teams to work from, it could minimize project spin up time, switching costs, and more.

We must be diligent in keeping all of the tools we use sharp, well understood and supported by our teams.

As digital project managers, it’s easy to give into the temptation to generate a bunch of fancy processes and use complicated tools; however, at the end of the day they may just get in the way. We should strive to master our tools yet ensure the mastery doesn’t get in the way we work.

What Do You Think?

How important are tools to the success of projects? How do you choose your project management tool? Let us know in the comments.


Michael Luchen

Michael Luchen

I’m Michael Luchen, a Project Manager for the incredibly talented team at Crema, where we partner with funded startups and top enterprises to craft products that change the world. I’ve managed a variety of digital projects with startups and enterprises, ranging multiple industries including staffing, wearables and non-profit. The breadth of my projects have ranged from user validation engagements to large, multiplatform projects that target the web, iOS, Android, and more. I believe in the systematic connection of business and technology to drive results.


  • Hi Michael totally agree with your blog and we found the same challenges internally actually developing a new project management tool. One of our key findings was that most project management tools were more task management focussed in that if you knew what to do that was great and they worked well. However project management to be successful the planning requirement and the gathering of all the stakeholder requirements is key and we felt all the current tools lacked this feature. As with all great products if you use it internally first and can see the benefit then commercialising is a natural progression. If you are looking to give planning a prime role in your process and combine it with task management then please give Barvas a try. Would love to hear your feedback if you try it. Regards Ash

  • Michael, having come up through the trades as a union carpenter, I can certainly relate to your blog posting but as my shop teacher used to tell us “a fool with a tool is still a fool”.

    Unfortunately in role as a mentor/facilitator for competency based program and project management training, what I am seeing are far too many people who hold PMP, ITIL or other exam based certifications who THINK they know how to use the “tools of our trade” but in fact have yet to actually MASTER their use or worse yet, use them incorrectly or inappropriately.

    Bottom line-as evidenced by the Pyramids of Giza, Great Wall of China and the 7 Wonders of the Ancient world stand as evidence that “project management” processes, tools and techniques have been around for at least 5,000 years. I would further argue there is very little that is “new” or “unique” in project management- that the tools & techniques used today, save for being automated, are not all that much different than those used 5,000 years ago. Meaning the only difference I can see is how well trained and COMPETENT the practitioners are in USING those tools/techniques.

    Dr. PDG, Jakarta, Indonesia

    • Very well said, Dr. Paul D Giammalvo. A good project manager needs to be able to invest beyond standard education and work with the techniques applied through our tools.

  • image Drew Soske says:

    Hi Michael,
    I liked what you had to say here. I started my career in 1998 and have been through the history of the ups and downs of online tools development, the change in web standards and language popularity (remember when everyone wanted to be a ColdFusion developer?!). I started coding in text editors with no love for code. Earlier still, I interned in print shops that needed the 4 colors painted onto the drums and then run the paper rolls through, etc.

    My point is that I have seen the tools (I like Asana too) become the job. Like you said the training and time involved can become “waste” and change is always the best medicine. However, on my teams, I have sometimes taken them back to my first days and run it all manually. This is a great way to get back to basics, for me too, and for team building. This ensures that we are putting the individuals over the tools while using the process.

    Well done. Cheers.

    • Thanks, Drew! I also enjoy getting back to basics. Often, my team will use whiteboards and Post-It notes as a preliminary means of planning before transferring the information to a tracking tool, like Asana.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.