How to be unopinionated about process, but still keep things on track.
Lately I’ve settled into a role where I act as project manager on a regular basis. This role kind of evolved organically, and I didn’t come into it with a formal project management background, but rather a design background. To me, project management just feels like another creative problem to solve.
At &yet we tend to work on projects that are outside of the box, both creatively and technically. Whether this be internal projects or consulting work, each project has different goals, unique contributors, scope, constraints - you name it. Because of this, there’s really no one-size-fits-all project management process that works for every project. I tend to reinvent the wheel (er, ‘process’) with every project. Sure, there are some basic approaches that I’ve noticed work really well, but I still see every project as an opportunity to evolve and iterate on project management as a practice.
I generally start by asking myself the same fundamental questions:
Start with the basics
-
Goals: It’s helpful to take stock of the over-arching project goals. This may seem obvious but it can be easy to lose sight of bigger picture goals when solving more granular problems, or even to forget to establish clear metrics for success in the first place.
- What are the external goals of the project?
- What are the internal goals of the project?
-
Requirements: If there’s anything that can make a project feel like a win-win for yourself and the client, it's setting clear requirements. This ensures that client expectations are met and that scope creep doesn’t threaten planned profit.
- What is the project scope?
- Is everyone involved aware of the scope?
- Does anyone need clarity or have any concerns?
-
Deadline: It’s helpful to know how a deadline is determined to get a sense of how flexible it is (because, hey, unexpected delays happen), as well as how comfortable it feels for the team working on it. A super strict, immovable deadline can require extra support and communication as a project manager.
- What is the deadline?
- How has the deadline been determined?
- Does it feel loose, comfortable, or tight?
-
Personnel: It’s helpful to establish everyone’s role on the project, make sure they’re clear what‘s expected of them, and determine if any planned outages could impact project progress.
- How many and which team members are involved?
- What are their roles in within this project?
- Are there any notable outages to consider?
-
Budget: A project’s budget is determined as a result of setting scope, value, negotiation, and often a certain amount of guesswork (ehem…https://twitter.com/lynnandtonic/status/1096126469745434624). It’s helpful to have a system for monitoring if a project is trending toward exceeding the budget, and a plan for getting it back on track.
- What is the budget?
- Are there target time contribution ranges for each type of contributor? (Design, Project Management, Dev, etc.)
- If so, what system will be used to monitor the hours throughout the project?
-
Internal and External Communication: At the end of the day, someone has to be opinionated about where and how to communicate. Figuring out how to capture communication where it naturally occurs can greatly improve the flow of ideas and quality of collaboration. When setting communication expectations, it’s important to think about what your team needs to be successful, but also about what you need from your team in order to keep the project running smoothly. This is also a good time to think about not only how often meetings take place, but also how you can be an effective meeting planner. Perhaps creating an agenda to share with the client prior to the meeting would make the most of a short meeting time. Think about what you need from your teammates in order to do this, and make sure they know to prioritize providing this support.
- How do the stakeholders and teammates prefer to communicate? (Slack, email, phone, etc.)
- How often do the stakeholders and teammates prefer to communicate?
- Are there timezone challenges to consider?
- What communication boundaries need to be set? For instance, is it ok for clients to DM individual team members with questions or feedback?
- How should feedback or bugs be reported?
If I don’t know the answer to a question above, I seek it out. If I’m not sure how a stakeholder prefers to communicate, I ask; “What tools does your team use? If we have a quick question or design direction to hash out, how do you feel about hopping on a quick call? How far in advance do you like to have meetings scheduled?”
Go beyond the basics…or don’t
If the project that you’re planning for is likely to last for a more than a couple of weeks, it may be helpful to consider the long-term impact on the team involved. Consider more deeply how the cadence and management approach to the project may affect your team.
I recently held a project retrospective where many people shared that they had all felt a certain level of burnout at some point during the project. After several months of heads down work, it would have been helpful to plan for somewhat of a break, along with an intentional revisiting of the core goals of the project, to enable us to come back to the work with renewed energy and fresh perspective.
Going beyond the basics requires you to deeply consider the unique needs of your team as contributors, and yourself as a leader. A few folks on my team (Heather, Eric, Lynn, Fritzy, Luke, and Amy) recently formed a ‘Project Management Working Group’ and did some excellent work in outlining what this deeper project prep work looks like:
Get to know your team
Being aware of personality types and areas of general strength can help the PM communicate effectively and work through conflicts when they inevitably arise. Getting to know your teammates is one of the most important and effective skills of a project manager. It can be helpful to run through these as a mental checklist at the beginning of every new project, even if you’ve worked with the same people for years.
- Who is self-directed and who needs more explicit direction?
- Who is naturally focused on big-picture or long-term and who is focused on the present details?
- What is the team’s capabilities, strengths, and interests?
-
Trust can be strongly affected by the presence and quality of project management.
- In general people who trust more slowly may need more explicit direction. This is because they see their work in terms of agreements. If there is no verbal or written agreement about what should be done, or if these agreements are violated, they may view a minor oversight as a personal betrayal or violation of trust.
- On the other hand, people who trust more easily may find working on highly-structured project to be constraining or annoying. They extend trust naturally, and may interpret any insistence on procedure to be questioning their competence or reliability.
- Visibly appreciate and celebrate your team, especially people who do background work.
Let your team get to know you
- What is your leadership style?
- How are you under stress?
- What are your expectations and availability?
- Let them know you are there to make your teams life easier!
Whether or not you go beyond the basics when preparing to manage a project is up to you. It depends on some obvious factors (the size or duration of the project), but also some less obvious factors as well (whether or not this is a team that you’ve worked closely with before, whether or not this project feels like old hat or uncharted territory).
Create a process
From here, create a process that makes sense for that project. I’m calling it a ‘process’ for the sake of continuity, but really it’s a framework for communication. The real role of a project manager is to make sure everyone involved has the information they need when they need it, where they need it.
-
Decide what information will live where
Example:- Slack: Ongoing discussion and quick status updates
- Dropbox/Dropbox comments: Sharing early design iteration
- Dropbox paper: Work plan, checklists, meeting notes, feature specs
- Github: Milestones, design and dev collaboration, granular UX discussion
- Define a ‘work plan’ that makes sense for this project. A work plan is simply a series of milestones at intervals that make sense for the project. It’s a document visible internally and externally (client-facing), and is very much a living document that changes as circumstances change. Most often a work plan lines out goals or tasks for each week of the project. In some cases, if a project has a very tight deadline, it can be as granular as daily. If a task becomes complicated or priorities change, the work plan changes accordingly.
-
Set internal and external communication expectations
Example:- Weekly sync call - 30 minutes, all team members
- Weekly PPP email - PPP stands for Progress, Plans, and Problems/Questions. It’s a formal account of what’s been accomplished that week, as well as next steps for the following week. It's also a chance to identify any blockers, get clarity where it’s needed, etc. It’s closely aligned with the tasks and milestones outlined in the work plan. The weekly PPP email is a concept that our team has grown very familiar with and have come to appreciate the benefit of. It’s a bit of work to put together, but is very worth it. This email gets sent to both the project participants as well as the client.
- Daily status updates in Slack in the week leading up to a milestone or launch.
- Retrospective meetings to cap off each major phase or milestone.
Vet your process
One of the things I love about how we operate at &yet is the avoidance of process for the sake of process. What I’ve observed is that before the team is required to adopt a process, it gets vetted to ensure that it has a net positive effect on everyone involved. I think this vetting step is largely unspoken, unofficial and largely unconscious for those who are accustomed to our work culture, but if I were to have to break it down, I’d assume it’s just a matter of asking yourself a few important questions:
- Does it require everyone to purchase, create accounts for, buy into, or learn a new tool?
- What are the work styles of everyone involved? Does this process require anyone to fundamentally change how they work or communicate?
- Are there any existing tools or familiar processes that can be emulated or altered to achieve what’s intended?
- Who benefits from this process, and how?
- Who is burdened by this process, and how?
There are no right or wrong answers to those questions. I suppose the point of the exercise is to think about the creation of a process with a people-first, empathetic mindset. Do the benefits of the process outweigh the burdens? It also requires that you consider and respect the unique work styles of everyone involved, and to trust that everyone on a project has the same goal in mind, regardless of how they arrive there.
After all, the less prescriptive you are about process, the more trust it requires.
Ask the people involved what they think of the process. Would they prefer a different way of communicating, or different intervals, or different tools? Tell others what you need from them and ask what they need from you in order to move the project forward. Iterate on you process as you go. Notice pain points, blind spots, or gaps in communication. Scaffold your process where needed, but also back off on meetings for a week or two if it would be more productive for everyone to be heads down. Conversely, notice when increased communication could be useful. Ask your team members how they’re feeling as the project progresses.
Up until recently, I had gone into projects with the assumption that people wanted to avoid needless meetings whenever possible. I had worked very hard throughout the project to avoid frequent meetings in an effort to respect everyone’s focus and time. I tried very hard to make the meeting schedule sparse, efficient, and generally short and sweet. I learned during the project retrospective that there were times when more frequent meetings may have been helpful for the team. In an effort to avoid imposing a bothersome, interruptive process I had missed the opportunity to provide needed communication support. I now know to ask and to take everyone’s communication temperature throughout the project.
Live and learn
Iterating on your process as you go is one thing, but sometimes it’s hard to notice where you can improve until the project is done and the team has a chance to take a breath and really think objectively about the project as a whole. Capping each project off with a retrospective is an important exercise (but so easy to forget to do!). This is also something can be helpful to do at regular intervals throughout the project, or aligned with sprints or milestones.
Conducting a productive and meaningful retrospective is kind of a topic in and of itself. Even with the most well-meaning, empathetic team, it can be really hard to avoid feelings of blame when discussing something that went wrong in any way.
A while back I went through a rabbit hole of research on the concept of a blame-free retrospective. I came across some really thorough resources, but ultimately felt like a lot of the proposed methods were extremely dense, formal, and downright intimidating. I was looking for a lightweight, casual guide to having a productive, freeform conversation with my teammates. I ultimately wrote up my own guidelines for a blame-free retrospective. These guidelines have worked well so far, but I’m always looking to improve and iterate on the retrospective process as well. The concept of a blame-free retrospective is something that I’m very passionate about, and would love to hear what has worked for other teams.
Project retrospectives are the ultimate way to learn and grow as a team, but also as a way to develop project management methods that are as frictionless, flexible, and ultimately as effective as possible.
Why be unopinionated?
I was inclined to write this post because it seems that project management is often seen as a rigid practice, or even a necessary evil. In reality, it can be an interesting, creative, rewarding practice that anyone can do. In fact, leading a project with a non project management background can be a great advantage.
You don’t have to have a background in agile development to manage a project efficiently. You only need a basic framework, a people-first mindset, and faith in your own ingenuity to develop a system that works well for you and your team and your clients.