Project Manager is one of those job titles that seems to mean completely different things depending on where you work.
The common theme on all project manager job descriptions are vague sounding goals around ensuring quality and staying within budget. But the actual day-to-day activities and skills required for a Project Manager position can vary widely.
I’ve known project managers who were entry level employees in their company essentially tasked with setting meetings and taking notes. I’ve known project managers whose role is the highest level in their company without being a senior manager. I’ve known PMs that manage a team of ‘resources’, and I’ve known PMs who outsource everything to a vendor (who has their own project manager).
Of course, this is all in the context of building websites. Project Management in manufacturing or construction may be different.
However, in the web building world I’ve found the following skills to be essential to good project management:
Own the relationship
For any customer engagement, you’re going to be the main point of contact. You’re the person the client deals with on a day-to-day basis, you’re the one who understands their project better than anybody, and you’re the one who gets to know them as people.
There may be a sales person who brought that client in, and there may be an account manager who meets with them a few times a year and tries to sell them on new services. But regardless of what the org chart and job descriptions say – you are the one who really builds, maintains and owns that relationship.
Everything else you do serves or flows from this essential duty.
Good client relationships are built by establishing trust, communicating clearly, consulting expertly, and building rapport.
Building good relationships makes it easier to:
- Have input into product decisions
- Negotiate scope changes and push back on scope creep
- Get acceptance if you need to adjust the timeline or otherwise give ‘bad news’
- Win repeat business
Understand your product
There’s a school of thought that you don’t need to understand what you’re managing in order to manage it. You just need to understand proper management techniques.
I wholeheartedly reject that idea when it comes to project management in the web world.
To be clear, you don’t need to be a programmer or designer. You do need to know enough to:
- Speak about your product intelligently
- Offer good advice to your clients
- Negotiate scope change
- Help clients understand what will require custom development vs leveraging existing functionality for a much lower cost
Be the main client consultant
At some larger agencies there may be separate people taking on the role of “Business Analyst”, “Technical Analyst” and “Information Architect”. You may even have a UX team that’s separate from the design team.
But at most agencies, one or more of these roles are going to fall to you.
As a PM, you may find yourself doing any of the following as part of your day-to-day job:
- Help the client shape their marketing messages
- Show why a certain approach will make their site more usable
- Create user flow and site map documents
- Assist with digging into their analytics to inform strategic decisions
- Prioritize internal feature requests and determine which will give the biggest win for the least effort
Even if your company has people who can handle all of these things for the client, they will not be on every call and in every meeting with you. You can’t answer every question with “let me set up a call with the appropriate resource” and hope to ever get a project over the finish line.
Ultimately, in the real world of web project management you are more often than not the client’s de facto strategist. If you weren’t, they wouldn’t pay you the big bucks.
Communicating clearly sounds simple enough, and is probably on every job description for every job in every industry. However, for the web project manager there are specific challenges:
- You often need to break down complex technical information to an audience made up of non-technical people.
- You need to translate design feedback from the client into something the designer can actually work with.
- You need to write requirements so clearly that there is a zero percent chance of the developers building something that is not exactly what the client asked for.
The final one is the most important. The requirements are the one thing you can point to when the client wants a million changes before launch. If they are well written, they will spell out exactly what is being built.
However, vague requirements, or overly technical requirements that the client did not understand will almost always lead to disagreements at the end. These disagreements will end up meaning that you fail on at least one of the three main goals of project management: delivering on time, on budget, and to expectations. Often these disagreements will mean failing on all three counts.
This is why communicating clearly is vital. Ensuring the requirements spell out exactly what you will build, and that the client truly understands what will be built going in to the process. If the client doesn’t understand the requirements or just felt pressured to sign off to meet a deadline, there’s a very good chance that the project will blow up at the end.
Think like a lawyer
Related to communicating clearly above, you need to think like a lawyer when documenting your project.
By this I don’t mean the questionable ethics of refusing to write anything down so there won’t be a paper trail. I’ve worked in environments like that and it always felt uncomfortable to someone who personally prizes honesty.
I mean ensure every implied promise is captured and followed up on. Too often I’ve seen a client ask if something is possible and a resource to honestly answer “yes, this is possible” not understanding that the client now assumes that will be part of the project. As a PM you need to follow up with the client and make sure they know whether or not that request is in scope and do any additional discovery to properly document it.
Just as importantly, you need to be exhaustive in looking through requirements and figuring out where there’s too much gray area that can lead to misunderstandings. Does a Statement of Work say how many mockups and how many rounds of revision the client will get? Does it say where you will be leveraging existing technology so you have the ability to tell the client that custom work will be out of scope? Has any statement about SEO implied an improvement in Google rankings? Have you walked the client through seemingly obvious plugins like comments or donations so you’re on the same page about what functionality is and is not included?
You need to be prepared to do anything else required to ensure that your project moves forward. It’s too easy to hit a roadblock and say the project can not proceed.
I once had a job that should have been a slam dunk. I had a project that was already defined and the development work was being done by an outside vendor. My job was just to get a few things signed off, sit through some status meetings and move on to the next thing.
One of the signoffs was from the company’s legal compliance team, and it turned out that a data point we were going to use was not allowable under federal regulations.
As the PM I could have easily said “Okay, that’s that.” Instead, I pushed for six months down every avenue I could to solve this problem. I tried to find ways we could add disclosure that would allow us to use the data in a legal and ethical way. I tried to find a source of data that would pass legal muster. I tried pushing things up the chain to senior management to get involved. I tried to see if we could calculate data in house. I worked with the vendor and design team to try to come up with a version of the tool that did not require this data. Finally after months of negotiations I got a federal agency to agree to allow us to create a new data point that would play the same role as the verboten one, but be different enough to not cause confusion and not run afoul of the regulations.
I am not a lawyer, I am not a statistician, and I was a fairly low-level project manager in the marketing department of one of the largest multinational finance companies in the world. But I got it done just because I refuse to let a project fail and I refuse to accept the idea that a project manager is little more than a recording secretary that helps other people organize their work.
Finally we get to the traditional “PM Stuff”. The things that most people who aren’t full-time project managers in the industry think our jobs entail.
- Setting up meetings
- Taking notes and documenting everything
- Keeping an eye on the budget and timeline and reporting when they may go over (and asking your developers to work faster)
- Scheduling resources
As you can see, the duties that are usually written about for PMs – reporting methods, burndown charts and all of that – are but a small fraction of what you’ll actually do on a project.
In the end a PM is not a highly specialized job dependent on expertise in chart-making. It’s a generalist job for a swiss-army-knife type of person. You may not be the best tool for any specific job – you’re not a designer, developer, lawyer or salesperson. But you have to be good enough at all of those things to do in a pinch.