Portfolio Manager Guide

The four portfolio roles

Access to a Portfolio Site on GAITS is organised around four distinct roles. Each role has a defined scope of access — from read-only visibility to full management and site creation rights. Understanding these roles is the foundation for managing who can see and do what within your programme.

The portfolio dashboard

Portfolio Members, Admins, and Managers all have access to a portfolio-level dashboard that provides a view across all Solution Sites in the portfolio. This is the primary tool for programme-level oversight — it lets you see where every project stands without having to open each site individually.

The portfolio dashboard shows:

• Project progress across all sites — maturity levels by dimension (clinical, regulatory, commercial, technical) displayed in a sortable table, so you can compare projects and identify which are advancing well and which need attention
• Deliverable and Work Package status — a summary view of active WPs and overall Deliverable completion across the portfolio
• Drill-down access — select any project to open its full Solution Site, with the same access you would have within the site directly

The dashboard is designed to answer the question every programme manager asks: where are my projects, and which ones need my attention right now? Sorting by dimension or maturity level quickly surfaces the outliers — both the projects that are ahead of schedule and those that are falling behind.

Creating Solution Sites

A Solution Site is the private project workspace for a healthcare innovation team. When you create a site, you make two foundational decisions that shape everything the team will work on:

Assigning a solution type

GAITS supports six solution types: MedTech, Digital Health, IVDs, Diagnostics, Biomarker Diagnostics, and Therapeutics. When you create a site, you assign the solution type for that project. This determines the Deliverable set the team will work through — many Deliverables are shared across types, while others are specific to the clinical, regulatory, and commercial requirements of each.

Choose the solution type carefully — changing it later is a portfolio-level action that resets the Deliverable configuration for the site. If a project spans multiple types or does not fit neatly into a single category, choose the type that best reflects the primary regulatory and commercial pathway the team will follow.

Inviting the team

After creating a site, you will typically invite the first team member with Site Admin access — this is usually the project lead, who then invites the rest of the team. Alternatively, you can invite team members directly from within the site. You can also assign a mentor to the site at the time of creation or at any point afterwards.

Managing portfolio members

Portfolio Admins and Portfolio Managers can add and manage members at the portfolio level. Portfolio-level membership is distinct from site-level membership — a person can have a portfolio role, a site role, or both, depending on what they need to do within the programme.

Choosing the right portfolio role

When adding someone to the portfolio, the choice of role should reflect their relationship to the programme:

• Portfolio Viewer for funders, oversight bodies, or any external stakeholder who needs visibility into programme progress without making changes or engaging directly with teams.
• Portfolio Member for lead mentors, specialists, or advisors who need to engage across multiple or all Solution Sites — including access to the Mentor tab. In the CRAASH programme, for example, lead mentors hold Portfolio Member access so they can review and contribute to any site in the portfolio.
• Portfolio Admin for programme staff who need to manage day-to-day membership and mentor assignments but do not need to create sites.
• Portfolio Manager for those with full programme management responsibility, including the creation of new Solution Sites.

Portfolio roles and site roles

A Portfolio Member's access travels with them across all sites — they do not need to be individually added to each Solution Site. A person with only a site-level role (Team Member, Mentor) does not have portfolio-level access and cannot see other sites in the portfolio. These two access systems work independently, giving you precise control over who sees what.

Assigning mentors to teams

Portfolio Admins and Portfolio Managers can assign mentors to individual Solution Sites. A mentor assigned this way receives site-level access to that specific team's site — including Mentor tab access on that site — without needing a portfolio-level role.

When assigning a mentor, consider:

• Match by specialism. Where possible, assign mentors whose expertise corresponds to the team's most critical current gaps — a regulatory specialist to a team approaching a significant regulatory decision, a commercial expert to a team building out its business model.
• Timing. Mentor assignment is most effective when it coincides with the team being ready to engage — typically after the initial self-assessment has been completed and the team has a functioning site with some recorded progress. An assignment made before the team is ready can result in an underused mentor.
• Multiple mentors. A team can have more than one mentor. Where a project spans domains that require different expertise, two mentors with complementary specialisms can be more effective than one generalist. Both will share the same Mentor tab on that site.

Sub-portfolios

Sub-portfolios allow you to organise Solution Sites into groups within a larger portfolio — and to assign portfolio roles at the sub-portfolio level rather than across the whole portfolio. This enables hierarchical management structures that reflect how your programme is actually organised.

