Work, Overhead and Flow
There are a lot of modern foundations and workflows for creating, managing and moderating a project, and AbleTime was designed from the ground up to allow for flexibility in how organizations mapped, planned and executed them. That said, there are some fundamentals you should understand based upon some of the core principals around project planning that AbleTime encourages.
The 4 types of work
There are 4 essential types or categories of Work involved in execution of an organizations projects. "Work" in this definition are the physical actions a company undertakes to produce a tangible, measurable result. The general rule is that, for it to be considered Work you should be able to point to something (a new column in a database, an updated client record, a door that no longer squeaks) and say: this is what that Work produced.
Work is separate from Overhead. Organization, backlog, meetings and the like should be treated as Overhead, i.e. time spent on things that are not specific in nature, or do not produce a tangible result.
Business Projects (The "Value" Work)
This is the type of work you are probably most familiar work, the creation of "deliverables", whether that's physical products, digital applications, professional services or any other business process that expects to "deliver" something during or upon completion of a workflow.
In AbleTime, these are represented by your Epics. These should generally only contain tasks that move the needle on a deliverable. Epics are "containers of Tasks" that when completed produce something tangible.
Rule: If a Task in a given Epic doesn't contribute to the "Definition of Done" for the feature, it doesn't belong.
The "Veteran" Sin: Putting "Weekly Standup" here. A meeting doesn't ship code or produce a widget. It’s a tax on the project, not the project itself.
Internal Projects (The "Foundational" Work)
This type of work isn't usually visible to an organization's customers. It's where the internal support processes and procedures are created. For instance, a marketing company creating a shared brand asset folder, or IT creating a help form for employees to use.
Rule: Internal Projects have their own Epics, and never mix with external work. They should be tracked separately so you can see your Investment vs. Feature ratio.
The "Veteran" Sin: Hiding "Refactoring the API" inside a "User Login" Epic just because that’s where they happened to be working when they noticed the code was garbage.
Changes (The "Maintenance" Work)
This is planned internal work for maintaining existing processes. It is pre-approved, low-risk, and often repeatable in nature (updates, patches, customer follow-ups). It should be well-defined, documented and organized.
Rule: Changes should be focused and of a short duration. If they take more than a few hours, they likely belong in an Internal Project.
The "Veteran" Sin: Creating a 40-hour Epic for "Monthly Maintenance" and then padding it with random meetings or treating it like a catch-all.
Unplanned Work (The "Friction")
This is the most dangerous and destabilizing type of work, and yet often goes all but unrecognized in project planning. It isn't your "Overhead" bucket and shouldn't just live as a "Firefighting" tag.
Rule: This is the most important metric in your app. You want this to be visible and painful.
The "Veteran" Sin: This is exactly what they are trying to avoid. By "taskifying" a meeting, they are taking "Unplanned Work" (or Coordination Headroom) and pretending it was "Planned Work." It makes their capacity look 100% utilized on the Gantt chart, but it hides the fact that the team is actually drowning in syncs.
Overhead (Is not the Enemy)
Overhead includes necessary activities that do not directly produce deliverables. Meetings, training, mentoring, and general coordination all fall into this category.
Overhead is not waste—it is part of running an organization. However, it must be measured.
For example, if a designer has a weekly capacity of 40 hours but spends 20 hours in meetings or mentoring, planning work against a full 40 hours will consistently overcommit that resource.
Tracking Overhead allows capacity to be measured realistically.
Tip: use Tags judiciously. Every extra step is friction for your users, and heavily taxing every time entry with things like Tags can end up reducing buy-in and participation and actually reduce the quality of your information.
The Bottleneck
The payoff to this type of project planning is worth noting here. When you start organizing the 4 types of work + Overhead in your organization, you will begin to identify pinch-points in your delivery. Perhaps you have constrained designer resources, or an over-taxed operations team. When you do, your focus should be entirely on optimizing and improving that position of friction.
“Any improvement not made at the constraint is an illusion.”
— Eliyahu M. Goldratt
As the saying goes, a chain is only as strong as its weakest link. By categorizing your work by the 4 types of work, and monitoring the throughput of your Velocity, Burn Rate and Estimates, you should quickly identify where these pain points exist, and work to relieve the pressures causing them.
The Goal
The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt remains one of the most influential books on operational flow. Its central idea is simple: every system has a constraint, and the system’s performance is governed by that constraint.
Unexpected disruptions—illness, outages, defects—are inevitable. Healthy project planning does not eliminate disruption, but it allows teams to absorb it without collapsing delivery schedules.
Good project management is less about maximizing activity and more about maintaining stable flow. When the system is balanced and capacity is understood, delivery becomes predictable.
The healthier the flow of work, the more consistently results follow.