How to keep track of all the goals of a large project?

Question

I have a very large library project in-progress involving French linguistics - (it will be) multi-faceted to work with the many aspects of language, including algorithmic inflections/conjugations, generative grammar definition, phrase generation, syntax analysis, lexicon interfaces, etc.

I've had a lot of ideas for the aspects of the project that I want to implement, and I have a pretty big whiteboard. I'm running out of room though; it's looking quite cluttered, and I'm having a hard time finding the things that I need to find that I am working on right now.

There are a million-and-one things that I need to do and keep track of, which will take me years to fully implement, and a whiteboard just isn't cutting it anymore. I'm trying to keep track of what I want to do, as well as a lot of the implementation ideas that I have for particular features.

I'm sure this is something project managers do all the time, but I'm not one, so the question:

How can one efficiently keep track of all of the goals and implementation ideas for a large project?

PS - I've been using Trello to keep track of what I'm implementing at the moment, but it doesn't help with the overall project goals. I'm not asking for a tool, but I'm sure that project managers use one, so I wouldn't be opposed to that being a comment or answer if a good tool exists.

Edit: To clarify based on Joel's comment, I'm trying to keep track o the project's requirements and implementation (2); any tools that could aid in doing so would be helpful. The team size is currently 1, but could expand to 2-3 in a year or two as I ask for help from my peers at the university.

Answer 1

Mathias' answer is solid. I personally would not go to a full Scrum for this, based on it being a single person project and work in progress is the more critical thing going on here. So I'd stick with a straight Kanban workflow with careful watch on your WIP limits for active work.

Essentially you need to tier your backlog. Like a funnel you get deeper and deeper detail as you get closer to the actual work done. Here is what I tend to use.

Epic- At this level you have a backlog of the general high level things that need to get done. For example, if we were building the next Tesla car, an Epic item might be "New Dashboard". You don't need more detail than this. If you do know items in the Dashboard that need to be done, list them as acceptance tests to the "New Dashboard" Epic. So you might have "Glovebox" and "Driver's Multi-Function Display" listed as an acceptance test in the Epic for "New Dashboard".

Feature- An Epic will decompose into usually 4-6 Features. These are still "projects" in an of themselves, though you are getting into more detail and understanding. Using the Tesla example, we'd now be looking at the "Driver's MFD". We start having more detail of what is going to happen and the acceptance tests should be more extensive.

User Story- This is the actual work product. A small enough piece of work it can be done in a few days time (2-3 being optimal). Continuing the example above, "Low Tire Pressure Warning Light" could be a User Story from the "Driver's MFD" Feature. At this stage you have a fully detailed story that meets the Definition of "Ready", i.e. it is ready to be worked on.

Tasks- While I try to avoid tasks, by instead decomposing User Stories down small enough, tasks can still have some use. If you have a three day User Story, breaking up the work into tasks can help you to better manage your blocks of time. I don't estimate tasks though. I stop estimating at User Stories. Tasks is just a way to break up your work day into manageable chunks. I tend to list tasks just as Acceptance Tests of the user story.

This is three separate backlogs with increasing degrees of detail. By keeping them in their own backlogs, you can not lose the big picture while focusing on the detail work.

Tools Tip: I've been using Trello for years. I use the Checklist feature for tracking "acceptance tests" or sub-tasks. That keeps the Epic and Feature backlogs from getting cluttered. If you're using a physical board, invest in some large size post it notes and write your Epics and Features on these. Then you can use the back of the notes to write down acceptance tests or sub-tasks.

Answer 2

I would recommend to apply a Scrum project approach here.

You should define your minimum viable product.

You create a larger backlog which contains all project ideas (or user stories).

You organise then sprints where you pick the backlog items on which you want to work on next.

Trying to track all the goals at the same time will not work.

You need to define the goals in a low detail level first and then introduce more detailed ideas on the fly. So that all details are specified right before implementation during the sprint.

You can then have a tactical level where you define and organise the details for a sprint. And the strategic level where you organise "the bigger picture".

Answer 3

I'm going to offer an old school answer - you need a work breakdown structure.

1. Define the end product - what will done look like? This is 100% of the work. Aside: I would advise you to do this even if you adopt the other answers. Your comment, I've had a lot of ideas for the aspects of the project that I want to implement makes me suspicious that the problem is not that you need to keep track of a plethora of goals, but that you haven't scoped the project. Success comes not from implementing all the cool ideas you have, but from rigorously scoping the project to something that is clear, distinct, bounded and achievable. You may find that by stripping the idea down to the minimum viable product, you've also reduced the number of things you need to keep track of to a manageable number. If an idea is cool, but outside the scope of the minimally viable product, write it down and add it to the backlog of things you'd like to do later.

2. Break the product/end state down into smaller packages. Each package should begin with a verb and be testably complete. The combination of all the packages at any level should add up to 100% of the work.

3. Break down each package into smaller packages. Work recursively until a package is 40 hours or less.
4. Sequence the packages - which packages rely on other packages? Which have to be done first or last.
5. Take a look at how much time you have. If you have 40 packages each of which will take you 40 hours to complete, you need to admit that this project won't be done for 1.5 to two years. If that deadline is too far out, you need to go back to step 1 and move more cool ideas from the production queue to the backlog.

Answer 4

I would highly recommend considering a product/story map (Google "story mapping" for starting points); physical if you have the space, digital if not. I've tried all sorts of backlogs and work views for different-sized projects over the years, and found that "flat" formats that don't actually represent the product just don't provide enough context and "wholeness". When planning things out, it's far easier to spot missing features or hidden work in a map than in a giant list of stuff. You can also pair it with an iteration or kanban board as others have recommended, where the map is the big view and kanban is the immediate view.

You can cover most of the common functions of a flat backlog by visually marking it up - risky items, incomplete cards or features to return to, dependencies, external components, iterations, contingencies, etc. I've even mapped out key UX moments (or "product pillars") to specific cards so that it's clear where the user will hit them in each path or feature area. The main drawbacks I've found with physical vs. digital maps are not being able to search across it quickly, and it can be painful to get total remaining work (since you have to manually count), but that can be mitigated by staying on top of it regularly, and grouping things up into chunks/sprints/kanban card velocity.

Answer 5

The root problem of your question is dealing with complexity. It might help to see how a other domains (beside PM) try to handle complexity.

How do (we) programmers deal with complexity in the systems we analyse? We use tools (or maybe these are strategies). Be aware that there might be two sides to deal with complexity, what is shown in my bullet list. It might be worth to google for some of those techniques or principles.

• generalisation and specialisation;
• information hiding, encapsulation;
• aggregation, composition;
• separation of concerns;
• modularisation;
• levels of detail.

On an abstract level it's always about

1. Highlight the goals speciality in order to define a clear scope
2. Summarising associated goals