Close
Vocab
3.0 BELIEF

Common vocabulary over common tooling

Diversity on teams is increasing (finally!). More and more conversations are happening via chat than in-person and we’re all busier than we’ve ever been, which means getting lost in translation has become the norm more than the exception these days. 

Belief highlighted
Belief highlighted
you are here
Clapping hands
3.0 RITUAL – common vocabulary over common tooling

Answer the same foundational questions for all projects

“What is a project?” sounds like a question the dictionary could solve, but it’s surprisingly complex. Layer in “How is your project going?” and the range of possible ways to answer can certainly not be defined by a generic dictionary. That’s why you need to create your own custom project dictionary for your teams.

Empower every team to work the way they want to work, by giving them a template for what needs to be consistent across all projects. It can be as basic as defining “What is a project?” and being clear about expectations for status updates or step it up a notch and setup a system that helps all teams answer the same foundational pre-, during and post- project questions we found critical in enabling our scaling company or empowered teams.

Ritual highlighted
Ritual highlighted
you are here
Before and after diagram of teams all talking about a different front to teams all talking about the same fruit
Before and after diagram of teams all talking about a different front to teams all talking about the same fruit
share:
Link button
Wavy background
Wavy background
PRACTICE with your team
Wavy background
Wavy background
Wavy background
Wavy background
Wavy background
3.1 technique – common vocabulary over common tooling
Framing a photo with caption: gimme all the context
Framing a photo

Define your project’s what, why and how

Oftentimes the “what, why and how” of a project lives in a few people’s minds. These questions are crucial context for every team member, stakeholder and anyone you ask for feedback.

How to set up the technique

Step 1

Gather a group of people who oversee, contribute to and lead projects across the organization. Make sure to get a diversity of tenures, roles and departments represented. Ask everyone to come with an example of the best project they’ve been on/observed and the worst.

Step 2

Using a digital whiteboard tool (like Trello, Mural or Miro), setup two columns to record the “Commonalities of the best projects” and the “commonalities of the worst projects.”

Step 3

Give every participant 2 minutes to share the details of the “best” project example. While they are sharing, write down qualities of that project that stand out to you. Focus on operations/processes over subject matter and talent.

Step 4

Spend 10 minutes as a group proposing common operational qualities of the “best” projects. Use your digital whiteboard to record your collective list. It’s okay to be exhaustive, you’ll cull this list later.

Step 5

Repeat Step 3 discussing and note-taking on the qualities of the “worst” project example.

Step 6

Repeat Step 4 summarizing the operational commonalities of “worst” project examples.

Step 7

Give everyone 3 votes in each category, best and worst, and ask everyone to vote for the most salient qualities of each category of project.

Step 8

Use the results of the voting in Step 7, brainstorm what questions every project should answer before kicking off. For bonus points, create a digital repository of all project kick-off docs so that they are discoverable across the organization.

variations

If you’re keen to skip the creation process, try the Project Poster all Atlassian teams use in Confluence

Anti-patterns

Don’t make the pre-project checklist so long it’s burdensome for teams. They won’t use it if it’s more than 10 questions, trust us.

Techniques highlighted
Techniques highlighted
you are here
3.2 technique – common vocabulary over common tooling
Holding a card of the moon phases with caption: nail the basics
Holding a card of the moon phases with caption: nail the basics

Agree on “what is a project” and phases

Ask a team of 10 people to independently write their answers to “what is a project?” chances are you’ll get 10 different answers.

How to set up the technique

Step 1

Ensure you have an appropriate decision maker engaged (async or live) who can help standardize the outcome of this exercise across teams.

Step 2

In a collaborative document (or in a meeting) collect examples of projects across departments.

Step 3

Ask a selection of project owner, contributor and group leaders across departments to fill out a “Mad Libs” style template to create their definition of a project. The template should include number of people, time period and differentiating features of projects (compared to work that is not a project, like a spike (quick burst of work) or service-style engagement)). For example Atlassian defines a project as any body of work that requires 2+ people for 2+ weeks. Yes, it can be that simple.

