Handbook

Project Management

A Project Manager (PM) job starts right after a new project has been sealed and assigned with a starting date, a deadline and a Team. As a PM it is absolutely fundamental you are an expert about our working methodologies, processes and communication.

πŸ”— To study in-depth about such things, please read all the Proccess pages very thoroughly. Go to Methodology
πŸ”— To know more about how to manage a product, which will come in handy, read Product Management.Go to Product Management

Core role responsibilities

Before digging deeper into the PM process itself, there are a few things you must understand as broader responsibilities for this kind of role.

First and perhaps the most important one is how relevant the PM is. On one side, there's a well-functioning project and a satisfied client and on the other, there's a sustainable company.

As a PM, you are responsible for a multitude of things, and making sure those varied situations are correctly dealt with will deeply impact the overall success of a project.

Be organised

Keep everything neat and things where they are supposed to be. Being organised and keeping track of everything will make your life much easier.

Create tasks and document them straight away. Don't let things get lost nor un-acted upon.

Keep everything on record

After every meeting or every relevant chat, create a new entry at the Client Communication block, available at every project on Notion.

Getting every change request or feedback recorded and saved means it won't be lost either in your memory or on Slack's feed.

Once discussed with the Team, any change request or Roadmap alteration should be immediately updated in its proper place – either by creating a task, changing a sprint, updating documentation, etc...

Manage expectations

This is a tricky one. Managing client's expectation has no recipe. In fact, it is more of a sensorial, gut-feeling capability rather than a technical skill that can be acquired.

It doesn't mean it is difficult. Setting and managing client expectations can be simple and short. Truth be told, it's all about the topics throughout this Guide.

Of course, delivering things on time will have the greatest impact. Keeping open, steady communication channels and things transparent will be important too.

But there's one big-little detail you can leverage in your favour: let the clients know, from the get-go, what we expect from them during the whole endeavour of working with us.

Things like providing feedback on time, providing content and/or assets in advance, being reachable frequently for any further clarification and whatever fits the case, will help you on transferring some of the pressure to the client – as well as manage their expectations.

With this, you're letting the client know they have their own responsibilities on a successful, smoothly running project.

Be the wall

Don't let the clients put pressure on the team. Reassure them if necessary.

Even though we encourage each Team member to assess any ongoing issues directly with the client – and you should do the same – we don't want any extra pressure upon them.

In such event, you must intervene and steer the communication from that moment on. Schedule a call if necessary, but don't let conversations spiral out of control between the Team and the client.

Having pressure is counter-productive. It will affect the Team's performance and their ability to deliver within the deadlines.

Make sure the Team has everything they need, at all times

As a PM you want the project to unroll as smoothly as possible and to be completed in a timely fashion. One key factor is the amount of time the Team will be blocked while waiting for you – either waiting for documentation, for the tasks to be created, for a conversation with the client or whatever it might be.

Be organised, anticipate bumps on the project's path and deliver the required information to the Team, on time.

Anticipate problems

Anticipating problems will help you Make sure the Team has everything they need at all times.

Your ability to predict any unseen problems and act upon them in advanceby adjusting the planning in real-time will make the difference between a PM and a great PM.

Anticipating problems and still managing to deliver project in time is remarkable.

Prepare the Project

Whoever closed the project might have gathered some insight into the projects. That one person is responsible for transferring that information to you.

This information may or may not be enough to set up the Project. In case it is, cool. If it is not, you should make use of the kick-off meeting to clarify any existing blind-spots and questions.

Preparing the Project means setting up the project at the Project Management tools we use. As of the moment this Guide was written, we are using Jira and Notion, depending on each project's characteristic. Our goal is to migrate everything to Notion at some point.

πŸ”— Here's a more detailed explanation about how Notion PM template works.Go to Notion PM Guidelines

Tasks Management

Within this section, you'll find a segment named Project Tasks. This is where you create all the tasks and where the Team can access them. It is also where you create the Sprints and where the Team move their cards around.

It is also within this section where you should create the project's Roadmap by accessing the Roadmap segment. Be sure you keep it up-to-date in case it changes along the way.

Documentation

This is the section where any documents must be kept and saved. With Documents, we mean any files, assets and general documentation provided by the client.

Create a new page for every document and date them.

Resources

Resources mean our work in progress or any editable, non-deliverable document.

It can be a User Research document, a Benchmarking spreadsheet, a Mood board, a Sketch File, a Typographic exploration or even a link to the project's Google Drive folder.

πŸ”— Take a look at the Sprint Report template.Go to Template

Client Communication

The place to keep track of all the communication held between the Team and the Client. From meeting minutes to Slack conversation you reckon should be saved.

