Unit 14: Collaborative Project Planning and Monitoring using GitHub and Asana

I. Orientation — Collaborative Planning as a Continuous Control Process

Collaborative software project management coordinates requirements, source code, schedules, responsibilities, and progress through a shared, continuously updated system. GitHub primarily connects work items to version-controlled code, while Asana organizes tasks, dependencies, deadlines, and resource capacity.

• Governing principle: A project should maintain traceability from a requirement or task to its owner, implementation, review, and completion evidence.
• Shared visibility: Repositories, issue boards, project timelines, and status reports provide a common view of current work.
• Single source of truth: Team members should update work in the designated platform rather than maintain disconnected personal records.
• Incremental planning: Large deliverables are divided into milestones, issues, tasks, and subtasks that can be estimated and monitored.
• Controlled change: Git branches, commits, pull requests, and merges preserve history while allowing parallel development.
• Accountability: Assignees identify responsible people, while due dates and dependencies establish time-related expectations.
• Feedback cycle: Planning creates a baseline; actual progress, blockers, and workload data are then used to revise that plan.
• Tool distinction:
  1. GitHub: Best suited to code-centric collaboration, requirement tracking near development, and release management.
  2. Asana: Best suited to broader task scheduling, cross-functional coordination, timelines, and workload balancing.

II. GitHub-Based Project Coordination — Connecting Requirements, Work, and Code

GitHub combines Git repository hosting with issues, pull requests, milestones, labels, and project views, allowing project activity to remain linked to the software artifacts it produces.

A. GitHub for Software Project Management

GitHub supports project management by making planned work and implementation history visible in one collaborative environment.

• Core artifacts: Repositories contain code; issues record work; pull requests propose changes; releases identify distributable versions.
• Workflow: A common sequence is Issue → Branch → Commits → Pull Request → Review → Merge → Release.
• GitHub Projects: Table, board, and roadmap views can organize issues and pull requests using fields such as status, iteration, priority, or estimate.
• Collaboration controls: Repository roles, protected branches, required reviews, and automated checks define how changes are accepted.
• Automation: GitHub Actions can run tests or deployments after events such as a push or pull-request update.
• Limitation: GitHub is code-centered; financial planning, detailed resource forecasting, and organization-wide scheduling may require another system.

B. Requirement tracking using GitHub Issues

GitHub Issues can represent requirements, defects, user stories, technical tasks, or change requests throughout their life cycle.

• Issue content: A useful issue contains a concise title, description, acceptance criteria, context, and relevant links.
• User-story form: A requirement may be written as “As a customer, I want password recovery so that I can regain access.”
• Acceptance criteria: Checklists convert broad expectations into verifiable conditions, such as sending a reset link that expires after a defined period.
• Ownership and discussion: Assignees show responsibility, while comments preserve clarifications and design decisions.
• Traceability: Referencing #42 links work to issue 42; keywords such as Closes #42 in a merged pull request can close it automatically.
• Templates and forms: Issue templates standardize bug reports or feature requests by requesting fields such as reproduction steps, expected result, and environment.
• Control practice: Requirements should be refined, prioritized, reviewed, and closed only when their acceptance criteria are satisfied.

C. Creating and managing GitHub repositories

A GitHub repository is the managed project container for source files, Git history, documentation, permissions, and collaboration settings.

• Creation choices: A repository requires a name, visibility level—public or private—and may be initialized with a README, .gitignore, and license.
• Local connection: A remote repository can be copied with:
  
  BASH

    git clone https://github.com/example/team-app.git
    cd team-app

• Basic organization: README.md explains setup and use; CONTRIBUTING.md defines contribution rules; source and test directories separate project artifacts.
• Access management: Owners assign individual or team permissions such as read, triage, write, maintain, or admin.
• Repository settings: Branch protection can prohibit direct changes to the main branch and require passing checks or approvals.
• Maintenance: Teams archive obsolete repositories, manage releases and tags, review security alerts, and remove unused access.

D. Milestones and labels for task categorization

Milestones group issues and pull requests toward a target, while labels classify them across multiple dimensions.

• Milestones: A milestone may represent Version 2.0, Sprint 6, or a delivery phase, with an optional description and due date.
• Progress measurement: GitHub calculates milestone completion from the proportion of associated open and closed items.
• Label dimensions:
  • Type: bug, feature, or documentation.
  • Priority: priority: high or priority: low.
  • Status or area: blocked, frontend, or security.
• Filtering: A manager can filter for open issues carrying both bug and priority: high.
• Naming discipline: A small, documented label scheme prevents overlapping labels such as urgent, critical, and highest from becoming ambiguous.
• Planning distinction: A label classifies an item; a milestone connects it to a specific delivery objective.

III. Git Version Control — Controlled Parallel Development

Git records snapshots of project files and allows developers to work independently before integrating approved changes.

A. Version control basics: commit, branch, merge

Commits preserve meaningful states, branches isolate lines of work, and merges combine their histories.

• Commit: A commit records staged changes with author, timestamp, message, and a unique hash.
  
  BASH

    git add src/login.py
    git commit -m "Validate expired reset tokens"

  
  git add stages the file, while git commit stores the staged snapshot locally.
• Branch: A branch is a movable reference to a sequence of commits, commonly created for one issue or feature.
  
  BASH

    git switch -c feature/password-reset

• Merge: Integration incorporates changes from one branch into another.
  
  BASH

    git switch main
    git merge feature/password-reset

