In this blog we make the case for ‘project onboarding processes’ to support employees at all levels that have been tasked with working on a project for the first time.
We explore the aspects of project documentation, terminology and software (for which there is rarely a soft launch), as well as socializing the business case and expected project outcome to those working as part of the project team.
Onboarding – the organizational one and done
Onboarding is “the process in which new employees gain the knowledge and skills they need to become effective members of an organization” – a welcome antidote to those ‘first-day’ feelings when you join an organization in a fog of disorientation around the things that went before: culture, language, technology and processes now a crapshoot, as you transition from leader to learner.
But, given the relentless pace of post-pandemic transformation projects, aren’t we all on a constant trajectory of change, discovery and learning?
The case for change (for change’s sake)
Let’s return to the example of projects, which can feel very much like the proverbial rabbit hole for the uninitiated. Transformation projects will inevitably require participation from employees who have a functional role in the business (their ‘day job’) relative to this project, including a senior or leadership representative who may be the project sponsor or lead. It’s entirely possible that all these team participants will have had no previous experience of working as part of a project, which makes for a very steep learning curve.
To put this into context, there are at least 55 project management terms, a minimum of 9 essential project documents, 17 project management methodologies and at least 10 variations of project management tools/software (excluding project-focused apps that form part of the M365 suite).
Stages in a project and what the team needs to know
Let’s identify some key processes in the project lifecycle that will necessitate an understanding of project terminology across the entire team, the purpose of the project documents and the use of that project software, as well as what is and isn’t generally shared with the broader project team (and whether it should be).
According to the PMBOKⓇ Guide, projects have stages broadly representing Initiation, Planning, Execution and Closure.
Initiation relates to understanding why the project is required, the work that needs to be done to deliver the desired outcome, and forms the Why? What? When? and How? of the project.
Part of this stage involves analysis of current resources, budgetary implications and a clear statement on the return on investment (ROI). In PRINCE2 this analysis will catalyse the business case which “gathers the information to allow the management to judge if a project is desirable, viable and achievable”. This document is continually updated at the end of each stage to ensure that the project is still on course to deliver ROI, within budget and to the agreed timelines.
It’s worth mentioning here that the business case is rarely shared with participants and is instead managed and updated by the upper echelons of the project team or committee, often with little contextual clarification at the grassroots level.
Since the business case contains all the benefits the project will deliver, as well as detailed information on how users will be able to make better use of the product or deliverable, it feels somewhat counterproductive to keep the outputs of this document under wraps when knowing why you’re doing something will make the task so much more fulfilling!
The planning stage does what it says on the tin, including defining the scope and activities of the project, identifying key stakeholders and creating a communications plan. It’s at this stage that project neophytes are likely to be more fully involved and will hear terms such as ‘Stakeholder RACI’ (the document which categorizes the stakeholders by virtue of their project participation, breaking them down into ‘responsible’, ‘accountable’, ‘consulted’ and ‘informed’).
What all the communications team should know
If you’re part of the communications team, whose role it is to ensure that the project messaging is timely, targeted and relevant to your audience, a contextual understanding of the document’s purpose and language is critical.
Requirements gathering also forms part of the planning process and is reliant on technology to document the outputs of any brainstorming sessions, particularly as this exercise will likely involve globally dispersed colleagues.
Why literacy in project tech matters
If you’ve never used a Klaxoon or Miro board, these are essentially virtual whiteboards that people can log into simultaneously, where ideas and key themes are collected onto coloured post-it notes, which can be themed by the facilitator.
Spoiler! This is not always an intuitive process, and dragging and dropping the notes can be hit and miss, not to mention the unavoidable task of increasing the font size of your text. And this is all before you can produce a single post-it note. As with many things that have no dress rehearsal, it’s easy when you know how; it just so happens that a lot of people don’t (and why would they?).
Atlassian describes execution as: “rolling up your sleeves and taking action on everything you outlined in your project plan” (if you’re fortunate enough to have laid eyes on it).
Once the project timelines have been agreed, participants will be assigned tasks for which they are responsible in a mapping tool such as Microsoft Planner, Jira, Asana.
From theoretical to functional (and more technology)
In Microsoft Planner, buckets that form a theme (e.g. data cleanse) are created. In these buckets (or themes), multiple tasks can be created and assigned. These will usually include a completion date, section to update progress or flag issues, as well as the ability to add one or more assignee (who will be notified of their task via email).
As with the virtual whiteboard, the expectation will be to hit the ground running with this software as time-sensitive activities are planned and distributed. However, additional (and useful) functionality in Microsoft Planner, such as downloading an excerpt of the tasks into an Excel spreadsheet, are not particularly intuitive and demand a reasonable knowledge of its features.
Navigating project lingo
Imagine planning an exotic, foreign holiday only to discover that nobody is speaking the same language as you. Every conversation is fraught with ambiguity and the potential of your experience diluted. So it is in projects, when acronyms and phraseology get bandied around with the assumption that everyone is following the dialogue.
Without proper clarity, the increased use of project language in meetings, often abbreviated to acronyms like SOW (statement of work), POC (proof of concept), CAB (Change Advisory Board), will leave a gaping hole in the context of what is being communicated.
And why a lack of clarity is a project risk
Team members unwilling to share any confusion about the terminology used will remain oblivious to what it means for the project (and potentially their outputs), which is, in effect, a costly risk to the project that won’t have been factored in. And this will be a problem for anyone unfamiliar to the world of projects, from the sponsor down to the grassroots team members.
Mitigating execution gaps with emotional investment
There is a concession by Atlassian that ‘execution gaps’ (the result of limited resources and a tendency to think of a project ‘in a vacuum’ without any conflicting priorities) will impede the project’s progress. You might argue that if project participants are equipped with all the tools and learning to navigate a project, they would also share a sense of personal investment, rather than see their part in the project as a baffling, nonsensical chore to be slotted in with more appealing, competing priorities.
A clear case for transparency
This highlights the importance of transparency in a project team, when “the project manager and key stakeholders are the ones with access to information not readily accessible to everyone and is on a need-to-know basis. This lack of transparency can cause distrust and resentment among team members.”
Transparency fosters: “honesty, openness, and trust in the team. It makes the team work better as a single, cohesive unit. Project team members are likely to trust each other when they are supported and encouraged to understand what the team is doing as a whole.”
Transparency around terminology, documentation and project software are also critical enablers for high-profile/senior project members who will be expected to have a detailed understanding of the project status and responsibility for making key decisions.
The Hackman Model of Team Effectiveness outlines five conditions which enable teams to work more effectively together, which include: “having a supportive context within the organization that allows the team to work efficiently” and “having expert coaching and guidance available to the team”. These elements provide teams with “adequate resources and information” as well as “access to a mentor or a coach who can help them through issues” (which you probably wouldn’t consider an unreasonable ask when you consider the scale of investment in making a project succeed).
All of this makes a rather compelling case to reimagine the traditional approach to projects and apply a zero-assumption blueprint for project onboarding.
Project toolkit for the beginner
Let’s assume you are currently in or about to enter the project wilderness without a compass at leadership or grassroots level. We’ve got you covered with some resources you may find useful, and a reminder of some of those mentioned above:
1. Project language and phraseology
2. Project documents
3. Project software
4. Project methodologies
5. Finding your project mojo
Related DWG research
Related Digital Workplace Impact podcasts