As said above, getting every change request or feedback recorded and saved means it won't be lost either in your memory or on Slack's feed.

Reports

At this section, you'll be able to create Sprint Reports. This particular section must be shared with the client.

Sprints reports must be filed at the end of every Sprint.

Deliverables

Deliverables can be found under the Client-side section. Such as the Reports, Deliverables must be shared with the clients, always.

A Deliverable is any piece of work which is ready to be shared, regardless of the stage of the project.

Briefing the team

Before jumping in the kick-off meeting, as a Project Manager, you should gather the Team and brief them about the pre-acquired project information.

One of the first documents to get ready on Notion would be the Briefing. Make it clear enough and be as thorough as you can. Make it using Notion and available to the entire Team.

The following list is a compilation of topics that can be addressed during the briefing:

  • Introduce the client and the project – What it is, why it needs to be done;
  • Scope;
  • Estimated timescale;
  • Introduce the team – who'll be doing what;
  • Target Audience;
  • Assumptions;
  • Explain project vision and goals – OKR's;
  • Dependencies on other projects/decisions;
  • Deliverables and Outcomes;
  • Potential risks;
  • Expectable constraints;

In case you don't have access to the entire extent of this information, you should address it at the kick-off meeting with the client.

Don't be embarrassed to ask anything. Better make things clear with a silly question than discard any potentially relevant information.

Kick-off meeting

This meeting is the starting point of any project as far as what the client is concerned.

Even though most likely, the new client has already heard about a few things about our process, it is always pertinent and reassuring to hear it from whoever's managing the project.

Also, it is the chance we get to introduce the Team to the client and vice-versa.

With that in mind, there's a few things to cater for during such meeting:

  • Introduce yourself, the Team and each one's roles;
  • Double-check the project scope and make sure both you and the client are on the same page on this regard;
  • Enquiry the client about the unanswered topics mentioned in Briefing the Team;
  • Explain our methodology as far as Working Processes are concerned – as part of it, emphasise what the next steps will be;

As an example of what can be said: So, just as a quick summary of what we’ll doing right next: We will kickstart the project next Monday and John Doe will start off by doing some pre-production tasks in order to really dive deep on what Project/Product is. What I mean is we will start with some quick docs on benchmarking and personas. We'll follow with the mood board. We will be sharing these materials with you as we go, so you guys can let us know if we’re going in the right direction early on.

  • Explain our working methodology as far as Project Management goes.

As an example of what can be said: We’ll be working in 1-week sprints for the length of the project. At the end of each Sprint, we'll share a Sprint Report via Notion. On this report, you'll be able to see what has been accomplished during the previous Sprint, as well as a Plan for the upcoming Sprint. In case we see fit, we can also schedule a call to sort out any pending topics.

  • Let the clients know what we expect from them and what are their responsibilities during the entire process;
  • Introduce the clients to Notion and let them know what they can find there;
  • Invite the clients to Notion;
  • Make sure a Slack Team or Share Channel is already in place for daily-basis communication;

Document Requirements

Documenting requirements are a big chunk of the expected work as part of Make sure the Team has everything they need, at all times.

Even though it might transcend your work, it is your job to make sure the Requirements are set in advance.

Literally, it means that not only each task has enough information before the Team actually starts working on it, but also to make sure each feature is well-described and explained, so both you and the Team can understand it clearly.

πŸ”— There's more about Product Requirements at the Product Management page.Go to Product Requirements

Plan the Sprint

Sprints make projects more manageable as they allow teams to ship high-quality work, faster and more frequently, with the added flexibility of allowing timeframe adjustments.

As a recap, the Sprint must be planned and agreed together with the whole Team. You and them must develop a common understanding of the Sprint goals as well as breaking down the project into smaller, more manageable tasks.

You must create well-documented tasks with title, a well-elaborated description and any relevant documents (wireframes, design, requirements).

Make sure the Team knows exactly what they have to do whenever they take over a new task. You must try to avoid having them reaching out to you because a certain issue is dubious or because it lacks enough background information.

πŸ”—You should know from inside out how Sprints work.Go to Methodology

Avoid changing sprints

Changing a Sprint scope mid-term will have a great impact on the Team's performance. Imagine you're allocating all your tiny little-grey cells into one specific task and suddenly somebody tells you to do something else, utterly different.

Not only you will lose your focus and motivation, but also it will take you time to kick-start the new task and re-gain focus.

For this matter, as a PM you must avoid changing Sprint scopes. It is paramount to let the Team focus on pre-determined things.

Changing the Sprint will more often than not create burdens rather than solving problems.

