You’ve finished the process of getting budget, shopping for, and buying project management software. After months (or more) of painstaking research, you sit down with a sigh of relief— and that’s when the real project management problems start.
As arduous as software buying can be, that’s often the easy part. Implementing it brings its own host of project management problems.
From team members who refuse to use said software to terrible data migrations, the costs of bad implementation add up. In 2015, the average stock decline for a public company enduring a known software failure was four percent. As a result, the total loss in market capital from these stock price dips was $2.7 billion.
Now, the good news: This doesn’t spell doom for your own implementation. If you’ve just bought project management software, a bad experience can be avoided with some (wait for it) project management. The key is to confirm that you’ve done your homework beforehand by:
- Preparing your project team members that new software is coming;
- Confirming that it’s the right time for your team to start using new software;
- Explaining how this new tool will benefit the team.
To help with next steps, we’ve outlined four project management problems to watch for. And since we’re not ones to leave you hanging, we’ll share steps to solve them as well.
Lack of leadership
Project management can feel like you lead everyone and no one. After all, you must motivate your team to bring projects to life— even when that team might not report directly to you or you might not control your projects’ budgets.
As a result, it might not be clear whether you own the software implementation process. That can cause confusion throughout your project team— especially since folks will likely have strong opinions about the software you’ve purchased and how they should use it.
“[Every] office had a different viewpoint on how project templates should look, what the average length of each task and milestone in those templates should be, and how user management should work,” recalls Alexander Bekhterev, program manager at Emarsys.
“It was like having [too] many cooks in the kitchen, as they say. It was not easy at times to agree on those points because every person’s project experience is so different.”
Tell your team and stakeholders that you will own the software implementation process and are happy to hear feedback. But make sure to clarify that while you welcome ideas, you will make final decisions.
Conflict resolution is an unpleasant aspect of project management, but you own it nonetheless. Daunting as this can seem, it’s a blessing in disguise. Poor communication is the culprit for one third of all project failures. Instead, you can use this implementation to set a transparent tone for your team.
“[Having] a moderator or a leader to make final decisions is important,” says Bekhterev. “Even smaller groups of people can slow down during times of disagreement and it is important to have someone who can resolve conflicts quickly and enact the optimal solution.”
Too many stakeholders
Along with being the point person for team members, project managers must manage stakeholders. Your project will impact folks within and beyond your business. At the very least, many folks within and beyond your business will think they’re impacted. That means they’ll freely share opinions about your new software.
It’s possible that various stakeholders will have different goals for using said software. As a result, they might want different configurations for project creation, milestones, reporting, and more. Even if the tool you’ve chosen is flexible, your stakeholders might not be.
Limit the number of stakeholders that you’ll consult to help implement your software. To begin, start by reviewing which frameworks and processes you’d like to use this software for.
Ideally, each stakeholder will have experience managing project teams themselves. If so, they can advocate for their team’s wishes during the process.
“In the end, we [had] just five people running the implementation of the new project management tool and never worked separately after that,” Bekhterev remembers.
“Our team of five consulted local teams and broader user groups to obtain more insight and perspectives, but only those five were allowed to provide input in the end.”
Bekhterev held calls and meetings to confirm that each team lead was on the same page. During every session, they debated questions like these:
- “What fields and data points are we bringing from SFDC?
- How many project templates should we have?
- What kind of templates are we going to create?
- What’s the average length of the sender domain DNS setup task in X template?
- What kind of reporting do different managers need?”
Everyone had to agree on the answers before team leads proceeded with the data setup.
Training remote team members
A Gallup survey released last year found that 43 percent of Americans said they worked remotely at least some of the time in 2016. This is made easier due to the rise of project management tools that allow users to team up from anywhere.
But remote work is not without its hardships. When a team is geographically dispersed, social isolation becomes a big risk.
“In our case, every Emarsys office (we have 15 globally) had its own vision of how they managed projects, what the inputs and outputs were, and how the new project management tool should be configured,” says Bekhterev.
“For example, people in Berlin, Hong Kong, and Indianapolis, Indiana, had different opinions on what information each project should contain upon creation, what should be automatically pulled from SFDC, and what should be entered manually.”
Include leaders across locations in your stakeholder team. Then, give them some autonomy over how to use the software within their own teams. For example, it’s important that everyone on your project team uses the same software: Mandatory adoption is a key part of making new software work.
But if teams in different locations used different workflows pre-software, give them the freedom to keep doing so. If a process is effective and familiar, allowing employees to keep it will decrease resistance to a new tool.
“To ensure a certain level of localization, and to help resolve minor disagreements, each office was given the flexibility to set their own hourly rates, project groups, and custom project templates,” Bekhterev says. “In the end, we launched an 80 percent global platform with 20 percent localization in less than three months.”
Despite these suggestions, don’t put the cart before the horse: Custom workflows are no use if your team members don’t know how to use your new software. Make sure to schedule several training sessions—including live demos— to show all team members how to use the software. Then, assign tasks for employees to create, modify, and complete events within it.
“If you’re switching over to some new project management software, be sure to teach everyone how to use it,” says Alexander Winston, managing director of PPC Protect.
Although that sounds obvious, he stresses that many tools are not intuitive to users. Rather than relying solely on the vendor’s customer service team, take training into your own hands. “Project management software can be a great timesaver and boost your team’s efficiency, but only if everyone knows how to use it!” Winston explains.
Integrating it into your work culture
It’s common when applying for jobs to share why you’re qualified for a role. That said, it’s less common to question if a company’s workflow is the right fit for you. If you’re a night owl, a job with an 8:00 AM start time might not be a match.
Getting new software often follows the same process. If your project team works in a specific way, introducing new software can cause disruptions. And if the software’s features misalign with your team’s needs, productivity can nosedive.
“After nine years of work, I can assure you that the biggest challenge after buying project management software is to integrate it into our work culture,” says Cristian Rennella, CTO and co-founder of elMejorTrato.com.
“The biggest problem with project management software [tools] is that they generate interruptions in the work. This means that they do not allow a programmer to focus on their work for several hours in a row to reach their highest concentration and thus better efficiency in their work.”
Configure your new software to meet your culture’s needs. Many project management software tools have custom features that let users choose how often they’re interrupted.
To solve this problem, Rennella encouraged his own team members to use Basecamp‘s “work can wait” feature to block notifications during certain hours. “[Basecamp] is configured so that every day from 8:30 AM to 12:30 PM and then from 2:00 PM to 5:00 PM, no emails or notifications are sent to users’ cell phones or browsers,” Rennella explains.
“This allows them to focus on what’s most important: the job.”