The intention is to move from the question at the start of the phase to the position at the end of the phase:
Can we validate our approach? → We’ve learned what works (and what doesn’t)
Page Navigation
Overview
The pilot is an end-to-end run through the workforce planning cycle generally with a limited area of the business.
The scope, roles and responsibilities, etc from the Discovery phase will be used, tested, and refined during the Pilot phase.
In terms of effort, running the Pilot is expected to take 4 weeks, +/- 2 weeks as part of a planning event. This excludes the preparation.
Preparation
Preparing to run a pilot has multiple activity streams that can be run in parallel:
TeamForm configuration for the Pilot
Engagement with the Pilot Group
Ongoing testing, refinement, improvements as we iterate and learn
Initial TeamForm Configuration
Is TeamForm effectively configured for the upcoming workforce planning cycle based on the agreed scope?
⏲️ Suggested time frame: at least 4 weeks before pilot launch
🧰 Who: TeamForm team with customer input and validation
Steps:
What’s in and out of scope could include:
Constraints, vacancies, secondments, daily rates, multi-quarter forecast (or just quarter ahead), hatted roles (significant secondary role), financial budgets, long-term leave, skills, personalised landing experience, leave/holidays, any external systems, dashboards
Workspace:
Workspace “active” for planning
Allocations:
Allocation projects: how many, time frames, what’s mandatory
Data:
Where we’ll get data for in-scope
Which integrations to bring in
What needs to be configured to bring in
What data is standard TeamForm keys
Tags
Attributes
Baseline:
Date and time for agreed upon baseline
Desired outcomes:
TeamForm product has been configured to effectively run the customer’s first workforce planning cycle
Engagement With Pilot Group
Are the people in the affected team structures effectively prepared for the upcoming workforce planning work and do they understand and appreciate the reasons for doing it?
⏲️ Suggested time frame: at least 4 weeks before pilot launch
🧰 Who: Customer team with input from TeamForm team
Steps:
Stakeholder socialising:
Run regular sessions to communicate with stakeholders what’s happening and how the process is changing
Find innovators/change champions/coalition of the willing
Find people who are unclear and/or fearful
Confirm users in the tool:
Establish first cut of personas
Communicate to stakeholders
Training
Training on the process and how to use the tool together
Desired outcomes:
Agreement on pilot launch date; typically as part of the next quarterly planning cycle
Anyone involved in pilot activities understands
why this matters
their roles and responsibilities
the business processes
the in-tool procedures
the timelines
the feedback and support mechanisms
Simulation / Test Run / Iteration
This is the pre-pilot pilot! Before launching with the pilot group, it’s important to test and verify both the business process and TeamForm configuration.
Early testing will happen naturally as part of the Preparation phase but it is often worth having a specific testing/simulation run phase to iron out any final kinks before launch.
Consider using the following progression (change and repeat each step as necessary until satisfied):
Internal testing: TeamForm tests the configuration and flow, if it doesn’t work for TeamForm then it won’t work for the customer.
Pilot group leads: test the configuration and flow with the strongest customer allies. They will bring in the organizational context lens.
Pilot group: simulate a run through the flow with the full pilot group. It is strongly recommend that customers do the talking and driving of TeamForm at this stage as it builds confidence and ownership in the process and supporting tool.
The outcome of the iterations is to achieve a confident go-ahead for the pilot launch.
Launch
The pilot launch is typically aligned with a quarterly business planning cycle. As part of the launch:
Communication plan: announce the pilot to the broader business planning community. They should understand the Problem Statement, who the participants in the pilot are, and when they’ll learn of outcomes. This should create excitement for the broader Rollout.
Training and awareness: ensure that all pilot participants are comfortable with the process developed in test runs.
Timelines: at the designated times in the planning process, run the pilot activities.
Feedback and support: it is likely that the process pilot will need some form of support / hyper care to help address quick / timely topics (a chat channel or wiki can be useful for capturing learnings and building up a knowledge base).
Celebrate: share the outcomes, lessons learned, and next steps as part of the quarterly planning wrap-up communications event.
Feedback and Assessment
What did we learn from the pilot?
Are there things we could improve or stop?
What was missing?
Did it meet the objectives?
The desired outcome of the pilot is permission to progress to a broader Rollout.
While continual feedback is captured during the pilot, this tends to be be at the “doing it” level. At the completion of the pilot, it is worth seeking more systemic feedback from participants for reflection at a holistic level.
Some suggestions for feedback capture:
was the Problem Statement addressed?
collect verbatim quotes - include names / roles
what could be improved in the next iteration
This feedback is used to inform the assessment and next steps:
Assess the pilot: was the effort worth the benefits for the pilot group and how will that translate to a broader Rollout?
Review processes and potential tool improvements: look for opportunities to streamline and improve the processes and how the tool can support them.
Review existing guidance / documentation: look for opportunities to streamline and improve the guidance.
Outcomes and Resources
Desired outcomes
Pilot group have completed the pilot
Pilot group have provided feedback regarding the process, tooling and overall experience
Stakeholders want to continue to Rollout