How to Find Duplicate Task Names in Microsoft Project

You can find Microsoft Project duplicate tasks by sorting the schedule on the Name field, grouping tasks by name, or running a Visual Basic for Applications (VBA) macro that flags every repeated name. Sorting works well for a quick review. However, a macro provides the most repeatable method for a large Integrated Master Schedule (IMS).

Duplicate names do not always indicate duplicate scope. Two tasks may share a name while representing different work packages, control accounts, or Work Breakdown Structure (WBS) branches. Therefore, review the task’s Unique ID, WBS position, dates, logic, and responsible organization before changing or deleting anything.

The procedures below apply to the Microsoft Project desktop client. Ribbon labels may vary slightly by version or organizational configuration.

Why Duplicate Task Names Matter

Microsoft Project assigns each task an ID and a Unique ID. The task name is descriptive text, not the most reliable identifier for schedule analysis. Microsoft documents the Task.Name property separately from the Task.UniqueID property, which returns the task’s unique identification number.

Even so, repeated names can create practical problems. A scheduler may update the wrong activity, a Control Account Manager (CAM) may misunderstand a status request, or a reviewer may cite an ambiguous task in a comment. Duplicate names also make schedule narratives, risk-register references, and change-control records harder to trace.

This issue becomes more significant in a large IMS. If several tasks are named “Complete Design,” the name alone does not tell the team which subsystem, work package, or event the task represents. A well-structured schedule should give users enough context to identify the intended work.

Duplicate-name review is a schedule quality-control practice. It is not, by itself, a contractual compliance test. Apply any contract-specific data-item, coding, or naming requirements separately. For broader schedule review considerations, see the IMS customer-delivery review checklist.

Method 1: Sort Microsoft Project Duplicate Tasks by Name

Sorting is the fastest no-code method. It places identical or similar task names next to one another so you can inspect them.

1. Save a working copy of the schedule before changing views, fields, or task data.
2. Open the Gantt Chart or Task Sheet view.
3. Display the Name, Unique ID, and WBS fields. Also consider displaying Start, Finish, Duration, Predecessors, and Successors.
4. On the View tab, open the Sort menu and select Sort By.
5. Select Name as the primary field and choose ascending order.
6. Clear Keep outline structure if you want to compare names across the entire schedule rather than only within each summary branch.
7. Leave any option to permanently renumber tasks cleared.
8. Apply the sort and scan consecutive rows for matching names.

Microsoft’s Project Sort method documentation confirms that Project can sort tasks by a specified field and preserve or disregard the outline structure. In the user interface, disregarding the outline structure is often necessary because duplicates may sit under different summary tasks.

Use Unique ID and WBS to evaluate each match

Do not delete a row simply because its name matches another row. First, compare the following fields:

• Unique ID: Confirms that the rows represent separate task objects.
• WBS or outline path: Shows where each task sits in the scope hierarchy.
• Start and finish dates: Helps distinguish repeated work occurring in different periods.
• Predecessors and successors: Shows whether each task has a separate role in the network.
• Resource, control account, or work package coding: Identifies organizational ownership.
• Notes or activity identifiers: May provide additional context.

After the review, reapply your normal view or sort by ID to restore the familiar display. This workflow is especially useful when reviewing a schedule built using a formal WBS. See how to structure an IMS using the WBS for related guidance.

Method 2: Group Tasks by Name

Grouping provides a clearer visual separation than sorting. Project creates a group heading for each task name and places matching tasks beneath the same heading.

1. Open a task view such as the Gantt Chart.
2. On the View tab, open the Group By menu.
3. Select More Groups.
4. Create a new task group.
5. Give it a descriptive name such as Tasks by Name.
6. Set the grouping field to Name and the order to ascending.
7. Apply the group.

Groups containing multiple task rows identify repeated names. However, a large schedule may produce hundreds of single-task groups. Therefore, grouping works best for a focused review or a smaller file.

Grouping also changes how the hierarchy appears on screen. It does not replace the schedule’s actual WBS or summary structure. When finished, select No Group to return to the normal presentation.

Method 3: Flag Duplicate Task Names with VBA

A VBA macro is the most efficient option when the schedule contains hundreds or thousands of activities. The macro below scans the active project’s task collection, counts each task name, and sets Flag1 to Yes for every name that occurs more than once.

The comparison ignores capitalization and leading or trailing spaces. For example, it treats “Release Drawing Package” and “ release drawing package ” as the same name. It does not treat different punctuation or extra spaces inside the name as equivalent.

VBA macro for Microsoft Project duplicate tasks

Option Explicit

