Project management


We receive requests from more and more people willing to use the OFN, either set up a public instance (OFN partner) or deploy a white label version (OFN based service providers).

There is always someone from OFN who is the first contact answering those request. It can be me when it answer an international request, through the “global gardener” role that I have played for the last couple of years (already?!). Or it can be @nick for example he received some request directly from Belgium through OFN UK. Or it can be @Kirsten also, for example with the German project, after some first discussions with me I handed over the project to the Aus team when it started to get more into a “contractual support” to help set up an instance, do specific developments.
It’s great actually if that “global gardening” role can be a bit more distributed as it’s sometimes hard to take over a contact / emerging local instance if the local territory has already been facilitated by someone else. So if some people would like to take the “global gardening role” for some parts of the world, please tell it here and we can see how to distribute more the role and I’m happy to document how I have been doing that until now :slight_smile:

There is a need to empower more people within the community who could do that job of “project manager”, build the project hand in hand with the “prospect / instance applicant” (don’t know how to call him)

A- Understanding the situation and start envisioning what to propose

If I were to describe the process of welcoming and facilitating the emergence of the project, I would list the following steps:
1- Welcome, personal connexion, who are we, what do we want to create in the world, feel the alignment with the values, etc. Sometimes it’s super evident, sometimes I have asked many question to really undertand what they wanted to create, asking “unpleasants” questions also, on their vision of farming practices, on governance, etc.
2- Explain what is OFN, our “policital project” I would say (I always formulate it as: building a public infrastructure managed by the citizens to support reconnexion between producers and consumers and decentralization of the food system by enabling and supporting the emergence of independent food hubs everywhere, etc.). So first it is “what world we want to create and why we do what we do”
3- Then explaining the different options for someone who want to use the OFN in a country where there is not yet a local community. There are basically two options:

  • either the person wants to be part of the community and wants also where they live to empower the emergent of a vibrant and diverse food hubs ecosystem, then they will want to deploy a public local infrastructure than anyone will be able to use locally, and so they need to build a governance and business model around it (like the platform coop model documented by OFN UK). A good point is that infrastructure and support cost can be shared by all the local users.
  • either they have a specific project and it’s not their “mission”/will to develop a public infrastructure and organize it so that anyone (and so, themselves) can use. They want just their version, a white label instance, and are ok to pay the full cost of their infrastructure.
    4- Depending on the local situation:
  • If the person wants the public infra option as it’s very much align with what they want to create locally, then you can check if other people from this region have already contacted OFN and next step can be to facilitate a meeting with the emerging local communities to see how it fits between the people and if they would like to work together on building the local infrastructure and community. You can propose support in setting it up if they need.
  • If the person wants a white label version you can propose support in setting it up if they need, as we have project managers and developers who can work on this project if needs be.
    5- If support is required (meaning the person doesn’t have dev skills around, etc.) then we enter the project framing phase
    6- Also mention the “contribution to the commons” point (cf community agreement document, every local instance contribute a % to the global core CC, same for white label instances)

B- Build up a more formal project proposal

let’s talk now about this person as a potential “client” as there will be a service done by an entity for another entity who is going to pay for that service.
1- First step is understand clearly the need of the client in terms of:
- infrastructure (servers capacity depending on the project, the level of accessibility they want, like are they ok to take the risk that the service is not accessible if the server is down or do they want it to be available all the time, in case you need to double the server capacities to create redundancies, etc.). You don’t have to find the good technical solution but understand the need to be able then to put in the project someone who can do the specification. Do they have someone already internally who can deploy the code, manage the server, etc? Or do they want to subcontract this part? etc. See here and here for more understanding on this part.
- localization adaptations (VAT, invoice format, translations,…)
- features developments (is the existing big set of features answering their need or not? Try to understand what is the MVP need, what they need short term, and what they would like but they can start without it)
2- Build the team to be able to make a formal proposal on what we can do to answer their need.
The idea here is to find the persons who can give the recommendation on the infrastructure (and if accepted set it up), who can do the estimates for the developments, who can then do the developments if the project is accepted by the client. If you won’t be yourself the project manager, find a project manager. Ask the whole community to find the people who can work with you on that!
3- Ask an estimate from the team on all what need to be estimated so that the client can have an idea of how much it should cost (always clarify it’s just broad estimates and will be adjusted when we start working on it). If needed explain the agile methodology we work with (maybe will need a specific post)
4- There is often a need to clarify “how we work” also. Because we all cooperate on the same master branch, when the client express a need, there will be concertation phase with the community to agree on how to make the change in a way that is ok for everyone. It takes a few days, but it is important that they understand that if they want to co-build with the rest of the community they have to accept that (see this post to have your arguments ready)

