DRAFT COPY

Aligning Projects with OpenUp's Mission and Vision

OpenUp's Mission

To drive systemic change and innovation in local governance, in order to empower residents and government role-players to become active and collaborative agents in positive and sustainable development.

OpenUp's Vision

To inform and empower citizens through technology about how government systems work, while giving them the proper tools to engage with their government more directly.

What Impact do we want to have?

We want to create a vibrant civic data landscape in which residents and civic groups use data tools and civic tech to engage with government, and government becomes open, accountable and responsive to their needs.

How Projects Support Our Mission

What are the qualities that make a project align with OpenUp's mission and vision, and what are the metrics used to measure them?

‌OpenUp’s projects should allow the public to play an active role in society, and make a difference in terms of their needs. A project’s ability to address and achieve this is initially judged from the perspective of three key words in our core values: to Inform, Empower, and Activate. These broad segments form the basis of the metrics we use to assess potential project compatibility.

Inform

  • Are people informed?

  • What will we inform them of?

  • Why do we want to inform them?

Empower

  • How will what we plan to do empower our audience?

  • How will we give them the ability to actively interact with their environment?

  • How many people can use our tools?

  • How many people can access them?

  • Ultimately, what benefit would the information have? How much will a tool help or improve the circumstances of our target audience?

Activate

  • Who is our target audience? What kind of questions would they want answered?

  • How will we inform our target audience? What medium will we use to inform them?

In summary, a potential project would need to answer two questions:

  1. Does it create information that is accessible to and/or could be given to citizens?

  2. Does the project create tools that allow people to successfully engage and interact with government systems?

For example, making budget data open to the public allows them to stay informed of developments. By creating a tool that sits on top of the data that people can use, we empower South African citizens with the knowledge the tool grants them. This helps hold the government accountable.

OpenUp is not a grassroots organization. In our mission to make information available, we have to find the right partners and partner with the right companies.

*As a non-profit, how does the potential for profit influence the overall viability of a proposed project?

Adrian K: That’s something we’ve been tackling. Because we work with technology, we haven’t really articulated how to sell what we have to offer more effectively. With certain projects, there’s a client, and there’s a contract. We go out, and deliver on what the contract says. Through this, we generate a fixed amount of money. Luckily, both of my current projects have contracts. So I know exactly what the fixed amount will be, and what the client expects.

Secondly, I’d need to align the project with what OpenUp is about- in terms of our methodology, ideology, and three objectives. So far, we’ve been fortunate enough to do that.

With other projects, it’s quite different. There might not be a fixed amount provided or promised in the contract; the project might not be intended to generate income at all.

Evictions (the project) is a good example. The evictions project (that) Shaun was on. There’s no money coming in for services going out. Or for development, or project management. It’s basically an experiment with money coming in from a donor or from core funding, but the money wasn’t necessarily allocated for it.

And it becomes very tricky, because that particular project will end up taking time. It starts eating into the money and might take a whole lot of it, while running the risk of not delivering much.

--

My honest view: OpenUp needs to be very careful with what projects we take on board. We almost need to experiment with a time frame.

Next, we need to establish a clear cut off. At OpenUp, we usually try to make a project aim for maximum impact, instead of a relatively smaller impact that utilizes less resources.

I think...that we’re a non-profit organization. I don’t think our intention should ever be to look at or rely on a profit margin, or implementing a project with the view of making a profit.

I believe our goal should be to develop concepts and ideas that speak to our vision, which is to Inform, Empower, and Activate. And through that, we should then be able to gain a space within where we work, in terms of these three objectives. Not necessarily through making profit, but to actually gain leverage for our stakeholders and the key people in our space of open data, for them to come on board with us and say, “-”

We shouldn’t be looking at what we do as a profit making activity.

Documents and Checklists

What, specifically, are the documents and checklists required for a project to push through?

The first thing a project requires to push through the conceptual stage is a concept note or a proposal, These are used to ‘define what the problem is’, and what this project is attempting to solve- NOT by the tool we want to attempt to create. Building a concept note on the basis of preconceived tools or technology- like a website, or an app- is a good way to get confined by the boundaries of the tool in mind, limiting potential solutions.

  • ‘We want to build a website’ (wrong)

  • ‘This is the problem we are trying to solve’, and ‘this is how we can solve it’. (correct)

Implementation plans go into time frames that get broken down into digestible chunks called ‘sprint plans’. i.e. if a particular feature needs to be delivered, we align it to a Gantt chart or a project load map. These make it possible to develop small, mini-time frame plans. Within a bigger delivery of project features and a 12-month plan, two-to-three week plans are made.

