Sometimes, for whatever reason, we choose a tool that does not work for our team members. Recently, I had the experience of choosing project management tools that made my life way easier, but then found out that team members had other thoughts. When is it time to scrap your favorite tool?
A Tale of Failed Implementation
Recently, I started using Zoho Projects in order to better organize and manage (so I thought!) the editorial process of a magazine I work for. I was really excited that I was ahead of the curve, and I created milestones and tasks, discussion boards, and a calendar so that the editorial team would be on board, and so that it would facilitate communication amongst team members.
After a month, the software has been abandoned. Why? Because the software did not match the project. Only one other person actually logged into the project space and actively participated in discussion. I found that instead of using the software app, my other team members preferred to message me using Facebook or Skype, email me, and upload things into Dropbox - the file-sharing program we use.
There are two ways of looking at this scenario - I could say "Wow, I'm a terrible project manager - I can't get my team to use the tool I invested time in setting up," or I could adapt and scrap the software. I chose the latter. Instead of trying to force my team members to use a tool they weren't comfortable with, instead I chose to use tools they were familiar with and adapt to the method to my team.
Counterfactuals and Project Management
The team I manage for this particular project is a remote team - and perhaps this is why the software I used didn't work. Perhaps if we were all located in the same building, we'd be better users of the software I created the project in. However, I doubt this. In addition to needing to adapt to the culture of the team, it's really important to adapt to the composition of the team and to the work-styles of the team.
We have a small team of three management level editors and then we have a few assistant editors - six people at most. Perhaps as the magazine grows, and we add editors, project management software will become a more vital part of the tracking process.
Additionally, because the team is made up of contract workers who all have their own methods for tracking projects, it makes more sense to use a system that integrates into each person's already established project management method. Rather than requiring each editor to learn a new system for tracking tasks, it makes more sense to develop a system of action item tracking that allows each editor to integrate that system into his or her own system. Perhaps if we were a team of full-time staff, dedicated project management software would make more sense.
Creating More Work for Yourself
By trying to force a software onto my team members that wasn't working, I realized I was creating more work for myself! After all, it took time to set up the milestones, tasks, and discussion groups. It took more time to reproduce information that could have instead been forwarded on in the application.
When I realized that it was just as easy (if not easier) to create a spreadsheet and a FreeMind document tracking brainstorming for the upcoming issue and pitches that had been approved, and to place those documents in the DropBox folder for all to view, it no longer made sense to track information on a spreadsheet, mind map, and in the project management software - especially since there was only one other person accessing the project management software.
Letting the Dream Go
Sometimes, we have to give up a commitment to doing things a certain way just because that's how we think they should be officially done. I've had to give up on project management software twice in a situation like this. The other time, the group decided the software was not necessary since we could easily just manage the project using Outlook and emails to one another.
This is where it's vital to know your team. Rather than imposing software on team members, discuss with team members how the project will be managed - especially if you're working with a new team. Know the level of project management the team needs - do you need software that allows for collaboration or do you only need software that tracks action items? By being open to communication in the first place you can spare yourself the heartache of finding that your team is not using the software that you spent hours setting up. Sometimes a project plan is enough. Sometimes, when you're managing an ad-hoc project, perhaps just email and a spreadsheet are sufficient for tracking progress on the project. Fit the tool to the team, and not the other way around.
That being said, how do you know that it's time to let go of the software that was supposed to make everyone's life much easier?
- No one is using the software
- People consistently complain that it's hard to use
- It takes longer to set up the project than it does to complete the project (I would imagine this happens more often than we even realize)
- You find people discussing or asking about things that would have otherwise been found in the software (meaning they're not reading all those helpful notes you posted)
- You've found a better and more efficient means of tracking your project and communicating with team members
- When you're wondering whether your project is up to date enough in the tool you're using
Don't Drag Your Quest for the Perfect Tool into Your Dirty Procrastination Scheme!
Some project managers have the opposite problem. While the software they are using is perfectly adequate for tracking the various projects they are responsible for, they continue to search for the "perfect" software. This is a form of procrastination, and it's a particularly insidious one.
While quality improvement and process improvement are both worthwhile ventures - if they add value to your company - you should be very wary of fixing something that already works fine. Ask yourself, is this the most important thing I can be doing as project manager right now? Aside from wasting your time, the quest for the software that will solve productivity problems is actually counter-productive. If you've got a system that's actually working, why stop the flow of the team and retrain them to use a different system? Not only will you lose valuable time when entering information into the new tool, you could wind up overwhelming yourself, spending more time planning projects than completing projects, and frustrating your team members.
While it's one thing to find solutions when your software is not working, it's quite another to go looking for solutions when there's not a problem.
Doing What Works
By giving up a commitment to using a particular method or a particular program that will "solve" your productivity problems, and instead focusing on what's already working for your team and build on that with tools that complement systems already in place, you will find that your job as project manager gets easier - not harder. Isn't that what effective project management is about?
What sorts of stumbling blocks have you come across when using software? What has worked for your teams and what doesn't work? Have you found yourself resorting to whiteboards and spreadsheets even though there's advanced software available?