C- Manage the project until it’s released :slight_smile:

Then it’s more daily management, coordinate with the client and the devs/designers/etc.
So in agile, it’s more a role of “product owner” and “scrum master”. But all that depends of course of the scope of the project. If it’s only set up a local instance, it’s not the same as if there are lots of developments to do.
Some info though about agile project management.
1- As a project manager also, before the project start you will have to agree with the client on the contract and payment conditions. Big companies sometime pay very late, so it’s important to discuss with the team if they are all freelancers and have some working capital so they are used to be paid late by their clients, or if that’s a problem and you need to find some “factoring solution” for example. Of course as project manager you will pay yourself.
2- Before starting the developments there is an inception stage which is listing the user stories that the client want (the features, but formulated as user stories, like “as a user, I want to be able to see a summary of my basket and modify it”). Those stories are listed in what we call a “backlog” and prioritized. For big projects it’s important to define the scope of the “minimum valuable product”, so the stories that are imperative before the first version of the project can launched.
3- Developments are organized by “sprints”, fortnightly for example, so for ex on Wed. morning you gather with the client and dev, you agree on what is going to be done during the sprint. Every day you can have a quick 5 min stand-up meeting on what was done yesterday and what is going to be done today. At the end of a sprint you have a review with the client of what has been released, feedback loop, and plan next sprint. Until it’s complete :slight_smile:

This is just a first “quick post” on the project management role, I make it a wiki and let you @Kirsten and @danielle modify or precise some stuff before we @ and invite more people to that discussion :slight_smile: I did it quickly so maybe I forgotten some important things :-o

Introducing a US-based For-Profit Potential Partner

Thanks for the write up @MyriamBoure!

I’m wondering how is this related to the product management / coordination we were talking about in the last global (?) hangout. Is there any overlap between project and product here?

I ask this since my action item from the last global hangout is to organize a dedicated hangout regarding how to coordinate between instances / projects working on the OFN as a product.

I hope I got it right :grimacing:


Good point @enricostn there is overlap of course :slight_smile:
I would say in two main points:

  • on the estimation stage, there can be a possibility to crowdfund some features needed by the community, so this can be part also of the “product curation”, like identify the share needs. Also in the estimation there is a first reflexion on how things will be done so that it doesn’t mess up anything for the others :wink:
  • but more precisely it’s when you do the serious inception and specification job, there will probably be a specific card in the backlog for “community concertation” so you will make a first spec on how you see the feature implemented and facilitate the discussion so that it’s ok for everyone, flexible enough so that every local instance can set up / activate or deasctivate / customize to its local situation. So yes, the “concertation” stage before we develop any new feature is the “product collective curation” side of it :slight_smile:

But I think in terms of product management there is also the question more of “strategy”, like our collective vision of where the product is going to evolve, in a short/mid term, but also longer term (see discussion on micro-services architecture for example which is more a longer term evolution discussion I guess).

Just some food for thoughts :wink:


Hi everyone!

@MyriamBoure - nice work :smile:

I would suggest there are 3 distinct aspects that we are talking about here: Initial “sales” enquires and securing new potential instances (the thing you do so well @MyriamBoure), then the coordination of scoping and delivering any additional functionality, and finally the subject matter expertise to determine how something should be built, how it fits into the rest of the platform, who else is working on something similar, etc.

Let’s call these roles BUSINESS DEVELOPMENT and PROJECT MANAGEMENT and PRODUCT MANAGEMENT (for now, there are probably better titles moving forward).

I sit really comfortably with the project management role, however I don’t feel as adequately equipped to do the business development, and I usually step back (due to time constraints) and let @oeoeaio and @Kirsten do the product management side of things. Sometimes I do get involved in product development process (e.g. standing orders) and I’m not adverse to stepping in and doing this when required (I’ve been a digital product manager in my “day job” on and off for years).

So I wonder whether we should be differentiating between these 3 roles, because individuals may feel comfortable taking on (or be time constrained to) one aspect but not all 3?