Vizzuality playbook in progress
This project is maintained by Vizzuality
Making a proper project onboarding can be crucial many times; while some can see it as just a “go” for others it can mean a “sink or swim” moment. In this document we’ll identify key needs and propose a solid structure for a successful project onboarding.
Usually this means the time in between we win a project and when we are ready to start, but this also applies to the time when a new fellow comes to the project. We’ll try to set a solid base during the general onboarding to facilitate newcomers to join.
We need some time to review the initial proposal, preliminary emails and any kind of documentation. This step should be a PM responsibility in most cases with the participation of the BD team, we should get the following outcomes:
Project subject, a kind of short phrase that could describe the project.
Project description, a more elaborated definition of what the project is about.
Target users.
Client description.
Identify risks and caveats.
Preliminary - user needs that this project should cover.
Preliminary - project needs, what is this project demanding to gain success.
Preliminary - client needs, what does the client expect from this project.
Preliminary - short term client needs, if there is a short term deliverable, how we could cover this without compromising quality or team rush.
Preliminary - technical needs, identify tools and gaps. Think about company wide people that could help for consultancy.
Preliminary - how we’ll add value to this project.
Team allocation, who can work on this project. Who will be product owners in different areas.
Setting up the tools, PT, Basecamp, Slack channel, GH and Intranet.
Timeline or relevant milestones if any.
A document should be written with these points to help with the next step; where possible the intranet page should also be completed with this information.
In this event we’ll introduce the project to the whole team and we should get some outcomes. These are the points that should be covered in the meeting:
Client introduction: Who is the client, previous projects if any. Anything to be aware of?
Project introduction: We should make a presentation, a slideshow is desirable. We’ll talk about motivations, targets, risks and caveats.
Questions round.
Discussion - user needs that this project should cover.
Discussion - project needs, what is this project demanding to gain success.
Discussion - client needs, what does the client expect from this project.
Discussion - short term client needs, if there is a short term deliverable, how we could cover this without compromising quality or team rush.
Discussion - technical needs, identify tools and gaps. Think about company wide people that could help for consultancy.
Discussion - how we’ll add value to this project.
Discussion - what will we learn? Each team mate commit to learn at least one thing and will be revisit in the retrospective.
Discussion - should we ask for consultancy to someone else in the team?
Roles and ownerships assignments. These roles will be also responsible of maintaining the documentation in their areas along the project.
Giving access to the project tools to the team.
We’ll elaborate a document with the outcomes and link it into the Intranet.
Next steps and follow-up
At this point we have enough information to set up a good client meeting kick off (This will be documented).
It’s of primary importance to keep up to date documentation for all the areas involved. This will help any newcomer to join the project. Every owner of the project is responsible of maintaining his/her documentation by using the right tools and linking that into the Intranet. Something like:
Designers should put the link of the latest design and wireframes into the Intranet.
Data scientists should put the link of the latest Jupyter notebooks into the Intranet.
Social scientists or discovery owners should keep up to date their docs into the Intranet.
Developers should write the links of all Github repos into the Intranet, as well as technologies and frameworks.
Developers should document the Github repos properly, how to create the environment, how to deploy, dependencies and special procedures should be kept up to date.
PM should document any important change or exception to the SOW and link it into the Intranet.
Someone is coming to the project. It’s time to have a meeting and talk about the project. The PM together with other project owners should meet, give a project description, explain technical solutions and ask for opinions to the newcomer. At this point, we should have up to date documentation enough to make a proper onboarding.