Project Life Cycle.

Intro
Phases.

Intro

In this section of our playbook we intend to establish a common work methodology for project management and describe our typical project life cycle. The goal is to optimize the way we work and standardize the procedures, as much as possible, so that every person is familiar with it. Moreover, by creating a common process, we are bringing transparency and clarity to our practices and with it enhancing the way we care and support each other. This is also meant to be the central hub for all relevant templates and guidelines. Thus, hyperlinks to those documents are highlighted whenever it applies and are listed under a joint glossary.

Project life cycle

Independently of the diversity of our projects, we like to follow a common approach and process so that we can optimize the way we work together. To attain this consistency within the company, it is important that the whole project team understands and follows the different project phases and the most important rituals a project entails. Under this framework we intend to create the conditions that pull people into greater levels of development, performance and accountability. With this structure we can also enhance the performance and feedback culture that will allow us to grow individually and as a team.

What are the project phases?

In a standard Vizzuality project, we typically have 8 phases:

Proposal writing - under BD responsibility
Kickoff - organized by BD and the PM
Discovery - project team
Design - project team
Data processing - project team
Development - project team
Launch - project team
Retrospective - led by the PM
Support and maintenance - optional phase, led by the PM

What is a ritual?

A ritual is a formal “space” within the project life cycle to make things explicit, agree, document, review and learn from each other. There are two main rituals in every project life cycle: the kickoff and the retrospective. Together they form the performance loop, since on the first ritual we agree on how to work together and we define individual responsibilities, and on the second ritual we revisit those commitments and pledges and explore ways to improve. Formalised feedback loops improve performance and growth. Feedback and evaluation are not simple admin or bureaucratic tasks that we do just to check a box. They are key components for the solid construction of a learning and high performance culture. We need the entire team to know them, understand them and readily apply them.

This is why, independently of project or PM, kickoffs and retrospectives should be run in similar ways. Not only will all of us know what to expect and what to do, but, having a shared notation system, makes it easier for anyone outside of the team to compare projects and analyse them.

Elements of the rituals

When we perform a kickoff of a new project, and later on its retrospective, we have 3 main elements to combine: our functional area social contract (what we agreed to offer as a functional group), our individual roles and agreements (that defines who does what at an individual scale) and our growth perspective (what new skill/experience can be or was achieved).

Social contract - is something that doesn’t change with a new project, it can be revisited for sure, but for the lifetime of a project, this is rather a static document. [add links to social contracts]
Kickoff - To define and agree. At this stage we should share agreements for the Vizz team working on a specific project (Who, what, when, how). This is documented on the welcome doc “roles and agreements” table during or after the kickoff meeting (see the specific kickoff section on this playbook). Some of these agreements are also important to be shared with our clients, so this is a good moment to think that through.
Retrospective - To fix or close and learn. In general, we try to answer the question: are we collectively doing a good job contributing to our purpose? And we try to find out if there is a specific process that should be triggered internally to ameliorate our way of work or to grow. On the other hand, a retrospective also gives us the opportunity to think if there was something nice and interesting that happened on the project that is worth sharing with the broader Vizzuality team. (See the specific retrospective section on this playbook)

Project evaluation

Project evaluations are a way to inform the decisions we make by critically assessing our work. Thus, all projects should be evaluated by Vizzuality and the client. These evaluations are meant to track project quality and client satisfaction, as well as to identify growth opportunities and improve individual and team performance.

Our projects can be assessed both internally and externally. In both cases, we mostly want to understand the project performance in 3 main pillars: time, quality, and experience. However, from an internal perspective, we should also reflect on our processes, as well as new business and learning opportunities.

Criteria to perform an evaluation

Time

We know if the deadlines were kept or not, but it is important to detail:
Why did the delays happen?
Did they have a big impact on the client? On Vizz?

Quality

It is important to define since the start of the project what is quality. For different projects we might have different quality criteria and that is important to have in mind.
Added value (at what level? Innovation? BD? Other?)

Experience

Here we have several subgroups:
Satisfaction
Communication & feedback loops
Perspectives for future work (for the client)

Available tools

Project evaluation - presentation and google doc
Kickoffs - agenda with initial agreements
Retrospectives - guide
An internal survey - questionnaire
A structured interview with the client - script

Outcomes

Once we obtain all insights from our team and from the client some action points should be defined. These should be identified and shared with the entire project team by:

