Mentor Guide

Your role and access

The Mentor role on GAITS is designed for structured programmes in which projects are formally assigned mentors by programme leadership. If you have been assigned to a team, you are operating within that programme context — your assignment, your access, and your private workspace are all managed at the programme level, not by the teams themselves.

Mentors on GAITS are experienced practitioners — clinicians, commercial specialists, regulatory experts, or seasoned innovators — assigned by programme leadership to support one or more healthcare innovation teams as they work through the Healthcare Innovation Cycle.

The mentor role on GAITS is active and collaborative. You work directly with your teams in their Solution Sites — reviewing their progress, helping them calibrate their self-assessment, building structured plans, and tracking the work. You have Site Admin access to every site you are assigned to, which means you can read and write project content, create and manage Work Packages, and participate fully in the site alongside the team.

In addition to this team-facing work, you have a private workspace on each site — a separate channel shared with programme leadership and any co-mentors or advisors on that site. This is where you communicate with programme leadership, upload reports, and coordinate privately. The two channels are distinct: the site is where you work with the team; the workspace is where you work with the programme.

How you are assigned

Mentors are assigned to Solution Sites by programme leadership. You cannot add yourself to a site. When an assignment is made, the site appears in your account under My GAITS Sites. If you are expecting an assignment and the site is not showing, contact your programme leadership.

The self-assessment conversation

The first substantive step with a new team is reviewing their self-assessment — the picture the team has built of where their project currently stands, reflected in the Deliverable statuses they have recorded across their Solution Site. Before any planning can begin, you and the team need a shared, honest view of what has actually been completed and what has not.

This is not an audit. It is a guided conversation, conducted in the site, in which you help the team calibrate their understanding of what a completed Deliverable actually looks like in practice. Teams frequently overestimate their completeness — not from dishonesty, but because the bar for "done" is often higher than it appears, and because teams are naturally close to their own work.

What to look for

As you work through the self-assessment with the team, pay attention to:

• Deliverables marked complete with limited recorded evidence. A Deliverable that is checked off but supported only by a brief or generic note may not have been completed to the standard required. Ask the team to describe what they actually produced and compare that to what the Deliverable calls for.
• Uneven progress across dimensions. A team with strong technical progress but sparse commercial or regulatory work may have been focusing effort where it feels most natural rather than where it is most needed. The four-dimension view in GAITS makes these imbalances easy to see.
• Gaps that the team is not aware of. Some Deliverables are prerequisites for others that come later. A gap that seems minor now can become a blocker at a critical stage.

Recalibrating Deliverable status

If the conversation reveals that a Deliverable is less complete than its status indicates, update it in the site — this is part of your Site Admin role. The goal is a site that accurately reflects the project's true state, not an optimistic one. An accurate baseline is the only reliable foundation for a plan.

Identifying gaps and building a plan

With an accurate self-assessment in place, the next step is to look at the project as a whole — across all dimensions and stages — and identify the most significant gaps between where the project is and where it needs to be. This is a joint exercise: you bring the framework knowledge and the cross-team perspective; the team brings the detail of their specific project and context.

Identifying key gaps

Not all gaps are equally important. Focus the conversation on gaps that are:

• Blockers — work that cannot advance until this gap is addressed, either because later Deliverables depend on it or because the gap represents a fundamental unanswered question about the project's viability
• Stage-critical — gaps in Deliverables that define the team's current IML, which must be addressed before maturity can be demonstrated at that level
• High-leverage — gaps where a relatively contained piece of work would unlock significant progress across multiple Deliverables or dimensions

The gaps you identify together become the inputs to the plan. The plan itself is structured around Work Packages — defined collections of Deliverables that organise the work into coherent, manageable units.

Work Packages

A Work Package (WP) is a collection of Deliverables that the team will work through together as a unit. Work Packages are how the gap analysis becomes an actionable plan — each WP defines a specific body of work, groups the Deliverables it will address, and moves through a structured lifecycle from planning to completion.

The four stages of a Work Package

What makes a well-formed Work Package

Work Packages can contain Deliverables from any domain — clinical, regulatory, commercial, or technical. This is intentional: a WP is not confined to a single dimension. In many cases, the most useful WPs are those that group related work across dimensions — for example, commercial and clinical Deliverables that both depend on the same stakeholder discovery findings.

However, a well-formed WP should not span Deliverables that are too far apart in terms of Innovation Maturity Level. As a rule of thumb, Deliverables within a single WP should not be more than two IML steps apart. A WP that mixes early-stage and advanced Deliverables is difficult to plan, difficult to execute, and difficult to track — and usually signals that the scope needs to be split into two separate packages.

Serial, parallel, or both

Work Packages can be structured in sequence (one must be completed before the next begins), run in parallel (multiple active at the same time), or a combination of both. The right structure depends on the project's priorities and the team's capacity. Typically:

• Serial WPs are appropriate when later work genuinely depends on the outcomes of earlier work — for example, when a business model WP requires the output of a stakeholder discovery WP to proceed.
• Parallel WPs are appropriate when work across different dimensions can advance independently — for example, a regulatory pathway WP running alongside a technical feasibility WP.

Avoid creating too many parallel WPs simultaneously. A team actively working on more than two or three WPs at once is likely spread too thin to make meaningful progress on any of them.

Tracking active Work Packages

Once Work Packages are active, your regular mentoring work shifts to tracking progress — reviewing each active WP, checking on Deliverable completion, and providing support where the team is stuck or where quality needs to improve.

What to check on each active WP

For each active Work Package, review:

• Which Deliverables have been completed since your last review, and whether the quality of the recorded work meets the expected standard
• Which Deliverables are in progress and whether the team's approach is on track
• Whether the WP scope is still appropriate. If the team has encountered something that changes the picture — a pivot, new stakeholder insight, or a regulatory development — the WP may need to be revised or a new one created
• Whether the WP should be moved to Completed and the remaining work carried into a new planning cycle

When Deliverables stall

If a Deliverable within an active WP is not advancing, it is usually for one of a small number of reasons: the team does not have the access or resources to complete it, the team does not fully understand what is required, or the Deliverable is blocked by something that needs to be resolved first. Each of these calls for a different response — and identifying which it is quickly keeps the WP moving.

The private workspace

Each Solution Site you are assigned to has a private workspace — a separate area within the site that is shared between you, any co-mentors or advisors on that site, and your programme leadership. The team cannot see this workspace.

The private workspace serves a different purpose from the team-facing work you do in the site. It is a channel for programme-level communication — the place to:

• Share observations and assessments with programme leadership
• Upload progress reports or documentation required by the programme
• Coordinate with co-mentors or advisors assigned to the same team
• Flag concerns about the project that programme leadership needs to be aware of without the team being present
• Receive guidance or context from programme leadership about the programme's priorities or the team's background

Working with programme leadership

Programme leadership — the people responsible for managing the portfolio of Solution Sites — oversee all projects in the programme. They assigned you to your team, they can see your team's site and your private workspace, and they are accountable for the programme's outcomes across all projects. Your mentoring of individual teams feeds directly into their ability to manage the portfolio effectively.

The most useful thing you can do is keep the private workspace current — with honest assessments of where the project stands, what is working, what is not, and what you need from programme leadership. Programme leadership overseeing multiple teams relies on mentors to surface issues and risks at the project level that are not visible from the portfolio view alone.

The approval step in the Work Package lifecycle is also a natural touch-point with programme management. Depending on how the programme is configured, a member of programme leadership or a mentor may review and approve WPs before they become active. This gives programme leadership visibility into the team's planned work and an opportunity to shape it — use this as a moment to align on priorities, not just a procedural step to move through.