Notion PM Guidelines
We manage some of our Projects at Notion. It isn't necessarily a Project Management tool but when compared to such platforms, it kicks their bums with speed, simplicity, and a beautiful design. On top of that, it deals with data quite impressively and things are made rather swift and simple.
Notion surges as one more step on our continuous drive to improve our organizational skills in the lookout not only to deliver better projects but also to deliver a better experience to our clients.
Even though we use other channels for communication and iterations, our goal is to centralize everything in Notion as the one go-to knowledge base for every project, from Deliverables to Feedback.
Starting a new Project
Starting a new project is quite worry-free because we've got a Project Management (PM) Template prepared for you.
Make sure you select PM Template after being prompted with the new project modal.
All you have to do is change the project name, icon, cover and metadata to start-off with. It is that easy!
Once the project is created, you'll find it predefined with 7 separate areas. Each of them fits different purposes throughout the Project lifespan:
- Bug Report
- Client Side;
As you can see, some of the elements are greyed-out. It means those pages are available in the Client SideWe'll get to the Client Side further down this guide. therefore visible to the client.
The Briefing Section has to do with all the information that we should possess in order to embrace and develop a project with the required amount of information.
It is split into three sub-sections with very distinctive functions:
- 📃Not a One-pager
- 📋 Documentation
- 🗒 Requirements
📃 Not a One-pager
Not a One-pager is a one-page document with more than one page 🤯. Could also be named Two-pager 🤔.
It is a simple, not-that-short document that gives us a high-level overview of the client's product, service, or business and allows us to collect a significant amount of information that will turn out useful at later stages of the Project.
In the ideal scenario, the One-pager would be filled-in and shared with you, the Project Manager, prior to the kick-off meeting.
Documentation is just a collection of all the documents we received in the project context. This page should be the one go-to place to find all the client's project related information.
Even though there's not a template available, make sure you keep things organized, with a new entry for each document, named explicitly.
Depending on the project size, it may or may not be worth the effort to create this sort of documents.
A requirement is a higher-hierarchy document, with a broader, deeper explanation of a certain feature. On larger projects, the requirements should be filled in by the Product Owner or the Product Manager and then broken down into smaller, more manageable pieces, often called Tasks, by you, the Project Manager.
Roadmap regards the project's timeframe, duration, and milestones. There's only a couple of items inside:
- ⏳Time Scale;
⏳ Time Scale
As you know, we work on an hourly basis. At some point in the past, we've sent the client a proposal which basically consisted of a time-estimate that got multiplied by the hourly rate.
This page is meant to be a replica of such an estimate. It gives the Project Manager enough information to set the foundation for planning, defining the Roadmap and Milestones.
The Roadmap is just a regular calendar page. Intentionally, we left it template-free since we believe it should be up to the Project Manager to call the shots at this point. The calendar can play a major role in managing the Team's and the Client's expectation, therefore, as a Project Manager, feel free to freestyle.
However, there's a couple of things we recommend:
- Project Milestones – Important dates and Deadlines;
- Team's Holidays.
The calendar is available on the Client-Side for one main reason: to avoid unpleasant surprises and disappointments. The client must to be aware, at all times, of the Team's time-offs and National Holidays.
Besides such information, there's more stuff you can opt-in if you see fit. Looking back a the Time Scale, you can pick-up the time-estimates and translate it into the calendar.
One other possibility would be to include the Sprint Planning instead of the time-estimates as the latter one might end-up incentivizing micro-managing.
The Sprint section agglomerates all the Sprint-related paraphernalia:
- 🗄Project Tasks;
- 📈Mid-Sprint Catchups;
- 📝 Sprint Reports.
🗄 Project Tasks
The Project Tasks page is a backlog of all tasks within the Project, the one place to create them.
To create new tasks you can either just fill in the table in case it doesn't need further detailed specifications or, if it does, you can open each row as a page and type-in further details.
In the latter case, there's a Tasks Template available with predefined fields to fill-in. You don't have to follow them, you can either change it, add more or simply ignore it.
Are you looking for a Sprint-like Board? That's no problem at all, we've got you covered! Simply change the view on the top left-hand corner, from Table to Sprint X. With this, a classic Scrum PM Board, with the usual columns: Backlog (No Status), Doing, Ready for Review and Complete, will replace the default Table.
You can change from Sprint to Sprint by clicking Sprint X on the top left-hand corner. When a new Sprint is to be planned, just click Sprint X, then duplicate a previous Sprint and rename it. A new Board will become available.
Once done, edit the newly created Sprint filter, on the top-right hand corner, and change it to the adequate Sprint tag.
In order to assign tasks to the Sprint Planning Board just go back to the Project Tasks page and edit the tasks with the desired Sprint tag. They will become available at the corresponding Sprint Planning Board.
📈 Mid-Sprint Catchups
Some PM's like to do Mid-Sprint Catchups to make sure the team is performing well, on-track and make use of such meetings to address and solve any existing blockers.
In order to avoid loss of valuable information, the outcomes of such meetings must be noted down at the Mid-Sprint Catchups page.
Inside this page, you'll find the ability to create a new list entry. Each entry should be a new Mid-Sprint catchup note. Even though there's not a template available, make sure everything gets noted-down and that every takeaway gets created as a task in the Project Task page.
📝 Sprint Reports
Sprint Reports are meant to be shared with the client. It is a Project Status update and another tool to measure the Team progress and to manage both the client's and Team's expectations.
Inside, you'll be able to create new Sprint Report by clicking the New button. It will pop a page where you can select the Sprint Report Template for a pre-defined Sprint Report Template. Even though those are the more often required fields, feel free to adjust it based on the project's specifications.
No matter what, the client won't be able to see the tasks from the Project Tasks page, therefore you won't be able to reuse or invoke the tasks from the Sprint Planning. In order to overcome it but still letting the client know about the Sprint completeness, there's a bit of manual work involved.
On the first instance, you'll have to manually type each task on the Task overview table.
However, we still want to demonstrate how the Sprint Planning Board looks like at the time the Sprint Report was created. To achieve it, you can screenshot the board and place it below the Task overview table.
Once the Sprint Report is made, notify the client via Slack or whatever channel you see fit.
Communication is divided into two segments with very distinct purposes:
- 💬 Client Communication;
- ✨ Quality Assurance.
💬 Client Communication
The Client Communication page's purpose is to keep track of all 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.
In this page, you'll find the possibility to create a new list entry. Each entry should be a different moment of interaction with the client.
By clicking New, you'll be presented with a modal where you can either choose to start with a Communication Template or from a blank page.
✨ Quality Assurance
The Quality Assurance (QA) page is an internal segment of the PM Template which isn't meant to be shared with clients.
Once inside the page, you can add new entries to the QA list by clicking the New button. Done that, you'll be prompt with a modal where you can start from a pre-set QA Template.
Make sure each entry is as thorough filled-in as possible in order to make the Team's job as swift as possible.
The Resources section is pre-defined with 2 sub-pages:
- 🏗 Work in Progress
- 🎁 Deliverables.
🏗 Work in Progress
Work in progress relates to every bit of work we produce during the project which can and makes sense to be done in Notion. Inside it you'll 3 pre-defined sub-pages:
- 💻 Interface Moodboard;
- 🎨 Illustration Moodboard;
- 👨💼 Personas;
Even though these are just the most common ones it is expectable more pages end up being created.
Keep in mind, there's other bits of our working methodology which can, but might not make sense, to include here. As an example, Look & Feel and Wireframes are usually shared through InVision links but you can have them here as well in case you see fit.
Both the Interface and the Illustration Moodboards are straight-forward galleries where the Team can upload images. Once filled-in, voting should take place.
On the Personas page, once you jump in, you can create a new persona by clicking New. It will prompt a modal where you may select Persona Template in case you want to make your life easier and start with a pre-made document. Make sure you create a new list entry for each new persona.
A Deliverable is any piece of work which is ready to be shared with the client.
Even though we use other communication channels for daily-basis communication, in the ideal world, every iteration should be done here.
By doing so, not only can we centralize deliveries and keep them all in the same place, but also we make sure everything is saved and trackable, namely the client feedback.
Once you jump in you'll be presented with the list where you can create new Delivery entries. Make sure the Team creates a new entry for each iteration and names it accordingly.
At a Delivery point in time, the client should have already been invited and acquaintanced with Notion. With every Delivery, the client should be driven to this page as a way to keep iterations circumscribed to Notion, from all the Deliverable's details to feedback.
The goal is to have feedback in the context of its Deliverable.
As a PM, it is your responsibility to make sure the client feedback is converted into tasks on the Project Tasks Page and assigned to a Sprint later on.
The reason being of such a specific page is the attempt to avoid clients from interfering with the Development Team's focus. By having this page and incentivising clients to use it rather than interrupting the Team every time a bug pops, we're secretly increasing productivity and speeding up development.
It might seem otherwise, but bugging and pressuring the Team is counter-productive. It will affect their performance and their ability to deliver within the deadlines.
Inside this page, you'll find a table with a few important cells:
However, that's not all. Once a new bug is created, there's a way to add more information which, in some case, can be tremendously important and even strictly necessary. By mouse-over the Name cell, an Open button will become visible. Once you click it, you'll be prompt with a new Modal with a couple more fields to fill-in:
- Steps to reproduce;
- Technical information.
As a PM, it is your responsibility to make sure bugs are correctly reported, with enough information, as well as to make sure they get converted into Tasks on the Project Tasks Page as well as making sure the Bug Report table is always up-to-date.
Everything inside the Client-side is shared with the client and therefore available for their reading and editing.
Every page inside the Client Hub is a duplicate version of the pages on the Project Homepage. Once you edit them at one side, it will affect the other.
Said that, the client has access to:
- Bug Report;
- Sprint Report.
The first and only thing you should do at this sid of the PM Template is to change the Client Hub name from "PM template – Client Hub*"* to "[Project Name] – Client Hub".
Besides this, you can access all the pages from the Project Homepage. Virtually, there's no reason why you should come to this page ever again.
Once you're inside the Client Hub, you can invite clients. Simply click Share on the top-right hand corner of the screen, then click Invite a Person and type-in the clients' email addresses.
Make sure you change their permission to Can Edit only.
With all this, you are now ready to start managing projects using Notion.