Critical Project Triage Worksheet

Use this worksheet when a project looks important enough that “we use it” is no longer a complete answer.

The goal is to understand how critical the project is, what support it may need, and what your organization should do next.

1. Name the project and its role

Start with a short description.

  • Project name:
  • Where it is used:
  • Internal owner:
  • External partners or vendors involved:
  • Public services, programs, or operations it supports:

Then describe the role it plays in plain language. What would someone outside the technical team need to know?

2. Understand criticality

Review what would happen if the project changed, slowed down, became unavailable, or had a major security issue.

  • Would service delivery be affected?
  • Would staff workflows be disrupted?
  • Would residents, clients, or partner organizations notice?
  • Is there a realistic alternative?
  • How long would replacement or mitigation take?
  • Is the project part of a regulated, sensitive, or high-trust environment?

Mark the project as low, moderate, high, or uncertain criticality.

3. Look at project health

Gather enough information to understand whether the project appears healthy for your use.

  • Are releases current?
  • Are issues and pull requests being reviewed?
  • Is there a security reporting process?
  • Are maintainers active and visible?
  • Is documentation usable?
  • Is governance clear?
  • Are there signs of maintainer overload?

Do not treat activity metrics as the whole story. A quiet project can be stable. A busy project can still be fragile.

4. Understand your current relationship

Name how your organization relates to the project today.

  • Do you only use it?
  • Have you modified it internally?
  • Have you reported issues?
  • Have you contributed fixes, documentation, or funding?
  • Do maintainers know your organization depends on it?
  • Are other agencies, nonprofits, vendors, or civic groups using it too?

This helps distinguish a normal dependency from something that may need participation or shared stewardship.

5. Identify the main concerns

Choose the concerns that need attention now.

  • Security or vulnerability response
  • License or policy clarity
  • Maintainer capacity
  • Documentation or usability
  • Roadmap uncertainty
  • Internal ownership
  • Vendor dependency
  • Data, privacy, or AI-related questions
  • Lack of shared governance
  • Unclear replacement options

Write down the top one to three concerns. More than that usually means the next step needs to be discovery, not immediate resolution.

6. Choose a practical next step

Pick the smallest useful action.

Possible next steps:

  • Assign an internal owner.
  • Complete a dependency or policy review.
  • Open a maintainer conversation.
  • Contribute a small fix or documentation improvement.
  • Explore sponsorship or support.
  • Convene other users.
  • Plan a small pilot or replacement test.
  • Document an exception or risk decision.

The next step should be specific enough that someone can do it within a few weeks.

7. Decide when to revisit

Critical dependencies should not disappear after one review.

Set:

  • Review date:
  • Internal owner:
  • Trigger for earlier review:
  • Notes to preserve for future decisions:

When to ask for help

Bring in support when a dependency is important, the health picture is mixed, or the project may need contribution, sponsorship, or shared stewardship rather than a one-time review.

Next step: Talk through a first step.