I decided to organize my to do lists and write up everything I plan to do in 2025. I started with goals, then projects, then tasks. This turned out more complicated than I thought. My goals have sub-goals. Projects have sub-projects. When I tried to use common PM apps like OpenProject or JIRA I found that my plans do not neatly fit on to the structure they provide. 1. Can you recommend a systematic PM/strategy approach for me to use? 2. Can you recommend an app for this? Saving Changes...
This isn't the only way to accomplish what you're trying to do, but google "OKR Framework". Have you heard of the book "Measure What Matters"? It's about using OKRs. Coursera also offers an OKR Certification course based around the book. Saving Changes...
Given that such plans are subject to frequent change, I'd take a rolling wave planning approach to it and not go to deep except for what you expect to complete in the next quarter.
OKRs are certainly one approach, but those tend to be used organizationally rather than personally. A simple, goals and projects structure is a good starting point for the overall year, with the breakdown into sub-projects reserved for near term initiatives. Do you really need sub-goals? Why?
First of all, thank you all for responding. I really appreciate the wisdom. Will look into OKR framework and how I can apply it in my case.
Kiron, here's an example of my goals and subgoals:
Goal: Increase company sales by 50%
Subgoal: Increase Amazon sales to $50k/mo
Subgoal: Increase Walmart sales to $10k/mo
Subgoal: Begin distributing internationally though partners
Subgoal: Expand product line
Under each of the subgoal I would have at least 1 project. In the case of "distributing through partners" the subgoal could be a project. Because there aren't that many tasks under it. But something like "Increase Amazon sales to $50k/mo" will have multiple projects under it:
- Improve A+ content for all listings. This includes taking and editing photos for many products, researching best practices, researching the market to an extent, etc
- Expand internationally to overseas Amazon sites. This involves satisfying regulatory requirements from 10+ countries, registering for tax IDs and IORs where needed, creating listings in these marketplaces, shipping goods to local Amazon warehouse, etc
- Form a team to manage Amazon sales. This involves deciding on org structure, finding talent, creating on-boarding docs, hiring people, etc.
The goal of expanding product line also involves multiple projects, which have to do with market research, producing test batches or buying outsourced, etc.
Yet most of these subgoals are not really required for me to achieve the overarching goal. I may be OK with doing fewer projects and still be able to achieve it.
Things got pretty complicated, so I thought may my approach was off. Hence I'm here.
...
1 reply by Aaron Porter
Jan 10, 2025 9:13 AM
Aaron Porter
...
Thank you for the additional context of your situation. I suggested OKRs expecting others to provide more options. Your example makes it look like they could still work, but they're not effective when done in a silo, and adoption can take time. One of the ideas behind them is aligning activities with department and company objectives. However you tackle things, keep this in mind. It's not about using a specific tool or approach, it's about aligning work with objectives. The tool/approach you use should help you do that.
Not to complicate matters for you, but not everything listed as projects are projects. There are programs and operations activities mentioned, as well. This doesn't change the outcomes you are trying to achieve, but it does highlight why this effort could seem a little overwhelming. Envisioning the complete picture is nice, but sometimes it's too much to take in all at once. Using a project as an example, I often manage and report at the work package level (a group of related tasks that one individual is responsible for), not the task level. If I need to dig deeper into the work package, I'll go to the individual. Trying to show every detail in one view can lead to static instead of a comprehensive view. The complete picture needs to exist, but you don't need to look at all of it at once, all the time. A little bit of abstraction can help prevent distraction.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
To put this in terms of the PMI you will find the guidelines inside the documentation related to business analysis. The "new buzzword" is OKRs. I am using the word buzzword because it is just a new way to call things that existing from long time ago if you go to business administration literature. The key is: make it simple. You have to make an analisys using a model. For example McKinsey 7s model. With that on hand you will find the strategic themes (between other things) to move your organization or just a business unit or a team between it from the actual state to the desire state. To convert Strategic Themes into work you will define Initiatives. Initiatives will realize Strategic Themes. From Strategic Themes Objectives will be defined. Objectives can be met by defined Epics (just in case you are using agile approach). From Objectives you will define Key Results. Key Results will be achieved by completing Features. Features are defined from Epics and Features are the characteristics that the solution should have, where solution is equal to "the thing" to be created plus "the way" to create it. That´s the simple taxonomy. You can see this in two interrelated columns: at the left the transformation (Strategic Themes, Objectives, KRs) at the right the work to make the transformation a reality (Initiatives, Epics, Features). All the picture has to be created in a time line called Roadmap. Saving Changes...
Thanks for the clarification. Given that there is a many-to-many relationship between initiatives (projects and programs) and goals & sub-goals, a hierarchical visualization would not work for you.
Given that a project or program might address multiple goals or sub-goals but likely predominantly addresses one, a simple approach might just be to use a spreadsheet whereby goals, sub-goals, and programs are columns associated with a project. When all the projects associated with a goal or sub-goal are completed, you can deem that goal or sub-goal completed.
You could also look at either creating a simple RDBMS-based information system or look into a PPM solution, but both might be overkill (and costly)!
First of all, thank you all for responding. I really appreciate the wisdom. Will look into OKR framework and how I can apply it in my case.
Kiron, here's an example of my goals and subgoals:
Goal: Increase company sales by 50%
Subgoal: Increase Amazon sales to $50k/mo
Subgoal: Increase Walmart sales to $10k/mo
Subgoal: Begin distributing internationally though partners
Subgoal: Expand product line
Under each of the subgoal I would have at least 1 project. In the case of "distributing through partners" the subgoal could be a project. Because there aren't that many tasks under it. But something like "Increase Amazon sales to $50k/mo" will have multiple projects under it:
- Improve A+ content for all listings. This includes taking and editing photos for many products, researching best practices, researching the market to an extent, etc
- Expand internationally to overseas Amazon sites. This involves satisfying regulatory requirements from 10+ countries, registering for tax IDs and IORs where needed, creating listings in these marketplaces, shipping goods to local Amazon warehouse, etc
- Form a team to manage Amazon sales. This involves deciding on org structure, finding talent, creating on-boarding docs, hiring people, etc.
The goal of expanding product line also involves multiple projects, which have to do with market research, producing test batches or buying outsourced, etc.
Yet most of these subgoals are not really required for me to achieve the overarching goal. I may be OK with doing fewer projects and still be able to achieve it.
Things got pretty complicated, so I thought may my approach was off. Hence I'm here.
Thank you for the additional context of your situation. I suggested OKRs expecting others to provide more options. Your example makes it look like they could still work, but they're not effective when done in a silo, and adoption can take time. One of the ideas behind them is aligning activities with department and company objectives. However you tackle things, keep this in mind. It's not about using a specific tool or approach, it's about aligning work with objectives. The tool/approach you use should help you do that.
Not to complicate matters for you, but not everything listed as projects are projects. There are programs and operations activities mentioned, as well. This doesn't change the outcomes you are trying to achieve, but it does highlight why this effort could seem a little overwhelming. Envisioning the complete picture is nice, but sometimes it's too much to take in all at once. Using a project as an example, I often manage and report at the work package level (a group of related tasks that one individual is responsible for), not the task level. If I need to dig deeper into the work package, I'll go to the individual. Trying to show every detail in one view can lead to static instead of a comprehensive view. The complete picture needs to exist, but you don't need to look at all of it at once, all the time. A little bit of abstraction can help prevent distraction. Saving Changes...
Community Champion
