Hello brain trust. I’m working in a digital transformation team alongside a cohort of PMs and CMs. Earlier this week we welcomed few new members into our team and I was advised one of them would be reporting to me as a project support officer. I haven’t had a direct report in my role. The staff member is part time and works remotely. They are new to the PM discipline and haven’t had any prior exposure. Part of my responsibility is introducing and uplifting their PM capabilities. I thought a good approach would be a combination of training and hands on activities. So I signed them up for a PM basics course and planning to slowly bring them along into my own projects, probably starting with designing and maintaining a risk log as the first step. Any tips or feedback to improve the journey for them?
The onboarding strategy for this remote, part-time, zero-experience professional centers on a seamless, five-step transition: environment setup, historical case analysis, passive meeting observation, automated risk tracking, and a final alignment wrap-up. By removing all immediate delivery and technical pressures, the new hire can execute systematically. Throughout the week, they will configure their access, maintain a "terminology log" for unfamiliar technical jargon, shadow team syncs, and serve as a tactical follow-up driver by prompting owners for status updates on three pre-existing, low-risk log entries. The week concludes with a brief 1-on-1 video sync to review their log updates and decode the accumulated industry terminology. This structured framework effectively eliminates cross-industry anxiety, drives immediate organizational value for a part-time contributor, and establishes a robust, highly scalable managerial feedback loop from day one. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Your combination of foundational training and hands-on experience sounds like a strong starting point, Meysam. I would make the progression capability-based rather than simply time-based.
With the risk log, for example, I might first let them observe how risks are identified, discussed and used in real project decisions. They could then contribute to an existing log, maintain it with guidance, understand the reasoning behind updates, and progressively perform the work with greater autonomy as their capability develops.
Because they are remote and part-time, I would also make contextual learning and feedback particularly deliberate. They may naturally miss some of the informal learning that happens simply by being around a project team.
Perhaps the most important principle is to teach the "why" alongside the "how." The objective is not simply to teach them how to maintain project artifacts, but to develop the knowledge to understand the work, the practical capability to perform it effectively, and the professional judgment and behaviors to act appropriately within their role.
That way, practice, feedback and reflection progressively build the maturity needed to perform the role well, while responsibility and autonomy grow within clear boundaries and decision authority remains explicit.
...
1 reply by Meysam Davoody
Aug 13, 2026 10:39 PM
Meysam Davoody
...
Thanks Luis. I do like your suggestion to explain the why as well as the how. That way they wont just copy the process, they understand the reasoning behind it and make the right tweaks in different situations. I take a mental note of that.
Sounds like a good stretch activity for you! I'm not sure I'd give them ongoing maintenance of the risk register as that is a critical artifact so unless you are ready to also keep an eye on it regularly I'd look for something different.
What you will want to do is make sure that they understand your approach to managing your projects, what you'd consider your standard project control book to be, go over the normal schedule of administrative activities, and work with them to identify which would be a good fit.
They should definitely be with you at every key stakeholder meeting and take time after each meeting to debrief with them. While initially it may just be you educating them on the outcomes, over time, you may find that they have insights that you missed.
When the relationship works well, it is magic. The PCO/PA becomes confident in their abilities to take on a small project of their own, and the PM is comfortable that they can focus on higher value activities and can step away for a few days from the project if needed without worrying that everything will fall over.
Good luck!
Kiron
...
1 reply by Meysam Davoody
Aug 13, 2026 11:01 PM
Meysam Davoody
...
Thanks Kiron. Yes, definitely feels like a good stretch task for myself. I use excel to log and monitor project risks. I was thinking to use the register log of one of the recent projects I've delivered as a practise. I can give them an overview of the project, explain how we identify and log risks, then walk them through an earlier version of the register with all risks open and elaborate how and why they were closed off. How does that sound as a starting point? I do like your idea they may notice things I have missed, that's extra bonus.
Your combination of foundational training and hands-on experience sounds like a strong starting point, Meysam. I would make the progression capability-based rather than simply time-based.
With the risk log, for example, I might first let them observe how risks are identified, discussed and used in real project decisions. They could then contribute to an existing log, maintain it with guidance, understand the reasoning behind updates, and progressively perform the work with greater autonomy as their capability develops.
Because they are remote and part-time, I would also make contextual learning and feedback particularly deliberate. They may naturally miss some of the informal learning that happens simply by being around a project team.
Perhaps the most important principle is to teach the "why" alongside the "how." The objective is not simply to teach them how to maintain project artifacts, but to develop the knowledge to understand the work, the practical capability to perform it effectively, and the professional judgment and behaviors to act appropriately within their role.
That way, practice, feedback and reflection progressively build the maturity needed to perform the role well, while responsibility and autonomy grow within clear boundaries and decision authority remains explicit.
Thanks Luis. I do like your suggestion to explain the why as well as the how. That way they wont just copy the process, they understand the reasoning behind it and make the right tweaks in different situations. I take a mental note of that. Saving Changes...
Sounds like a good stretch activity for you! I'm not sure I'd give them ongoing maintenance of the risk register as that is a critical artifact so unless you are ready to also keep an eye on it regularly I'd look for something different.
What you will want to do is make sure that they understand your approach to managing your projects, what you'd consider your standard project control book to be, go over the normal schedule of administrative activities, and work with them to identify which would be a good fit.
They should definitely be with you at every key stakeholder meeting and take time after each meeting to debrief with them. While initially it may just be you educating them on the outcomes, over time, you may find that they have insights that you missed.
When the relationship works well, it is magic. The PCO/PA becomes confident in their abilities to take on a small project of their own, and the PM is comfortable that they can focus on higher value activities and can step away for a few days from the project if needed without worrying that everything will fall over.
Good luck!
Kiron
Thanks Kiron. Yes, definitely feels like a good stretch task for myself. I use excel to log and monitor project risks. I was thinking to use the register log of one of the recent projects I've delivered as a practise. I can give them an overview of the project, explain how we identify and log risks, then walk them through an earlier version of the register with all risks open and elaborate how and why they were closed off. How does that sound as a starting point? I do like your idea they may notice things I have missed, that's extra bonus.
...
1 reply by Kiron Bondale
Aug 14, 2026 7:31 AM
Kiron Bondale
...
Meysam -
My concern with having them primarily "owning" the risk register is around accuracy & quality of the contents. Risk is uncertainty that matters as Dr. Hillson is fond of saying and if the content in the register does not matter to key risk stakeholders, the effort spent on the discipline will be wasted.
As long as you are reviewing the content of the register and ensuring it is current and well stated, that's fine.
Thanks Kiron. Yes, definitely feels like a good stretch task for myself. I use excel to log and monitor project risks. I was thinking to use the register log of one of the recent projects I've delivered as a practise. I can give them an overview of the project, explain how we identify and log risks, then walk them through an earlier version of the register with all risks open and elaborate how and why they were closed off. How does that sound as a starting point? I do like your idea they may notice things I have missed, that's extra bonus.
Meysam -
My concern with having them primarily "owning" the risk register is around accuracy & quality of the contents. Risk is uncertainty that matters as Dr. Hillson is fond of saying and if the content in the register does not matter to key risk stakeholders, the effort spent on the discipline will be wasted.
As long as you are reviewing the content of the register and ensuring it is current and well stated, that's fine.
