Agree the pilot and the people who will decide
Choose a project with a named manager, upcoming milestone and meaningful stage review. Set a practical success criterion: the team can prepare the required evidence, the reviewer can approve or return the stage, and the manager can find the resulting decision. Use demonstration or anonymised information until your organisation has agreed its data-handling arrangements.
Assign responsibility for workspace configuration, delivery, PMO review and finance where relevant. AEVU has Owner, Admin, PMO, Manager and Finance roles, plus custom roles. Review the actual permission matrix rather than assuming a role name grants every action. Stage submission, gate approval and document approval are distinct permissions.
Create the project with the right delivery profile
Choose a blank project or an enabled solution-pack starter. A client engagement, internal initiative and funded initiative have different commercial contexts. Internal and funded work can carry a planned budget without a client invoice; client engagements use the client billing workflow. Add the manager, team, dates and portfolio that the pilot actually needs.
A starter recommends a delivery profile and method and offers role and risk prompts for review. It does not assign people, create assessed risks or build a complete delivery plan. The project’s folders, document placeholders and gate requirements come from its applicable document template. Review those requirements, then plan the milestones and tasks with the project manager.
Bring over only records the import supports
AEVU’s spreadsheet import accepts CSV or XLSX for risks, issues and new draft projects. Risks and issues go into a selected project; draft projects go into the workspace. Map columns, inspect row validation, fix or exclude problem rows, then commit and inspect the job result. Start with a small sample before using a larger file.
Google Sheets is another source when the Google capability and consent are configured. Plan limits and permissions still apply. These imports are not a complete migration of task hierarchies, document binaries, approval history or every field in a legacy system. Add the pilot’s plan and evidence through their supported workflows, and evaluate any wider migration separately.
Exercise planning, risks and document evidence
Add the milestones, task owners, dependencies and resource allocations needed for the next review. Check the project workload and Resource utilisation report for booking pressure. Record a real risk and response owner, and an issue if one is already affecting delivery. These records give the review something concrete to act on.
Provide the required documents in their project folders and test document review where it is needed. External SharePoint, OneDrive and Google Drive links remain references, not evidence satisfying a mandatory document requirement. Test access as the manager and reviewer so that the correct people can see the project, evidence and decisions.
Complete the decision loop before expanding
Check the stage’s Requirements panel, resolve mandatory blockers, submit the stage and review it from Actions. Test a return for modification as well as approval: the team should be able to find the reason, correct the source record and submit again. Ari’s optional readiness explanation can help describe the checklist, but the authorized reviewer makes the decision.
Finish by checking the project in the register, Exceptions and relevant reports. Confirm that the team understands the period, filters and permission scope behind the figures. Record any configuration or process changes needed for the next project. Expand once the pilot demonstrates that people can own the work, supply the evidence and follow the decision through; account creation alone is not a completed rollout.