• Parallel-work benefit: One developer can modify authentication while another updates reporting without placing unfinished code on main.
• Merge conflict: A conflict occurs when Git cannot automatically reconcile competing edits; the developer edits the marked file, stages it, and completes the merge.
• Good practice: Commits should be small and logically complete, messages should describe intent, and branches should be reviewed through pull requests before merging.
• Remote synchronization: git push publishes local commits, while git pull retrieves and integrates remote changes.

IV. Asana-Based Planning and Scheduling — Coordinating Work, Time, and Capacity

Asana is a work-management platform in which teams arrange projects into tasks, assign ownership, establish dependencies, and monitor delivery through visual planning views.

A. Asana for Task Planning and Scheduling

Asana converts project objectives into organized work that can be assigned, dated, prioritized, and tracked.

• Planning hierarchy: An organization or workspace contains teams and projects; projects contain tasks, which may contain subtasks.
• Project views: List, board, calendar, and timeline views display the same work from different planning perspectives.
• Custom fields: Fields such as priority, risk, effort, or stage enable consistent filtering and reporting.
• Workflow use: Sections or board columns may represent Backlog, In Progress, Review, and Complete.
• Integration value: GitHub activity can be linked to Asana tasks so that scheduling context and development evidence remain connected.
• Plan awareness: Advanced views and controls depend on the organization’s Asana subscription.

B. Creating projects and workspaces in Asana

Workspaces establish the collaborative boundary, while projects organize work directed toward a defined result.

• Workspace or organization: A workspace supports groups of users, whereas an organization is generally associated with a shared company email domain.
• Project creation: A project may start blank or from a template and can use list, board, calendar, or timeline as its default view.
• Essential settings: Managers define the project name, purpose, privacy, members, and notification preferences.
• Structural choice: Sections can represent phases such as Analysis, Development, Testing, and Deployment.
• Governance: Membership should follow least-privilege access, especially where projects contain confidential client or product information.

C. Defining tasks, subtasks, and dependencies

Effective task decomposition turns a broad deliverable into actionable, logically ordered units of work.

• Task definition: A task should express a clear action and outcome, such as “Implement password-reset endpoint.”
• Task details: Descriptions, attachments, comments, custom fields, and acceptance criteria provide execution context.
• Subtasks: Subtasks divide work—for example, endpoint implementation may contain token generation, email integration, and automated testing.
• Dependencies: A dependency states that one task is blocked by or waiting on another; system testing may wait for implementation.
• Granularity rule: Subtasks should be independently trackable but not so small that updating them costs more than performing them.
• Scheduling effect: Delayed predecessor tasks can threaten successor dates, making dependencies important for identifying schedule risk.

D. Assigning responsibilities and setting deadlines

Assignments establish ownership, while deadlines convert planned work into time-bound commitments.

• Single accountable owner: Each task normally has one assignee, even when several collaborators contribute.
• Supporting participants: Collaborators receive updates and provide input without weakening ownership.
• Due dates: A due date specifies expected completion; start dates show when work should begin.
• Priority balance: Managers should consider urgency, skill, availability, and dependency impact before assigning tasks.
• Deadline quality: Dates should reflect effort and capacity rather than arbitrary targets.
• Accountability practice: If a deadline becomes unrealistic, the owner should update the task, explain the cause, and communicate the revised forecast.

E. Timeline view for schedule tracking

Timeline view presents dated tasks as horizontal bars, making sequence, duration, overlap, and dependencies visible.

• Schedule representation: A task’s start and due dates determine its position and length on the timeline.
• Dependency visibility: Connecting dependent tasks reveals whether one delay may affect later activities.
• Adjustment: Dragging or resizing task bars supports scenario planning when dates change.
• Critical attention: Long dependency chains and tasks with little scheduling flexibility deserve close monitoring.
• Baseline limitation: A visually valid timeline is not automatically realistic; task estimates and resource availability must also be checked.

F. Workload view for resource utilization

Workload view compares assigned work with team capacity to reveal over-allocation and underutilization.

• Capacity basis: Effort may be represented by task count or a numeric custom field such as estimated hours or points.
• Interpretation: If a developer has 40 hours of capacity but receives 52 estimated hours, the planned utilization is 52 ÷ 40 × 100 = 130%.
• Balancing action: Managers may reassign tasks, reduce scope, split work, or move dates to remove overload.
• Forward planning: Viewing capacity across future weeks identifies conflicts before deadlines are missed.
• Data limitation: Workload results are only reliable when assignments, dates, effort values, and capacity settings remain current.

G. Monitoring progress and status updates

Monitoring compares current execution with planned scope, schedule, ownership, and capacity so that corrective action can occur early.

• Task-level signals: Completion state, comments, due-date changes, blockers, and custom fields show operational progress.
• Project status: Periodic updates commonly indicate whether work is on track, at risk, or off track and explain major achievements and obstacles.
• Quantitative measures: Teams may track completed tasks, overdue tasks, milestone progress, cycle time, or remaining estimated effort.
• Update rhythm: Owners update tasks during work, while project managers publish status reports at a regular cadence such as weekly.
• Exception management: Attention should focus on blocked items, overdue dependencies, unreviewed pull requests, and overloaded contributors.
• Corrective actions: Responses include reprioritizing scope, reallocating work, revising dates, resolving dependencies, or escalating decisions.
• Cross-tool traceability: An Asana task linked to a GitHub issue or pull request allows schedule status to be verified against concrete implementation activity.