This post is the second in a series. Read Part I: The Chokehold of Calendars by Mike Monteiro.
My job is to protect my team. That’s every project manager’s #1 job. Make your team’s work possible. Provide the structure to allow a project to run smoothly. So why don’t our tools reflect that cooperative enterprise?
I’m not the only one who chafes at standard project management processes and applications. Many companies are structured in such a way that the only interaction the team has with their project manager is seeing meetings pop up on their calendar. That dynamic can only result in the team seeing their project manager as a calendar monkey and resenting them for interrupting time they need to work. That’s not how any project manager wants to be perceived, and certainly not the purpose we’re dedicated to.
Mike’s post about calendars just opens the door to a new possibility (If you haven’t read it, read it now and come back to this as Part II). We were sketching out the goal-oriented calendar tool he included in his post and I couldn’t help but imagine a few additional steps. What if the tool you used to scope a project was the same tool that allowed you to schedule work and meeting time, analyze its efficiency, and report both qualitatively and quantitatively on project success? Using the same tool for scoping and managing a project would allow you to compare how the project was originally scoped to how it’s running now and give at least some of the whys—someone needed more time to do the work, someone they needed input from was on vacation, another project had a more pressing deadline, etc.
Could we also rid the world of the annoyance of time trackers? Because despite how much I want and need to know how profitable a project is, I hate having to enter my time into a standalone tracker application. Something that automates the process as much as possible by grabbing work and meeting time from the calendar would at least make the job of entering time less taxing and provide a more accurate starting point than zeroes across the board.
As project manager I think not just about what’s best for the Mule team, but what’s best for our clients. I’ve been working on a way to balance the benefits of Gantt charts (ability to input dependencies and adjust an entire schedule with the push of a button) with the best way to communicate project schedules to clients. Most people can’t read a Gantt chart, and no client should have to. Gantt charts are more useful for planning next steps than providing an at-a-glance project status anyway. There’s also an inherent inefficiency to entering information into multiple tools multiple times over the course of a project because each one is focused on a single task. We’re thinking through how to create one tool to handle these multiple functions, which would free up a project manager to focus on the real reason we come to work every day—facilitating the work that needs to get done.
Mule creates delightful interfaces, strong identities, and clear voices for useful systems and nice people.
Also, We are funnier than all other designers.