Project management is a broad topic that requires different approaches depending if you work on e.g. a construction or a software project, an improvement or a green field one, at an established or a young company.

My aim with this post is to collect the minimal set of knowledge and responsibilities a fresh project manager must know about, the absolute essentials that are applicable regardless of what projects you will work on.

There are tools and practices to extend these essentials, but I think they depend on the project at hand, and should be cherry picked.

I don't plan to talk about how to find out what projects a company should make, or how to manage an organization through projects (OKRs and stuff). This is solely for fresh project managers on how to manager their projects.

What is a project?

There are many definitions of what is a project, I like The Pragmatic Engineer's definition.

My definition of a “project” is this: a non-trivial piece of work which delivers measurable impact.

Almost every word of this definition is important. Projects are important by making measurable improvement on the organization objectives. Small or trivial work doesn't require project management practices.

What makes a work non-trivial, or with other words what makes a project complex?

• Length (time): The longer it takes to deliver the project, the more uncertainty you need to plan with. Holidays, changes in priorities, etc. While you try to break big work down to smaller one, in general, estimations also more difficult you need to estimate bigger chunk of work.
• Number of people involved: Both internal (project team) and external (dependencies). The more people you work with the more difficult to communicate, and to keep one coherent picture of the project in everyone's head.
• Deliverable: Is the deliverable an internal tool of a team or a new consumer facing client from scratch? Is the deliverable in the CEO's spotlight? Less room for mistakes, and more important to manage expectations.

Project management is the process of supervising the work of a team to achieve all project goals within the given constraints.

Project management triangle

There is no project management talk without the Project management triangle. It is both boring because everyone brings it up, and fantastic because a huge portion of your daily project management struggles can be resolved by able to track your problem back to this model.

There is nothing new I can say about it, let's just quote Wikipedia:

The project management triangle (called also the triple constraint, iron triangle and project triangle) is a model of the constraints of project management. While its origins are unclear, it has been used since at least the 1950s. It contends that:

• The quality of work is constrained by the project's budget, deadlines and scope (features).
• The project manager can trade between constraints.
• Changes in one constraint necessitate changes in others to compensate or quality will suffer.

The trading part is very important. Read and think about this as much as you can because my experience is that you will run into problems almost daily that you can bring back to this simple model.

End-to-end ownership

As a project manager, it is important to understand what is expected from your role. While depending on the project and your peers your responsibilities can change, there is something that never changes no matter what:

Project managers are solely, exclusively accountable for the outcome of their projects end-to-end. It is never someone else's fault.

This can freighting for some, but I find it empowering. With this accountability, you get green light to speak up in any discussions that affects the outcome of your project.

I found especially important to keep this in mind on projects where your project team members try to help you, and in the process the lines of accountability become blurred. Don't fall for it, and make this clear without discouraging others to take responsibility for their work.

There are many things I can talk about here, but the aim of this document is to capture the essentials, so I chose only the most important:

To know whether your project will be successful, you all the time need to have a true and accurate picture about the past, present and future of your project.

What tools to use to scope, estimate, plan, track and report your project depends on many things (industry, project complexity, company culture), and I don't want to highlight one of them. I will share tools in later blog posts.

Communication

As a project manager you will spend most of your time related to communication, either doing, or preparing for it. I said you always have to have a true and accurate picture of the state of your project, and it is your responsibility to plant the relevant parts of this picture to the heads of the people in and around your project.

• Internal: Make sure your team understand why they are doing what they do. Define project communication i.e. what Slack channels are used, how many meetings you have to keep everyone in sync but don't overwhelm the team.
• External: Know who to communicate to, what to say and how frequently. There are frameworks that help you to keep track of this. Missed communication can lead to issues in later stage of the project, but overcommunication can erode the curiosity of the receiver.

Again, there are many things that can be mentioned: expectation management, dependencies management (which is most of the time just making request and following up), how to build trust through communication, which communication method (chat, email, meeting, presentation, coffee talk) to use and when, etc. Half of building a high performing project team is communication.

It deserves its own post, but for now I just wanted to emphasize that good communication skills are essential for successful project management.

What is next?

Do you still don't know how to lead a project? Sorry, you can't be saved. 🙁 Joke aside 😄, it is fine, it is impossible to give many concrete tools that work on every project. I think this is a mistake that many people do, and I tried to avoid that.

As I mentioned earlier, my plan is to introduce tools and practices separately one by one. I will share them with meta-information about when to use it, what problems they can introduce and how to avoid them, examples, and such. Then you can select tools for your project, or different phases of your project. 💡

Besides tools, I also plan to share interesting situations I ran into on my projects, what mistakes I made, and what worked. I think it will

You will find these posts under the 🏁 Project tag.