However, there's exceptions to this. There will be mid-project circumstances when you must change the sprint, no matter what – groundbreaking Bugs is one of those.

We have a section about Bug triage in the Product Management page.Go to Product Management

Manage Team Progress

As a PM you must be the one person who knows everything about the project you are managing.

Managing and tracking the Team's progress will help you determine whether or not you'll have to adjust your planning based on whether or not the Sprint will be completed successfully.

With Mid-Sprint catchups you can make sure the Team is working accordingly, on-track and make use of such meetings to address and solve any existing blockers.

Find out more about Mid-Sprint catchups at the MethodologyGo to Methodology

Make sure you take enough notes and create outstanding issues as tasks. Be sure you assign them to the correspondent team member. It is up to you and the Team, together, to decide whether or not those new issues should make the current Sprint or the upcoming one.

You might want to run a daily standup meeting in case you feel the Team needs it. However, the goal mustn't rely on micro-managing the Team, but rather focusing on solving blockers.

Don't micromanage

It’s hard watching someone make mistakes, especially if you already know how to avoid them. Staying silent while they slip up (or even do things in ways you would not) is harder.

That doesn’t mean you have an excuse to micromanage them.

Micromanagement is the ultimate controlling management style. It’s demoralising and counter-intuitive, as the desire for control to make sure everything goes to plan only creates more problems in the long-term.

As a PM, imagine what your reaction would be if your manager kept on asking for constant, often needless progress reports? You would be mad!

Therefore, you must not watch and control the Team's work like a hawk.

When you micromanage you’re telling the Team that you don’t trust them enough to let them work on their own and still produce good results. This leads to annoyance and damaged trust.

It also discourages any kind of independent work, decision-making and exploration in the Team. After all, it demonstrated you don't have confidence in their actions or choices if everything they do gets scrutinised.

Let the Team work independently and make use of the right situations to correct them or arrange things if you think they are not performing as expected.

Always keep the client up-to-date

Everyone likes to feel they're in control. Our clients are no different.

To start off with, they already deposited a big deal of confidence in us by handing over their product to someone miles away, virtually out of reach on a different location.

The best we can do is cope and keep the client in the light, every time. To achieve that, there's a couple of things you can do:

  • Make sure iterations are done as frequently as possible. As you know, our entire process is very iterative, stick to it. Over-iterate rather than under-iterate;
  • Over-communicate rather than under-communicate. If you have any questions or any information you reckon is worth sharing, go for it. If you think it would be a nice touch to say πŸ‘‹ Good morning every day and give the client a head-up for the day's tasks and the previous day's progress, no one will stop you.
  • Never assume clients know what's happening. It is up to you to enlighten them;
  • Never leave a client message un-replied. It regards the entire Team, but you particularly. As the person in charge it is up to you to take the lead and demonstrating how to behave;
  • If you feel like scheduling a call at the end of each sprint and showcase the outcomes, we encourage you to do it.

Keeping the client up-to-date and making sure they feel in control is crucial. Clients don't only pay us for the final result, they pay us to be part of the process.

Ending the Sprints

Before moving one, please make sure you've read How We Work and Product Management. You should know all about it and there's valuable information on how to close a Sprint available at those pages.

πŸ”— To study in-depth about such things, please read Methodology and its other pages very thoroughly.Go to Methodology
πŸ”— To know more about how to manage a product, which might come in handy, read Product Management. Go to Product Management

From a high-level, closing a Sprint is about gathering the Team together, assess the overall Spring progress and figure out what can be improved moving forward.

As a PM and looking back at Always keep the client up-to-date, it is your job to compile a document with a few Sprint Details. Even though communication has been kept tight – or at least we expect so – the Sprint Report formally marks the end of a Sprint.

There's more to it

There's no such thing as one-size-fits-all at managing projects. There's small projects, there's complex products, there's all sort of different requirements and scopes.

Once more, please read both How We Work and Product Management. The amount of information is precious and it complements this Project Management Guide. Both of those pages dig deeper intro our high-level working methodology as well as our Product Management process. Some of those chapters within, even though they might not be present in this Guide, will be essential for a successfully managed product.

πŸ”— To study in-depth about such things, please read Methodology and its other pages very thoroughly.Go to Methodology
πŸ”— To know more about how to manage a product, which might come in handy, read Product Management.Go to Product Management

Do you feel like you got what it takes to start managing projects? Simply let us know.

This is an ever growing document

This document isn't complete nor will it ever be.

If you feel something is missing, which it is, feel free to make suggestions, we'll work on it together.

πŸ”— You can either let us know personally or make an entry at the Suggestion Box.Go to Suggestions Box