For as long as I can remember, I have described myself as a project manager. I found it was the simplest way to explain what I did. In reality, I have been a Sybase database administrator (DBA), systems analyst, software team lead, business process manager, implementation manager and most recently, a customer success manager. At the end of the day, I get s**t done. I found that the term “project manager” was the simplest way for people to grasp what I do.

I have started to wonder whether I’m using the right term. As I compare my methodology to how others are managing projects, I wonder if “project manager” may not be inclusive enough. Additionally, the response I get from resources involved in my projects often is one of pleasant surprise. Their prior experiences or preconceived notions of what a “project manager” is has left them jaded and unimpressed.

A few years back I was brought into an organization by a mentor and former boss to help alleviate his workload so he could focus on raising money for the organization. Prior to my entrance into the organization, everyone did everything for their customers. There were no project managers. This resulted in project delays and the curse of constantly switching gears to focus on the biggest fire. At first there was subtle push back and doubt as to what value I was bringing to the table. Out of necessity and as a result of the influence of my mentor, the project resources started engaging me on the basics – timelines, status, meetings, etc. As I got more involved and took on more responsibility (i.e. owning the documentation, managing the communication, pursuing the missing information) those same resources started to come around to me as a “project manager.” I believe they view me as the exception rather than the rule.

More recently, I overheard a conversation regarding a project where technical resources were responsible for writing status reports and updating the project team. This very much confused me as I have always felt that this function was a core responsibility of the project manager. After probing a bit, I learned that the project manager did not understand the technical solution and therefore was unable to provide descriptive enough project statuses. I understand that the project manager is in an oversight role and will rarely understand every detail of how a technical resource plans to implement, but I don’t understand how they are going to oversee every piece of the project if they don’t understand individual components.

These are just 2 anecdotes that make me ponder whether I misunderstand what a project manager is or incorrectly associate this term to what I do. A good project manager requires equal parts operational understanding, technical skill and project coordination.

Operational Understanding: To manage a project effectively, it is imperative to understand how that project fits into the big picture.

• How does it impact the business unit?
• What motivates the project owner?
• How will it impact the project stakeholders?

If I don’t understand that the goal of the project is to significantly reduce costs or improve efficiencies in order to prevent layoffs, I may not see or understand the anxiety of the stakeholders or the project owner. I may also not know the right way to motivate the team or get to the root cause of disagreements.

Technical Skill: Furthermore, it is crucial to have an active part in the technical conversation.

• How do you step in to test or troubleshoot?
• How do you mitigate disagreements between technical resources?
• How do you translate between technical resources and the business owners?

Technical skill allows me to get my hands dirty when required. It is the reason that I can play “cardboard batman” to work through complicated project issues. It also allows me to step in and mitigate disagreements between technical resources, and pursuasively communicate decision “whys.”

Project Coordination: Lastly, it is critical to know what goes into running a project.

• How do you estimate a project task?
• How do you allocate resources and make sure milestones are met?

This is the nitty gritty of running the project. It’s the logistics – status meetings and reports, milestones and gantt charts, task estimation, etc. These are the basics you need to know. Unfortunately it is not enough to make sure project successful. Only by combining the basics of project coordination with technical skill and operational understanding can you truly get s**t done.