Best Way to Set up the Levels for Overlapping Projects

I am trying to develop a management tool for rolling up key objectives to the company level while at the same time allow teams to manage their individual projects. I know at a high-level Coda should be good for this but I want to get some advice on how to lay out the proper hierarchies so I can get us off to the right start. Here is how we roughly manage our business.

We have several types of “Project” such as:

Business Key Objectives - These are 3 to 5 areas to build improvements to our business. The things we must get right to grow and succeed (not day to day work). We use our own type of RACI model to create the team members from people throughout the business.

Client Project Key Objectives - We have about 5 client project. For each of them we identify e 3 to 5 key objectives that each client project key objectives must achieve. These are “high-level” objectives and

For both of these Key Objective types above, they are high level and come with Mission statements on the pain points, objectives, guidelines, team members, key milestones with dates, etc. It is worth noting that the objectives are generally outside of everyone’s day-to-day roles and work so we are not tracking day to day objectives but unique things that could be one-time fixes, yearly goals related to a specific project, long term processes to deploy across the business or just a simple “hit team” for answering a strategic question.

So far - it should be pretty straight forward in Coda. The challenge is here. For a more complicated objective it will have sub-projects that need real tracking and monitoring, For example, “build a new marketing process” will have a number of independent project sub efforts that roll-up into the specific “client A project key objectives - marketing”. This could be operations team building systems to support the marketing team, another team building the marketing internal processes, and another team working on the content calendar, etc. So in otherwords the Company Obj=>Project 1 Objective “Build and launch new marketing effort for X client” =>Sub-Project 1 - Find and integrate new inbound marketing platform, Sub-Project 2 - Building Marketing Calendar with Client, etc.

So sometimes we need project teams and tracking at the objective level and sometimes at the sub-project level.

From a management perspective, every Objective has key milestone dates with metric we are using - some numerical, many not. So on a monthly all teams meetings we are doing a quick run through of all the company and client project key objectives. In other words we ask what is current status, where are we at versus what was projected at the end of last month, what are we projecting for the next months, what help or blockers are they facing. That’s is all we discuss. However at the sub-project level, team have many more dates, milestones, actions lists, etc that they are using to manage their tasks. I only need to look into the details when something is not on target or their is a key task that hasn’t been considered.

I am not sure how clear this is but I am not sure if every possible Key objective, Client project objective and Sub Project objectives all go on the same level and the create a view to filter it. Or should I nest various activities? Any thoughts or advice would greatly be appreciated. I am especially trying to understand the tradeoffs of what I lose through different approaches.

Should I consider managing the milestones using an OKR like independent project where I set up and track it with the team leaders and this is independent from sub-projects and project tracking or is there a way to set the key milestones withing the project/sub project itself and then have them feed up into the reporting?

Thanks

`

2 Likes

That sounds like a ragged hierarchy, take a look at this post, maybe you get some ideas: "Ragged Hierarchy" or "Snowflake" Data Structure in Coda

Coda itself is talking often about OKRs and there are several templates out there, maybe you can get some inspiration?

3 Likes

Following this with interest.

Does anyone have a demo Doc/Docs where a similar level of complexity has been achieved?

Happy to compensate for your time.

1 Like

Thanks for linking to Agile_Dynamics’ demo doc.

1 Like

I think I have achieved what I needed. I created high-level Program related to larger client projects, then I created Missions that are complex business improvement projects, some of which, are deeply connected to program and some not. Then I created task. Tasks can attached to any of the others. So basically, I define a program or a mission and then tell it which programs, missions or related. Once they are set-up the users can add any new tasks they want. When they create their own task (which can be sub-project) they choose if it is related to an existing program or mission (everything must be or else we won’t track it as a business). When they are in the task section to create it they can choose to add sub-projects also so they have as many levels as they need.

It sounds complicated and messy but really it is not since they just set up the task (project or sub-projects) with a few basic fields. The key is really about the views. We create the ability for viewing by program, person, mission, task, client. So basically since everything links back into a master table it is really easy if you have the specific use case in mind. The project tracking and work is done in the task tables and then when needed we can see those from any view we set up.

Hope that is useful. It takes a lot of work to make it useful from the user’s perspective but once it is in place it is super easy since everything is automatically updated and allows tons of flexibility.

1 Like

This is really helpful, thanks @Chris_DeAngelis.

I see you referenced a master table. Is the whole system working out of a single table?

Also, is the system running within a single Doc?

1 Like

Today everything is running in a single document since I don’t have too many security issues. Currently I have 3 main tables based on the usage of each of them. So for example, Program at the highest level asks the team to describe the overarching principles and high level goals - more of an annual check in and milestones. So most of this data doesn’t need to be accessed one it is there.

Then I have missions that are much more complex as far as my requirements so they are in another table.

Finally I have tasks which focus on goals, metrics, dates, progress, etc.

What you will notice there is no “main” or parent idea as it is much more like tagging since I add a lot of fields like clients, team members, project value, industry, and so one. So any time I can filter by these fields and show everything in the view I want connected to them.

Now that I get how it works, I am changing an moving things to make it work with reality.

2 Likes

Thanks for taking the time to respond. I’m very appreciative.

2 Likes