Through the duration of this process, Google Drive is used to document everything. It’s common for the living minutes to get taken, most notably during project steering meetings. Project steering meetings give the organization opportunities to discuss what OpenUp needs to prioritize. This is all made possible through an Agile project management system, which allows time and schedules to shift once data is made available.

The last step is to partner with a committed domain expert- a process called stakeholder management. Typical partners are government citizen groups and NGOs- specialists on the issue at stake, with the ability to drive the project forward.

To Summarise: Internal Project Initiation Process- Steps and Documents:

  1. Create a Trello Board

  2. Create a project chart and checklist. The project manager will draft an initial concept note budget and a rough implementation plan. Formulate a cohesive proposal from the concept note. During this stage, we work to determine:

    • What we are doing

    • What we are trying to solve

    • Who are we doing it for. Note that is a very important part of the overall process.

  3. Stakeholder engagement begins.

Engaging Stakeholders

Engaging stakeholders will usually be one of the first stages of every project. It is important to know exactly who is involved, what their level of commitment is (financial and labour), and have clarity on roles within the project.

Read this entire section and then use the stakeholder checklist and Project Overview Document to make sure you have all the information you need to start a project.

*see Stakeholder Management, Project Implementation.

Desired goals and outcomes

What are the desired outcomes for each stakeholder? From OU's side you may want to create a concept note to explain how the project supports OpenUp's mission.

Resource Capacity

What capacity does each stakeholder (including OpenUp) have? Commitments should be made up front regarding how much time and money each stakeholder is able to provide. The project manager should keep each party accountable.

Defining Roles

Having clearly defined roles and communicating them to everyone is vital to a successful project. Knowing what people can and cannot do, will help you plan accordingly.

Common roles include:

Financial Implications and Responsibilities

Budgetary implications for each party must be expressed early in the project in order to plan efficiently. See Budgets & Finance for more information.

Time frames and time limits

Projects cannot run indefinitely. The client or partner may have some hard deadlines, but if they don't you should create your own in order to keep the project moving forward.

How long does the Project Initiation Phase take in relation to the rest of the project lifespan?

What needs to be considered here is 'how long do we want to do this for?'

The length of the Project Initiation phase usually depends on the circumstances the project was birthed from. A clear client with outlines intentions and set deliverables typically indicate a shorter initiation process. Fixed contracts easily expedite this phase of the project lifespan.

Otherwise- for projects borne from proposals and concept notes, that require OpenUp to engage possible users, participants, and clients- the initiation process easily takes two to three months, minimum.

Some projects never exit the initiation phase. A proposal or a concept note could be put together and approved, and still fail to leave the procedural planning stage. A common reason for this is a lack of funds- which is why the budget is the last item to be signed off. Sometimes the project incubates, or gets written off as a waste of time. This is why it's imperative to get to the decision-making stage as quickly as possible.

Is this project a revenue stream for OpenUp?

[Lailah, what are the implications here?]

Concept or Proposal

  • Why are you doing this project?

  • How does it align with OpenUp's mission?

  • What question(s) are you trying to answer?

  • What is your broad strategy for answering these questions?

Project Overview Document (P.O.D)

This document contains all the important project information and will give anyone reading the document a good overview of the the project; who is involved, what its trying to achieve and how its trying to achieve it. It is a very important document fro senior management and for new staff being on-boarded.

Budget

Every project needs a budget to gauge how much resources will be needed in terms of labour, staff time, and finances. Stakeholder engagement and the concept of the project should allow you to make a budget that can can be discussed and approved or rejected.

The Budget Process during Project Initiation

MOUs, SLAs, and Contracts

The information mentioned above should be complied into a Memorandum of Understanding (MOU) or a Service Level Agreement (SLA) or some other relevant type of contract or agreement. It is a formalisation of roles and commitments and sets out in writing clearly what each stakeholder has agreed to.

What kind of MOUs/contracts are worked up during the project?

Many projects birth clear contracts between OpenUp and the client- with deliverables, time frames, and an overall idea of what the budget might look like. Project managers are made aware that their ability to deliver on the features outlined will ultimately amount to a certain desired outcome.

On the administrative side of things, they create:

Templates

  • Find the MOU template here. [Doc]

  • Find the SLA template here. [Doc]

Add the stakeholders details to stakeholder database.

Product Management During the Project Initiation Phase

Jennifer Walker manages implementations on top of existing products. The products already exist (i.e. Wazimap), already deemed to be aligned to OpenUp’s mission.

