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.