The Lifecycle of a Network-Centric Resource


A network-centric resource is a knowledge asset that supports interaction and strengthens the ability of a community or network to exist. They can be collection of curriculum such as IFRC’s Data Playbook, EFF’s Security Education Companion, or events like MozFest.

We’ve chosen to describe the method of developing and sustaining a network-centric resource as a lifecycle that goes through phases, in order for resource designers to understand complexities and amount of effort. We often find resource designers using metaphors around life, such as ‘a living breathing document’.

At the beginning of 2018, we released a draft version of the lifecycle, after workshopping the initial methodology. The major change in the process is that we now consider birth to be the moment you share draft content, instead of the moment of an official launch. We’ve also added and refined tasks within each phase.

We are grateful to participants at our workshop sessions at NPDev and MozFest and members of FabRiders’ Network Centric Resources Project, who further refined and contributed the lifecycle. We also need to thank Greg Bloom from Open Referral and Rachel Weidinger from The Narrative Initiative for the encouragement to publish another version.

Preconception

Before any work begins:

  • Understand community/network needs & assets.
  • Conduct research of what already exists. How has the issue/topic been addressed elsewhere? What approaches might be relevant? Where is their potential for learnings that can be applied?
  • Map stakeholders and develop your engagement plan
  • Cultivate community/network and buy-in
  • Begin to scope funds, resources and expertise needed.

Conception

Articulate purpose and goals

  • Create a vision of success for the resource. If a theory of change exists, how will the resource support it?
  • Develop User Personas that detail how individuals will interact with and use the resource.
  • Make sure you understand how interaction and contribution will benefit individuals.
  • Establish governance, how decisions will be made. Clarify roles and lines of accountability.
  • Consider establishing an advisory board of users/contributors.
  • Develop outlines/wireframes/mockups & begin to draft content in order to solicit feedback & revise

Birth

Get it out to the community/network so they can begin to make use of it.

  • Release beta/first draft crediting contributors
  • Solicit feedback and revise
  • Follow-up with reviewers on how their inputs have been incorporated
  • Create an outreach plan to track and learn from usage
  • Identify appropriate licensing that will support reuse, modification, adaptations and forking.
  • Define evaluation metrics
  • Track usage
  • Collect and analyse use stories.

Infancy

  • Launch a first version
  • Review governance, roles and how decisions are made. Possibly rotate advisory board members.
  • Share with relevant communities/networks (not the one it was created for) and solicit feedback
  • Establish impact and benefit indicators.
  • Integrate feedback and revise

Youth

  • Analyse impact and benefit indicators.
  • Identify what is most useful to the community. Consider cutting least useful content.
  • Monitor reuse and modifications.

Maturity

  • Refine and refine useful content
  • Archive content that’s not useful.
  • Versioning

Death

  • Articulation of Purpose Fulfilment.
    • Is it being done better elsewhere?
    • Is there another/different effort that is causing this to have obsolescence?
    • Has the community/network moved on?
  • Agreement from beneficiaries on ceasing development
  • Management of closure process.
    • Archiving or put content into a repository

AfterLife/Rebirth

  • Supporting reuse, adaptations and forks in other networks and communities,