Should all nodes in AoA represent milestones? What if I need to show several activities like
a1,a2 where there is a single milestone after a2?
In an Activity-on-Arrow diagram, all of the nodes represent a specific achievement in a project with zero duration. A milestone is also an achievement in a project that doesn't impact duration.
It's likely that at least some, if not all, nodes correspond to project milestones. It does depend on who's perspective you are calling it a milestone. A node could represent an internal milestone as opposed to a milestone to an external stakeholder. To reach a milestone in the project, you may need to accomplish several of the achievements represented as nodes on the AOA diagram.
If you want to differentiate between activities and milestones, consider dummy activity arrows. In your particular case, if A1 leads into A2, you can either identify node A2 as the milestone or have a different node to represent the milestone with a dummy activity arrow from A2, as dummy activities have a completion time of 0. This would also allow you to sync up multiple nodes that are prerequisites for achieving the milestone.
What if I need to show several activities like a1, a2 and at the end of a2 there is a milestone?
In activity-on-node (AoN), you'd be looking for the concept of "virtual nodes." Standard nodes within the diagram represent activities. Nodes that represent collections of activities, decision points, or other non-activities are inserted as logical nodes.
In activity-on-arrow (AoA), each node represents a zero-duration milestone of one kind or another, while the arrows represent activities. In this type of diagram, you can use dummy arrows to represent logical dependencies that roll up into a larger milestone. While not common, it's also certainly possible to borrow the notion of virtual nodes from AoN, and having activities or nodes roll up into a virtual node using dummy arrows. However, if you're doing this often, it may mean that AoA is not the ideal representation for your particular project.
In short, with AoA you should refactor your work packages so that each activity is large enough to lead to some sort of milestone. Otherwise, leverage dummy arrows and logical nodes to represent the roll-up, or switch to a better graphical representation like AoN or a precedence diagram.
Many practitioners consider AoA diagrams to be outmoded. In practice, they have generally been superseded by AoN or precedence diagrams. So, the first recommendation is not to use AoA unless you have to, precisely because of the sorts of visualization problems you're experiencing.
With that said, the dictionary describes a milestone as "an action or event marking a significant change or stage in development." The key word here is significant. In AoA, this may force you to visualize work in less-granular terms, such that each node represents sufficient progress to be significant. That in turn means that each activity arrow much be sufficiently high-level that the end result of the activity is a significant change, which makes it hard to diagram granular dependencies within work packages.
If you have a milestone with multiple precedent dependencies, you can use dummy arrows to represent dependencies within your diagram that can't be representated as a standard sequence. Consider this example:
Photo credit: cpmtutor.com
In your specific case, you should:
- Refactor a1 and a2 so that each activity leads to a milestone of some level of significance.
- If a2 is dependent on a1, link a1 to the milestone preceding a2 (if possible).
- If a1 is a prerequisite for the milestone following a2 (let's call that m1), but not required for a2 itself, then use a dummy arrow to link a1 to m1.
Alternative Method: Activity-on-Node (AoN)
Because AoA has so many known problems and edge cases, it may be worth your time to consider alternative representations. It's worth carefully evaluating whether AoN would better represent your data or planning/execution process.
Activities are Standard Nodes; Milestones are Virtual/Logical Nodes
Within the Critical Path Method, a standard node is a component within an activity-on-node (AoN) diagram that represents an activity. An activity generally is a task or work package that provides a useful unit of work that is a dependency for a subsequent task/package within the project.
Milestones, on the other hand, are typically represented as logical or virtual nodes within the diagram. This can be done by using a different shape or color for the node to ensure that milestones and activities aren't visually confused with one another.
Milestones Consist of Activities
As a pragmatic rule of thumb, if each activity is a milestone then there's really not much point in differentiating between the two. Furthermore, most businesspeople and project managers expect a milestone to represent some sort of roll-up of tasks or work packages, rather than discrete units of work. So, while you could create a project plan that consisted of only of milestones, it's likely that doing so would result in a project plan of insufficient granularity for effective planning and management.
Therefore, milestones should generally represent a collection of activities that provide a sensible inflection point for the project. While one could argue that each activity within the project should be measured and controlled, in practice senior management typically concerns itself only with major milestones. Therefore, how much work or which points within the project should be denoted as milestones will depend on:
- your project plan's level of granularity,
- your organization's politics,
- the level of executive/stakeholder oversight, and
- any contract terms that may apply.
Depending on your framework and methodology, these milestones may define potentially-releasable increments, a completed set of features, a phase gate, one or more delivery targets, a payable chunk of earned value, or any other turning point within the project that makes sense for your organization.
Activities and Milestones: Many-to-One
I don't think you'll find a "one size fits all" definition of what a milestone should be in every organization or every project. However, I think you'll find a consensus among project management practitioners that activities and milestones should generally have a many-to-one relationship. There can certainly be edge cases, but they will be the exception rather than the rule.