Sub FlagDuplicateTaskNames()

    Dim counts As Object
    Dim t As Task
    Dim key As String
    Dim duplicateRows As Long

    Set counts = CreateObject("Scripting.Dictionary")
    counts.CompareMode = vbTextCompare

    'Clear Flag1 and count each nonblank task name.
    For Each t In ActiveProject.Tasks
        If Not t Is Nothing Then
            t.Flag1 = False
            key = Trim$(t.Name)

            If Len(key) > 0 Then
                If counts.Exists(key) Then
                    counts(key) = counts(key) + 1
                Else
                    counts.Add key, 1
                End If
            End If
        End If
    Next t

    'Flag every task whose name occurs more than once.
    For Each t In ActiveProject.Tasks
        If Not t Is Nothing Then
            key = Trim$(t.Name)

            If Len(key) > 0 Then
                If counts(key) > 1 Then
                    t.Flag1 = True
                    duplicateRows = duplicateRows + 1
                End If
            End If
        End If
    Next t

    MsgBox duplicateRows & " task rows were flagged in Flag1.", _
           vbInformation, "Duplicate Task Name Review"

End Sub

The code uses Microsoft’s documented Project.Tasks collection and reads the Name property for each task. It then writes the result to Flag1, a read/write custom task flag.

How to install and run the macro

1. Confirm that Flag1 is not already used for another schedule-control purpose.
2. Press Alt+F11 to open the Visual Basic Editor.
3. Select Insert and then Module.
4. Paste the macro into the new module.
5. Close or minimize the editor.
6. Press Alt+F8, select FlagDuplicateTaskNames, and choose Run.
7. Insert the Flag1 column in the task table.
8. Filter Flag1 to display only Yes values.

You can rename Flag1 to “Duplicate Name” through the custom-field settings. However, the VBA property remains Flag1. If Flag1 already supports another process, change each t.Flag1 reference in the code to an unused field such as Flag2.

Only run macros that you understand and trust. Microsoft provides additional guidance on using VBA in Office. Your organization’s security settings may also restrict macro execution.

Example: Reviewing Repeated Names in an IMS

Consider a fictional radar modernization program with a 1,600-line IMS. The duplicate-name macro flags six tasks named “Release Drawing Package.”

The scheduler reviews each task’s Unique ID and WBS path. Four tasks belong to separate antenna, power, cooling, and enclosure work packages. Those names describe real, separate scope. However, the names remain ambiguous when used in meeting minutes or schedule narratives.

The scheduler renames them as follows:

• Release Antenna Drawing Package
• Release Power Supply Drawing Package
• Release Cooling Drawing Package
• Release Enclosure Drawing Package

The other two rows have the same predecessor, successor, dates, resource assignment, and WBS location. A planner copied the task during an earlier update and never removed the extra row. After confirming the intended scope with the responsible CAM, the team deletes the unintended duplicate and checks the surrounding network logic.

This example shows why a repeated name is a review trigger rather than proof of an error. A mature process combines automation with WBS, logic, ownership, and scope analysis. That approach aligns with the broader role described in Microsoft Project for Integrated Master Scheduling.

Exact Duplicates Versus Near-Duplicate Names

The macro finds exact text matches after removing spaces from the beginning and end of each name. It will not automatically equate the following variations:

• Complete Software Test
• Complete SW Test
• Complete Software Testing
• Complete Software Test – Increment 1
• Complete  Software Test

Sorting by Name helps expose these near duplicates because similar wording often appears together. You can also search for recurring verbs or nouns such as “complete,” “release,” “review,” or “test.”

However, standardization should not make every task generic. Names should distinguish the deliverable, system, event, or scope element. “Complete Review” provides little value. “Complete Flight Software Preliminary Design Review” gives the team a clearer reference.

Common Mistakes During Duplicate-Name Cleanup

• Deleting tasks based on the name alone. Compare scope, WBS location, logic, dates, and ownership first.
• Keeping the outline structure during a global sort. Tasks under different summary branches may never appear together.
• Using ID as a permanent reference. Microsoft notes that a task’s ID can change when its position changes. Use Unique ID when you need a more stable internal reference.
• Overwriting an occupied custom flag. Verify that Flag1 is available before running the macro.
• Ignoring summary tasks. The macro checks detailed and summary tasks. Repeated summary names may also create ambiguity in reports and exports.
• Renaming without checking downstream artifacts. Review schedule narratives, risk references, procedure documents, exports, and change records that may cite the old name.
• Assuming every repeated name is wrong. Repetitive scope may be legitimate, especially across separate WBS branches or production units.

Recommended Workflow for Program Schedulers

1. Run the duplicate-name macro on a controlled working copy.
2. Filter Flag1 to Yes.
3. Display Unique ID, WBS, dates, logic, and ownership fields.
4. Classify each result as legitimate repeated scope, ambiguous wording, or an unintended duplicate row.
5. Coordinate scope questions with the responsible CAM or work-package owner.
6. Rename ambiguous tasks using the applicable naming convention.
7. Remove only confirmed duplicate scope.
8. Recheck predecessors, successors, dates, constraints, and critical-path effects.
9. Document material corrections through the program’s schedule and baseline change processes when required.

Finally, rerun the macro before customer delivery or after a major schedule integration. Duplicate-name checks fit naturally within a broader schedule-quality review. They also support a more disciplined process for teams learning how to build an Integrated Master Schedule.