Signaling it on the Slack channel;
Saving all documents on the retrospective subfolder;
Writing a Blogin to share general conclusions with the whole company (use the retro tag)
Alerting Exec and/or BD if critical issues have arisen.

Project documentation

All information about our projects is kept in VizzTracker and Google Drive.

What can I find in VizzTracker?

Just as the name implies, VizzTracker is where we keep track of our work. It gives us a quick picture of the financial health of a project, but it is not only about numbers, it also intends to centralize all project related materials. BD is responsible to create new project/contract entries and PMs will update them monthly.

Tip: mind the difference between project and contract in VizzTracker. The contract is the actual work unit of a project. One project can have several contracts, but one contract only belongs to one main project. For the sake of our daily use, the contracts page is what we should look at.

For each contract we have access to:

Project start and end dates
Relevant links - here is where we centralize all information for location of google drive folder, gitbub, pivotal tracker, Invision, etc.
Project total budget
Estimated progress - based on tasks completed.
Cost to date & income to date - based on time reports and progress.
Budgeted and reported time breakdown per functional area

How do we organize our projects in Google Drive?

We keep all our projects documentation inside Google Drive. All projects main folders are here and a direct link to it can also be found on the sidebar of VizzTracker.

Each individual project respects the same organization of folders. The PMs are responsible for creating the project main folder (which you can access by entering the project page in VizzTracker), but everyone must collaborate to keep it tidy. Every FA is responsible for keeping their own space up to date. E.g. Design folder - invision links referenced, style guides, etc. Try not to keep any ongoing work on your personal drive, everything project related, even work in progress, should live in the project main folder.

What is inside the project main folder?

A standard project folder will include:

Proposal & Admin - here we put contracts, budget, link to proposal and other admin materials.
Onboarding - this is the go to folder when we start working on a project, thus important documents to understand the basics of a project, like the welcome doc, timeline or kickoff agendas will be kept here.
Discovery - all research related items should be kept in this folder.
Design
Data
Development
Launch
Retrospective
Shared folder - in case we need a folder to be shared with the client. Otherwise, use the SHARED prefix to individual documents located in other subfolders, it also works.
Internal notes doc - to keep a record of our internal meetings so that all team members can always be up-to-date.
Client notes doc - to keep a record of all our meetings with the client. These notes may be shared with the client (if marked SHARED) or not.

Reporting

At the end of each month everyone at Vizzuality has to fill in their report with the % of time they have spent working on each contract that month. Non-billable activities such as operations or vacation should also be reported. So at the end of the month your report should sum up 100%. This information keeps track of the cost of each project and allows us to check if we are within budget or if some corrective measures need to be put in place. These reports are NOT intended to be used as a timetracker software. For this we usually use Tmetric, but ask your PM if the project you are working on has any specific time tracking tools.

For cost tracking purposes on VizzTracker, we consider that 5% is roughly equivalent to one day of work. You should disregard bank holidays and different months length, as well as your own dedication time, since this is already calculated by the app. Other guidelines for reporting can be found in the i button of the VizzTracker reporting page.

Phases.

Acquisition & proposal writing

Budget template - always use the original template. This template is updated every 6 months or so to reflect the current exchange rate USD/Eur and our internal rates.

A new project may start in different ways as explained on the BD workflows document. There are also different proposal types, and a PM or members of other FAs might or might not be asked to participate in its writing (see different examples 1, 2, 3, 4).
This phase is led by BD. Most times a PM is already designated to a proposed project and ideally if the project is approved that PM will be following it through. At this phase it is important to use the proposal template [link to proposal template] and budget template [link to budget template] to apply a similar reasoning, buffer times and rates throughout projects. always use the original template. This template is updated every 6 months or so to reflect the current exchange rate USD/Eur and our internal rates. Once the proposal is accepted the client will send out a contract draft that must be reviewed.

Kick-Off

The kickoff and project onboarding is usually a crucial part of the project. This phase goes after the contract signature and it is a moment where we establish many of the conditions and expectations of the project. This phase definitely defines how the whole project is going to develop.

Preparation