Common uses for sub-portfolios include:

• Cohort management. Each programme cohort runs as a sub-portfolio. A cohort lead can be given Portfolio Admin access to their cohort without having visibility into other cohorts.
• Organisational divisions. A programme spanning multiple institutions or geographies can use sub-portfolios to reflect that structure, with local managers overseeing their own sub-portfolio while the programme director maintains visibility across all of them.
• Access control for funders. A funder with an interest in a specific cohort or category of projects can be given Portfolio Viewer access to the relevant sub-portfolio without seeing the full programme.

Portfolio roles cascade: a Portfolio Manager at the top level has the same access to all sub-portfolios within their portfolio. Sub-portfolio roles do not cascade upward — a person with Portfolio Admin access to a sub-portfolio does not have access to sites outside that sub-portfolio.

The mentor workspace

As a Portfolio Admin or Portfolio Manager, you have access to the mentor workspace on every Solution Site in your portfolio. This is the private channel shared between you, the assigned mentors, and any Portfolio Members — it is not visible to the teams.

The mentor workspace is where mentors record their observations, upload reports, and coordinate with you on the progress of individual teams. Reading it regularly is one of the most efficient ways to maintain an accurate picture of your portfolio without having to review every Deliverable in every site.

What to look for

The most useful mentor workspaces contain timely, specific observations — connected to particular Deliverables, Work Packages, or stages — that tell you something you could not easily read from the project dashboard alone. When reviewing a workspace, look for:

• Teams where the mentor has flagged a risk or concern that warrants your direct attention
• Teams where a Work Package has stalled and the mentor needs your input or a decision to move forward
• Teams that are performing well and may be ready for the next stage of support — or for reduced mentoring intensity
• Patterns across multiple teams that may point to a programme-level issue rather than a project-specific one

Adding your own observations

The workspace is not read-only for you. You can add your own notes — context about the team, programme-level decisions that affect the project, or observations from your own review of the site. This is particularly useful for ensuring continuity when programme management changes hands or when bringing a co-administrator up to speed.

Work Package approval

Work Packages move from Submitted to Active through an approval step. Depending on how your programme is configured, this approval may rest with you as portfolio manager, with the assigned mentor, or with both. The approval step exists to give programme leadership visibility and input into the work teams are planning before it begins.

What to review before approving

When a Work Package is submitted for approval, review it against the following:

• Scope coherence. Does the WP group Deliverables that logically belong together? A well-formed WP should not span more than approximately two IML levels, and its Deliverables should form a coherent body of work rather than a miscellaneous collection.
• Sequencing. Is the WP appropriately positioned relative to other active or planned WPs? If it depends on outputs from a WP that is not yet complete, activating it prematurely will leave the team blocked.
• Capacity. Does the team have the resources to execute this WP alongside any other currently active packages? A team with too many parallel WPs will struggle to make meaningful progress on any of them.
• Alignment with programme priorities. Does the work the WP describes reflect the right priorities at this stage of the project? The approval step is also an opportunity to redirect effort if the team's focus is misaligned.

If a WP needs revision before it can be approved, return it to Planning status with clear notes in the mentor workspace explaining what needs to change. This keeps the feedback visible to both the mentor and the team's Site Admin without disrupting the team's broader workflow.

SWOT notes

GAITS provides a SWOT (Strengths, Weaknesses, Opportunities, Threats) notes space for each Solution Site within the portfolio dashboard. SWOT notes are visible to all portfolio roles — Viewer, Member, Admin, and Manager — and to site-level mentors. They are not visible to the team. This makes them a useful shared space for anyone involved in overseeing or supporting a project, while keeping the assessment private from the team itself.

SWOT notes are particularly useful for:

• Pre-meeting preparation. Summarising your current read of a project before a mentor review meeting or a team presentation ensures you engage with the right questions rather than starting from scratch each time.
• Portfolio-wide comparison. Noting the relative strengths and risks of each project in a consistent format makes it easier to allocate mentoring resource, prioritise support, and identify which projects warrant closer attention at any given point in the programme.
• Longitudinal tracking. Because SWOT notes persist across the life of the site, they build into a record of how your assessment of the project has evolved — which is useful both for programme learning and for reporting to funders or oversight bodies.