Four Things I Learned As A Project Manager (and none of them include Gantt charts!)

Posted by

I joined Tasktop’s Product team last June after spending three years working as a Project Manager. Project Management as a field seems to get less respect than some disciplines in the world of technology, but there is one thing project managers are indisputably good at and that is making things happen.

As a project manager, your job is to ensure that contributors such as developers, business analysts, and others, are able to focus solely on their roles. The developer’s job is to code. So let them code! They shouldn’t have to worry about things like schedules, customer relationships, or resource allocation. By allowing each team member to focus only on their specific role, the team can function as efficiently as possible.

I was able to incorporate my project management skills into my new role at Tasktop by managing the release of our new product, Tasktop Integration Hub, across all departments of business. Though my current role extends outside of the project management world, I’ve been able to apply the lessons I’ve learned to a wide range of professional roles, and even to my personal life.

Here are the top 4 things I’ve learned from being a Project Manager (and none of them include Gantt charts):

Whenever making a request, no matter how small, assign an owner

I often see e-mails sent to an entire department containing a request. If a specific owner is not assigned, it’s easy for the request to get lost. Don’t assume that someone will answer your question just because it’s in an e-mail, especially if that e-mail is sent to more than one person! When a question is sent to multiple people, it’s easy for diffusion of responsibility to occur. Everyone assumes that ‘someone will take care of it,’ and your request will stagnate as a result.

Don’t say: “Could someone please schedule a meeting with the customer?”
Do say:Jane, could you please schedule a meeting with the customer?”

Assign deadlines to tasks

When making a request, add a deadline to it. If you aren’t sure what deadline to give, it’s totally fine to assign one (based on the information you have at the time). If you do have a tangible deadline (set by a customer, for example), make your internal deadline a few days earlier, so that you have time to troubleshoot any unforeseen issues that may arise.

Setting a deadline (even one that may change) helps keep things moving, and gives you a clear time at which you can follow up.

When setting a deadline, avoid using general terms like “asap.” What you think of as ‘soon,’ may be totally different from what someone else considers ‘soon.’

Don’t say: “Please get back to me asap on this request!”
Do say: “Could you send me a response by Wednesday morning?”

Provide context when making requests

When making a request, provide context. This will help the recipient of the request understand both the request itself as well as your requested deadline, which will make them more likely to fulfill it. When context is not included, a request can seem arbitrary or unreasonable, even if it isn’t.

Compare for example: “Please send me a status update on this feature asap – by Friday morning,” to “Could you please send me a status update on this feature by Friday morning? I have a meeting with the customer on Monday morning and want to make sure I have time to ask you any follow-up questions on Friday. That way I can present the status clearly to the customer and answer any questions they have.” Which request would you be more likely to fulfill?

Additionally, sometimes we think we know what we need when we make a request, but it turns out that we actually need something different. By including context, the recipient of the request can help redirect you in case some other solution would serve you better.

For example, a customer may ask for a new feature, such as the ability to create and execute custom scripts within your product. However, if they had provided context on what they truly wanted (perhaps the ability to query for specific artifacts), they could have learned that there is already an easy way for them to run queries right within the product’s UI, without any coding required. By including context, they are better able to find the ideal solution to their true goal.

Send a recap e-mail after a meeting is held, containing actionable tasks along with owners and deadlines

We’ve all experienced holding a meeting, feeling really good about what was discussed, and then three weeks later realizing nothing has come of it. To prevent this from happening, send out a recap e-mail after the meeting containing any actionable tasks that arose from the meeting. As we’ve already discussed, assigning owners and deadlines to the tasks will hold the team more accountable and make it easier to follow up.

Are there any strategies that have helped you become more effective in your role? Please comment below.