Product Management during the Project Initiation Phase

Product/Project 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.