In Feb 2017 in collaboration with the Engine Room’s Tin Geber I flew to Croatia to help GONG, one of Croatia’s most formidable NGO’s help kick off their new Mosaic of Influence project. It will be cross posted on the Engine Room’s blog.

GONG is a Croatian “think-do tank” which aims to identify and inhibit abuses of political power in their country.

The organisation is 20 years old and while some of their early successes were technology projects, the organisation later became more activist in nature and now has no in-house tech team. In Mosaic of Influence, they are again involved with a technology project, and wanted to know:

1. How should we structure our delivery team?

2. How will our delivery team communicate and coordinate with the rest of the organisation?

What follows is a short overview of the workshop we ran to help GONG work out their own answers to these questions and a short but awesome reading list of where to find out more.

Structure of the Day

Morning - Jargon Busting

This section is covered in more detail in the post, “A lean agile waterfall: Jargon busting software approaches”.

This section gave the team the key vocabulary to be able to interact with software teams and understand how a choice of a particular philosophy e.g. agile vs waterfall may impact their project. Crucially, as this is a grant funded project, it also allows them to think about how they might report on it.

Post Coffee - Common error modes

Error modes Part I: Civic Patterns

With the aid of the wonderful Civic Patterns, particularly the Engagement section, we quickly busted through some shared wisdom about mistakes that do not need to be repeated.

Error modes Part II: Cat Wigs

We then played with some Cat Wigs Cards to prompt us to have some of the crucial conversations around the project.

The cards ask questions such as:

• HAVE YOU DEFINED THE PROBLEM? Is it worth tackling?
• How many people are we expecting to use this?
• How are people going to discover it?

For those unfamiliar with Catwigs, this post highlights how it works.

The cards are a fun way to give a project a reality check and highlight areas requiring additional thought before work begins. For the best results, work with people inside and outside the immediate project team.

Post Lunch - Mapping roles

Mapping roles was an exercise in mapping known unknowns. It was important to let GONG realise what they already knew.

We did a simple exercise where they could brainstorm all of the roles they had heard of. Tin and I then augmented the list with other roles we thought they might encounter.

Action shot: Working through and shuffling the roles.

Once we had everything up on the board, we could fill in the blanks by allowing them to ask things like:

“What does a Scrum Master do anyway?”

As the questions came thick and fast, we together arranged the post-its so that common relationships between roles was clear e.g. Designers often conduct User Research, so do Product Managers - let’s draw a line between User Researcher and the two other roles.

My favourite part of this session was GONG’s Executive Director Jelena realising that she knew a lot more than she thought she did:

“Why do I understand 80% of this? What are you not telling me?”

Tin and I laughed. If there was more than this, we had functioned in teams for many years without it. I hope that the discovery that there were no wizards or dragon slayers on the board was reassuring.

With our map of people in place, we could now have a meaningful conversation about which roles we have in the organisation and what needs to be brought in. We discussed models that could work for GONG to get them some additional support (that’s another post another day).

Summary - Key messages

• Having to talk about problems in human language is a strength, not a weakness. Conversations should always start from a problem statement. Problem statements should always be expressed in simple language to ensure everyone is on the same page.
• As a stakeholder, you do not have to understand every technical detail of a software project and it is probably not the most efficient use of anyone’s time for you to try and do so. The tradeoffs are the part you need to make sure you talk about, regularly. (Pro Tip: If your provider cannot explain the pros and cons of a given option, they haven’t thought enough about the real-world implications themselves; find someone else to work with.)
• Project and product managers are bridge roles, facilitating conversations between stakeholders and technical delivery teams. To delve more deeply into what these roles do see my post on Project and Product Management.

We wrapped the workshop by discussing next steps. GONG will now digest the map of roles and work out a long term plan for which skills are strategic for them to start building in house and which will be brought in for this project.

I also gave them some homework, a short but high bang-for-buck reading list. Maybe you will find it useful too!

Homework reading list

• Civic Patterns - An excellent resource for those not wanting to repeat common errors made in developing civic software projects.
• Blinkist do 15 minute audio summaries of lots of books and some of their non-fiction ones are excellent for busy people. I recommended The Lean Startup and Lean UX. The audio versions also have the additional benefit of not delving too deep into lots of startup stuff which is not super relevant to NGOs.
• Talking to Humans - a short, essential read for anyone conducting user research answering questions on how to avoid group think, when observation is more powerful than interviews and how to smash your own assumptions apart. Well worth a (less than 2 hr) read and it’s free!

A massive Thank You to GONG for having me and the Engine Room for their support before and during the workshop. The next step in the project is kicking off the user research and I can’t wait to see what comes of it!