The 8 Project Management Standards I Hold Myself To
After another year of freelancing, building client relationships, dealing with both great and difficult projects, working with incredibly strong partners, moving halfway across the country, and a whole host of project management/tech events, I’ve really refined my approach to work that I take on.
I’ve found that all of the work I do and projects I take on have patterns that are shared across contracts. Certain things are important to me in how I work, how others interact with me, and it’s become a core foundation in how I work—the principles that shape what I do.
I look at these core principles as my personal set of project management standards.
This core approach is something that I think we should all apply to our work globally: no matter how many people or projects we’re managing, clients we’re in contact with, or what we’re launching, there are certain patterns that hold true across our industry.
I believe most of us have some idea of what these guiding principles look like to ourselves already. It’s important for me to write these down and refine them so that I have a clear understanding of what’s important to me and allows me to do my best work—just like project scopes or goals.
1. My job is to do the dirty work.
I might act as the coach, the referee, the parents cheering their kids on in the stands, the ball boy, or the janitor in the locker room cleaning up dirty towels. Most of the time, I should be doing the work that allows my team to do their best together: planning, reviewing/testing work, facilitating communication, asking questions, addressing the tough issues, acting as a firewall, and constantly reviewing our current state against our goals. I’m all out of sports analogies, but it comes down to this: my job is not always the glamorous stuff, and that’s fine, because It’s the core of what keeps the team a team.
2. I am defined by the strength and function of my team.
My job is to bring people together to achieve a common goal. While various factors contribute to a project getting done successfully, the core team I work with reacts and responds to the project management framework I create.
My team should feel comfortable communicating with myself and other team members regarding new approaches, educating each other, and helping to define success (or pick ourselves up out of failure). If my team is dysfunctional, unhappy, or drifts without a purpose then I am no better.
Much like a project has its own definitions of success, my success as a project manager is defined by the function and strength of my team.
3. I regularly question my methodology.
I should always assume someone, somewhere has done what I’m doing in a different way. That way might be better or more efficient, or at the very least provide a different perspective into what I’m doing.
I actively seek out other opinions and references whenever I can as to how others run their projects, deal with project or client issues, or set up their systems.
This shouldn’t be an excuse not to act and move forward on things. Instead, it should serve as a good gut-check and re-centering for myself and the way I work every few months.
4. Trust my gut.
With all of the project management I’ve done over the years (and with the last few years of my experience accelerated by freelance project managing with multiple companies at fast rates), I’ve seen my fair share of red flags.
I’ve learned the patterns of what makes a poor fit in projects or client relationships. I’ve learned project management pitfalls the hard way, and the same can be said on the project level.
When it comes to project red flags or client/team relationship trouble I should still take the time to justify it in a quantifiable way, but I trust myself enough to know that my initial reaction is usually spot on.
5. Communication is literally everything.
I say this in every conversation I have about project management—especially with remote project management. Communication is the key and basis to everything we do.
Clear and frequent communication is incredibly important for me to set expectations with clients and teammates, but also to open up casual channels of communication on top of project-related communication.
When someone is used to communicating with me beyond the project-level, it means they’re more comfortable and open to communicating other needs or issues as those come up. It strengthens my relationships with the people I work with and thus makes my projects stronger.
6. Everyone on the team has something to say.
Everyone communicates differently. I try to always keep this in mind and keep as many channels of communication open for team members as possible.
Private chat, public chat channels, email, and task commenting are not all methods of remote communication—they also help those that don’t have extroverted tendencies (or confidence in their needs or questions!) communicate effectively.
Real-time or in-person communication doesn’t always work for everyone—and that’s ok. There is no communication medium that is superior to another when it comes to my team.
7. Always assume ignorance.
I don’t mean this in a condescending way. But I don’t and shouldn’t ever assume that everyone is on the same page, or that everyone understands what we’re doing.
Communicate to set expectations at the beginning of every meeting, email, or project conversation. Repeat takeaways or actionables at the end of these things.
Run budget reports and check on timelines and keep everyone informed.
When issues come up, I should notify everyone necessary—but also communicate the expected ramifications of these issues (the timeline gets pushed out, or the budget changes).
If I ask for a weird or specific feature, or work to be done a certain way, I communicate what the end goal is (maybe my team knows a better way to reach this goal). And if I am explaining what we’re doing to my client, I educate, instead of using jargon or skirting the technical explanation.
8. i don’t have all the answers.
My team is smarter than me. I’m not a developer, and I’m not a practicing designer. If I’m asked a question I can’t answer I defer or check with my team.
If my team doesn’t know, I find experts. If I don’t have an answer, I let others be heard and don’t allow myself to feel obligated to answer immediately.
Further Reading:
An Incomplete Manifesto for Growth by Bruce Mau
Unintuitive Things I’ve Learned About Management by Julie Zhou
Principles for Digital Project Management by Brett Harned