As soon as the contract is signed, BD and the PM will fill out the welcome doc [link to welcome doc example]. It is important that the PM, together with the team, revises the proposal and any other documents the client may have shared. At this stage we will coordinate internally on how to organize ourselves as a team (communication tools, frequency of meetings, etc). This is also the moment to clearly define the roles and responsibilities of every team member.
Each member of the project team reviewed the welcome doc in advance of the Kick-Off session to understand both the “Big Picture / Purpose” and also the more specific “deliverables and jobs to be done”.
Based on the “Team Pledges & Agreements Template Table” present on the welcome doc, each member of the project team starts thinking on their Responsibilities, Impact and Growth.

Kick-off sessions

INTERNAL

In this event, we’ll introduce the project to the whole team and we should get some outcomes. The welcome doc [link to welcome doc example]. covers also the questions and aspects to be covered during the internal kick-off.

During the internal kick-off session, the PM will ask each member to share initial ideas about what their role and responsibilities will be.
Team members allowed 2-3 days to fill out the table “Team Pledges & Agreements” in the welcome doc.
Once the table is completed, everyone reads and comments. It is the moment to identify role overlaps and other inefficiencies.
Role owner to modify and update if needed (Self Set Targets, Ownership)
PM to facilitate a consent round to the Plan. “Does anyone have an objection?”

EXTERNAL
At this point, we have enough information to set up a good client meeting kick-off (This will be documented). Before this, we should make sure we have the welcome doc and the project starter kit updated with the particularities of this project.

Share project starter kit [link to project starter kit] with the client (if applicable: e.g. new client).
Prepare and share with the client external kickoff document [ link to external kickoff].
Create a project on Basecamp, Pivotal Tracker, or other communication channels. Template for the welcome message to basecamp [link to welcome message here].

Documentation

It’s of primary importance to keep up to date documentation in Google Drive for all the areas involved. This will help any newcomer to join the project. Every participant in the project is responsible for maintaining his/her documentation in the project main folder and alerting the PM if something needs to be linked to VizzTracker. Something like:

Designers should put the link of the latest design and wireframes into the Design folder of the project and this link should be also in VizzTracker.
Data scientists should put relevant links to notebooks or keep an updated spreadsheet with data sources in the Data folder of the project.
User researchers owners should keep up to date their docs into the Discovery folder of the project.
Developers should write the links of all Github repos in a google doc in the Development folder of the project and on VizzTracker, 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 in the welcome document.

Profile’s Onboarding.

If someone is coming to the project. It’s time to have a meeting and talk about the project. The PM together with other team members should meet, give a project description, explain technical solutions, and ask for opinions from the newcomer. At this point, we should have up to date documentation enough to make a proper onboarding with the welcome doc, tasks management software, and information from the meetings.

Discovery

Once the ground rules are established between our team and the client it is time to start the work. The first step is usually a discovery phase. Taking into consideration that the PM needs to be always aware of everything happening and should (somehow) sign all the plans This phase is led by user researchers and designers, but also involves data and tech discovery. It will vary according to the project, but below we highlight the most important things to take into account. The PM will be moderating discussions, gathering conclusions and setting next-steps or to-do lists.

Success definition

Define what the project needs to achieve.
Refine the timeline according to tasks.
Revise the Quality Cheklist.

User Research

Read previous research documentation (if existent).
Prepare a summary of that research (if existent).
Prepare interviews (if needed).
Prepare conclusions document.
Prepare conclusions document.
Prepare persona and use cases document
[Link to Design Sprint Guidelines]
[Link to Stories and acceptance tests]
[Link to Quality checklist]

Science discovery

Understand the datasets to be used, propose data analysis and complementary datasets
Set up data meetings (if needed).
Start filling the data status document [link to the data status].

Tech discovery

Understand the adequate tech to use and prepare a tech specifications document [ link to tech specification document ].
Prepare the FE scope document [link to FE scope document].
Prepare the BE scope document [link to BE scope document].

Feedback

Meet with the client.
Validate target users.

Design

After having a good understanding of what the client wants to achieve and the main user that is to be targeted by the platform the design phase starts. This phase is led by designers and involves a lot of iteration and co-creation. However, it is the PM job to make sure that we do not deviate from the scope and that we still keep the project on time.

Wireframes

Create the first ideas (low-fi prototyping).
Ask for input from the Scientist to clarify necessities (brainstorming).
Production of dummy figures/sketches for the wireframe.
Share with clients and collect feedback.

Design Sprint

Prepare a design sprint (in-person or virtual).
Create a summary of the sprint.

Visuals

Create visuals (high-fi), branding guidelines, etc
Share with clients and collect feedback.
Post conclusions of feedback on basecamp.
Post conclusions of feedback on basecamp.

