Help

Re: Newbie question: Base for PMO

Solved
Jump to Solution
94 1
cancel
Showing results for 
Search instead for 
Did you mean: 
Country_Pigeon
5 - Automation Enthusiast
5 - Automation Enthusiast

Hi All,

I am new to Airtable and I would like to set up a Project Management process based on our annual Strategic Realization (SR) OKRs. Each SR has its own project schedule, in some cases more than one schedule, depending on the KRs and deliverables.

For reporting and tracking purposes, we plan to:

  • Track project deliverables and milestones within the SR schedules and using a calendar view.
  • Maintain a roadmap view for Leadership.
  • Generate a report with custom PMO metrics.
  • Use a form that, when completed, populates a weekly status report sent to all stakeholders across all SRs.

My question is: In this scenario, should each SR project schedule be its own base that feeds into a single Calendar, Roadmap, PMO Metric Report, etc.?

Thank you in advance, and I apologize for the basic nature of my question.

 

1 Solution

Accepted Solutions

I may not have my terminology correct, but if we are mainly tracking 3-4 projects and their progress, we could have a base with each schedule as a separate table, correct?

Yeap pretty much.  How much leeway does each of those PMs have to dictate how their teams work?  If there isn't much leeway at all, then you may as well get them to all use one base

---

I'm thinking I would create the table fields that all PMs have to adhere to in order to maintain consistency. From there, we could make the various views, such as calendars, reports, etc., from the data in the tables.

Yeap!  Then as long as they had those fields you'd be able to sync to your reporting base

===

It feels like the main question is how much agency your teams have I think.  If the plan is to tell them 'Here's Airtable, use it for your projects' and expect them to create their own tables, fields, formulas, automations etc (and trust them to do so!), then having separate bases would be the way to go so people don't get in each other's way

Managing a base used by multiple stakeholders becomes a bit of a nightmare because you're never really sure how a change you're making in one place might affect someone else's workflow.  For example, you might have a "Status" select field where there's an option called "In progress", and you update it to be "Ongoing" instead.  A few hours later you find out someone's formula field broke because they were looking for the text "In progress", and that field triggers an automation.  (This was not a fun experience heh)

Airtable kind of recognizes this as a problem and has a feature that helps with this called the App Library (https://support.airtable.com/docs/using-app-library-and-components-in-airtable), and the idea is you create the skeleton of a base that your teams deploy on their own, and you can set what bits can or can't be modified by those users.  This is Enterprise only though

If you mostly expect them to use their own systems and then update Airtable for reporting purposes, then you can stick to one base, and if you don't trust them to create their own systems properly, then you should also stick to one base!

 
Happy to get on a quick (free) call to hammer out any questions you might have, and you can grab a time that works for you here!

See Solution in Thread

10 Replies 10

You always want to try to keep everything in one base as much as humanly possible. There are very few reasons to ever break things up into separate bases, which would end up making things infinitely more complicated for you in the long run.

Hope this helps! If you’d like to hire an expert Airtable consultant to help you with anything Airtable-related, please feel free to contact me through my website: Airtable consultant — ScottWorld

Thank you!  So in my case, would the data from the project schedules form the base, or the OKRs? I'm little fuzzy on this. Thank you for your time!🙏

 

ScottWorld
18 - Pluto
18 - Pluto

You may be helped by watching the first chapter of my free Airtable training course, which you can take for free by signing up for a free 30-day trial with LinkedIn Learning.

In  the first chapter, I discuss proper database structure and how you can figure out how to properly structure your data.

Note that the rest of the course is relatively outdated because it was created in 2020, but the core concepts still remain solid and valuable.

Hope this helps! If you’d like to hire an expert Airtable consultant to help you with anything Airtable-related, please feel free to contact me through my website: Airtable consultant — ScottWorld 

Thank you, Scott! I'm going through it now - I appreciate your quick response.

My question is: In this scenario, should each SR project schedule be its own base that feeds into a single Calendar, Roadmap, PMO Metric Report, etc.?

Hmm this depends on how you're planning on using it?

Some good reasons for breaking it into different bases might be:
1. You've got a dataset that multiple departments might need to use (e.g. a Client list) that only specific people should be able to modify.  And so you'd put that data into a different base and sync it over to other bases or use it as a data library: https://support.airtable.com/docs/data-sets-and-verifying-data-in-airtable

---

2. Different teams might have very different ways of working, and you might want them to have the freedom to make modifications to the base structure themselves without messing up other team's workflows or going through you to make changes
  - This is somewhat mitigated by using Interfaces for this and allowing each team to have their own Interface that's private to them.  They'd still be making changes to the base structure though, which might be confusing in the long run to other team members who have access to the same base.  And you'd need to give them Creator permissions to the base and so they'd be able to accidentally modify / delete fields, formulas, automations etc.  If not, every change would need to go through you, which might be a good thing depending on the desired workflow?

And so if each SR project schedule's going to be managed by a team of people and they're going to be using Airtable to work, then it might be worth considering giving them their own base with strict instructions on how you expect data to be formatted so that you can do proper reporting.  They'd format it the way you want in a separate table and you'd just sync it over to your reporting base track milestones, create the roadmap view etc

If this is just going to be a small team of people using Airtable then I wouldn't worry about this overmuch and would just keep everything in one base though

---
3.  Record limits!  Each plan comes with different record limits per base; the Teams plan comes with 50k records per base, while Business comes with 125k, Enterprise 500k.  If your workflow involves say, logging a lot of data and consolidating it, then it might be worth considering separating that out from the get go and creating a system to handle that

As an example, I know someone who needs to log every Shopify order they ever get so that they can deal with shipping details on a per order basis.  As such, we created a base that just logged said orders, and created a table that would consolidate those order details (e.g. # orders in last week, last month, etc), and then synced that table to their main working base

This allowed them to keep using their main base to do their work, and when the orders logging base ran out of room we just duplicated it to keep the historical data and then deleted all the records

Thank you for the thorough reply!

It is just our team (PMO) and the project teams that will work with the data. 

I may not have my terminology correct, but if we are mainly tracking 3-4 projects and their progress, we could have a base with each schedule as a separate table, correct?I'm thinking I would create the table fields that all PMs have to adhere to in order to maintain consistency. From there, we could make the various views, such as calendars, reports, etc., from the data in the tables.

Am I understanding correctly? 

I would not recommend this approach. You want to consolidate everything that is a similar "type of thing" within the same table. Otherwise, you'll end up duplicating your work over and over again.

ok - so if we have 6 project schedules for different projects, they should be in one long table?

I appreciate the help - I went through many tutorials but can't find anything similar around project management.

ScottWorld
18 - Pluto
18 - Pluto

Yes, that's correct.

p.s. If you'd like to work with an expert Airtable consultant on your project, feel free to contact me!