For instance: Wazimap aligns with OpenUp’s mission by democratizing data, opening data, and acting as an intermediary to others. This means that when a new client wants to implement the product or a version of it, OpenUp already knows that the product alignment lines up with our company standards.

Jen W: Well, there are some points in this initiation section that we do. For instance, getting MOUs in place, and contracts in place, and getting the project set up within the organization. So making sure that it’s on the master project list, that they exist in Clockify so people can log their time in again. So there are still project initiation tasks that happen; they’re just not a full assessment and validation of whether or not we want to go ahead with this. That decision is typically made before it lands on my plate.

But then, I’m responsible for making sure that there is an MOU or a contract. That’s Trello. If we’re not using the Product Trello board- and sometimes we do, sometimes we don’t- that there is Trello. Ideally, some of those projects should also be getting a Project Overview Document (POD). Sometimes, an additional Slack channel is required; sometimes not.

Living minutes documents, most of them get their own living minutes.

Logframes? I’ve never worked with.

And then, Budgets. Ideally, one day in the future, we will work with budgets, but at the moment, because we’re doing- sorry, my frame is very Wazimap-specific at the moment- but because we’re doing a rewrite of the base product, at the same time as implementing a whole bunch of products for different clients. The clients have a budget, but the base product doesn’t have a budget. In an ideal world we would have budgeted and would be kind of working towards that. So right now there isn’t a product budget sheet, but there are project budget sheets. So projects are instances of the product, like Youth Explorer, like Vulekamali, Wazimap, Instance, like GCRO. And um, there are a couple more.

K: Okay. So, what specifically are the documents and checklists required for a project to push through? What do you currently do?

J: I currently find the proposal, or the initial proof of concept note that Adi or Lailah typically puts together. From that is figuring out resourcing- so finding out who within the organization is going to be working on the project. I will populate backlogs, so that’s a lot of requirement solicitation, either from the concept note or the proposal. As well as talking to client stakeholders and internal stakeholders.

My biggest tool that I use for managing projects would be Trello. In the case of PMG (?) I use Pivotal, but that’s slightly different. So Trello is where we house all of our requirements and move them through the Implementation workflow. So the workflow I use in “incoming,” which is untriaged into backlogs, which is prioritized. And then it moves to “in-progress,” ready for review, or- oh no, sorry. “PR,” ready for review. At that point I test, and either put it back into the backlog if there are issues. If I accepted, I’ll move that card into “done.” That’s kind of like how things flow through Implementation.

What should be accompanying that is some form of documentation- describing “what it is that we’re doing", or “why it is that we’re doing it”- that is being earmarked for the POD. I’m trying to move all my documentation into Gitbooks, because it’s just a lot easier to use and to have it consolidated in the same place.

Manuals and instructions like that for clients and for users, I create in Gitbook too, so that’ll be a public face in Gitbook that they can access for “how to" use, or how to do what they need to do on the system.

What I need to get into doing- and it’s a big kind of flag in my mind at the moment- is creating product mailing lists. So everyone who has a version of that product would be on that mailing list, that I can do major release, sort of chainsaw (?) updates to, because this is a constantly improving product and system. When we do big releases, it’s necessary for us to do the communication around it as well.

Something I’m very remiss in is communication from a social media point of view, or blogging. I’m not doing any of that currently, but it should happen- both on the product, social sort of properties; Wazimap, for instance, has it’s own Twitter account. That should be used, but I should also be blogging on the OpenUp platform about new changes and about what’s happening.

J: At the moment, I’ve really had to prioritize getting work out, and “functional” work versus “important” work as well. Like, I don’t dispute that the communication on the social side is not important, it’s just- it’s not as urgent as the other work right now. So, it’s something I need to circle back on.

J: Okay, so “how long does Project Initiation take in relation to the rest of the project lifespan?” Difficult question for me because I don’t necessarily know when it starts, but my parts of it are kind of getting tools in place, and everything set up is pretty quick. That’s probably, ah-

I don’t know, ten to fifteen percent of the total lifespan? Maybe less?

Close-out for me, is- I think Adrian is the one who probably has the most specific closeout tasks, given the government work he does, and I know that’s a big government requirement. Close-out for me would be doing things like reconciling budgets, would be any sort of points that haven’t been- any backlog items, because we work in a time box or a budget constraint, ideally.

Um, process? It would be any of the requirements that haven’t been able to be done, kind of making sure that those are parked in a backlog for potentially revisiting in the future. And then also doing things like retrospectives.

PreviousProduct Management during the Project Initiation PhaseNextProject Implementation

Last updated