Data Processing

Data processing and ingestion will probably crossover several phases of the project. That is why the science team member should always be in close contact with both the designers during the discovery and the developers during discovery and implementation, to guarantee that the solutions we find are suitable for the data types we will process. The PM can serve as an intermediate to talk to the client or simply moderate the data conversations to make sure there aren’t any blockers that will affect the project.

Data digestion

Receiving the final data from the client; Transforming the data to serve it to the Front End; Fill out the Data status sheet
Provide code of the methodology in GitHub (Science repository) [Documentation]

Data Storage

In collaboration with the Back End determining where the data will be stored.
Fill out any database models explaining the relationship between datasets.

Communication materials

Prepare communication materials to explain the process to the client.
Prepare communication materials to complete the website or in close collaboration with the data person on the client’s side.

Development

Once the design and the visuals are ready and approved by the client it is time to make the magic happen. Developers will start building the application usually using sprints of 2 weeks. Working in cycles also offers the opportunity to provide feedback early, so we avoid situations where major rewrites are required. This can be two-way as developers might also identify areas where further discussions are needed. The PM job in this phase is to facilitate a good communication between the different functional areas and, as always, to make sure we keep the timeline, scope and quality of the project.

The development process characteristics will depend on the project but this are the implementation defaults [link to Implementation default]

Launch & Ahead of release

The launch is the official release of the project (platform). In this phase we must consider the hand-over period and warranty both in terms of time length and activities included.

Checklist (TBD).
Comms (TBD).
Analytics

Retrospective

At least after handing over the final deliverable and issuing the last invoice, it is time to take a step back and think of how the project went. We should consider both the client’s opinion and our internal team reflection. Note that retrospectives can also be done after important milestones or if there are issues with the project.
To set up a retrospective meeting see some guidelines here. Consider doing an internal retrospective or also inviting the client to this meeting. It all depends on the objectives we have in mind. Regardless of the format, we should always ask the client for its feedback. The PM should adapt the methodology to the type of project and client to perform an evaluation.

Preparation

Ask for a facilitator to moderate the session. And ask BD to be present.
Make sure everybody knows the subject and the objectives of the session, sharing the agenda, and some key points beforehand.
Each team member to revisit the “Team Pledges & Agreements” [link to team & agreements template table] in the welcome doc, to keep them in mind for this session.
Optional - each team member fills out a form [link to form example] before the retrospective, to summarize project satisfaction. If necessary, BD can collaborate, and fill in the BD questionare for the project [link to BD questionnaire doc]
Also, you can gather independent and specific information from the client in the form of a survey or interview [link to client’s interview script]. And get some information about the clients satisfaction [ link to Client Satisfaction].
Add up the project evaluation little description/mention.

Retro sessions

As we said, the structure and development of the retrospective are flexible so the PM should adapt the methodology to the type of project and client when doing the retro. But you can use the guidelines here for help and inspiration. While doing a retro some good practices are:

Keep positive communication and have the key principles in mind.
Make sure to reach out to introverts.
Keep the time and stick to the structure.
Write clear and achievable action points.

After

PM to write a summary of the main ideas and action points. Keep documentation in the Retrospective folder, inside the project main folder in Google Drive, for everyone easy access and tracking. It is also a good practice to share conclusions with the whole company via Blogin.

One of the most forgotten things is to follow up on the action points after a retrospective. It is ok to not have some action points for some of the issues found during a project, the main goal of a retro is to find improving points in order to act on them, not just to point or mention.

Support and Maintenance

In some cases a project might have a maintenance and support contract. These activities can be divided into 3 groups:

Corrective - will be applied when a problem is detected with a response within 48 hours if the issue is not critical, within 24 hours if the issue is severe, and within 4 hours if the issue is critical.
Preventive - will involve periodic revision of servers, codebase and updates to guarantee security and performance.
Evolutive - consists of some analysis and activities focused on finding areas of improvement for the usability and the quality of the platform.

New contract

Throughout the project, but especially towards the end, it is important to start conversations with the client about possible new contracts. A new contract will have a defined timeline, budget and scope, even though it will be associated with the same project. We must not drag things from old contracts into new ones.

This will start the same process with (possibly) the same phases we’ve seen, depending on necessities for the new contract for the project.

Glossary

All templates listed in one place (TBD).