Step 4

Once you collect everyone’s inputs on your collaborative document, as the facilitator use the inputs of your advisory group to propose one (or a few) project definitions for your advisory group to react to.

Step 5

Collect input to your proposed project definitions, revise and propose to the decision maker for use across the company.

Step 6

Once project definition is agreed on, you have the foundation to define what phases each project will go through. The Project Management Institute defines the 5 phases of a project as Initiating, Planning, Executing, Controlling and Closing (source). Atlassian development teams use Wonder, Explore, Make, Measure. We recommend starting with a standard framework and making it your own. Put it in your own language, reflect your company values and ensure it captures can be used and understood across functions.

Step 7

Design a system to reflect the project phase in each team’s updates. Atlassian teams reflect it on their Project Poster and in their Atlas weekly updates.

Step 8

Communicate to key project drivers the guidelines for project definition and phases and build in a mechanism to receive their feedback as each project leader uses the new guidelines.

3.3 technique – common vocabulary over common tooling
Holding flags with caption: what does green even mean?
Holding flags with caption: what does green even mean?

Define your status markers: On track (green), At risk (yellow), Off track (red)

Have you ever heard of Watermelon status reporting? It’s a contagious form of fake news that happens in the workplace but it can be cured by setting up a social contract among all teams for when and why to change your project’s status.

How to set up the technique

Step 1

If available, grab some old status reports, ideally as recent as possible and some sequential reports where projects statuses have changed.

Step 2

As time allows, interview a handful of project owners who shared changes in their project status over the course of the historical reports. If old reports are not available, simply send a survey or ask project owners and stakeholders the following questions:

  • Sample interview questions for project owners: 1) What prompted you to change your status from (RED/YELLOW/GREEN to YELLOW/GREEN/RED), 2) Define each status in 10 or less words; green, yellow, red. 3) On a scale of 1 (low) to 5 (high), how safe do you feel choosing a status that is not green? 4) On a scale of 1 (low) to 5 (high), how confident are you that you are scoring your status consistently with how other project owners are scoring?
  • Sample survey questions for stakeholders: 1) What do you hope to learn from reading a project status report? 2) Define each status in 10 or less words; green, yellow, red. 3) On a scale of 1 to 5, how much do trust today’s status reports? (1 = do not trust at all, 5= trust a lot)
Step 3

Summarize the inputs from project stakeholders and owners. Use the status definitions to draft proposed standard definitions of each status marker. Use the results of the scale rating questions as input into to share why defining status markers is important when you announce the definitions.

Step 4

Share your proposed status definitions to an appropriate champion/decision maker for feedback. Iterate and finalize.

Step 5

Record and share status markers in a shared document and embed in all status reporting process documents and reporting tools.

Step 6

Repeat the project owner and stakeholder surveys with the same participants 3-6 months later to assess how confidence, safety and trust have improved since the change and why or why not.

Quote mark
Quote mark

An order that can be misunderstood will be misunderstood.

Napoleon Bonaparte

Emperor of the French

Explore all the Loop techniques


1.0 Open up your work in progress


1.1   Create reference-able handles


1.2   Open up comments & questions (avoid 1:1 messages)


1.3   Distribute updates in channels where teams live


2.0 Curate, don't automate


2.1   Character constrain your updates


2.2   Update async, spar in real time


2.3   Balance qualitative + quantitative


3.0 Common vocabulary over common tooling


3.1   Define your project’s what, why & how


3.2   Agree on “what is a project” and phases


3.3   Define your status markers (On Track (green), At Risk (yellow), Off Track (red))


4.0 Show that you are paying attention


4.1   Level your feedback in line with phase/fidelity


4.2   Create a read receipts mechanism


4.3   Follow relevant projects & celebrate wins together