A brigade's Project Management Office

[Phil Wolff]

Brigades need more than github repos to support product and project lifecycles. We need an app that connects:

• Projects
• Teams
  • which may be associated with more than one project;
  • a project may have more than one team
• Products made through projects
  • Products may be related to each other (forked from; revived from; works with)
• Updates on project progress
  • Standup meeting updates
  • News and other blogged info
  • updates from github, trello, and other systems we use for activity tracking
• Things to do, help wanted, project roadblocks to work through
• Calendar of events
  • meetups, meetings, launch activities, sprints, parties, outside milestones
• PMO Handbook (wiki for how we do things)

Most useful as a mobile experience but should also be part of the web site.

[Greg Bloom]

Is this an app?

I often think about the need for a project template to delineate the fundamental elements (most of which you cover here; though I'd add that an essential and often overlooked element is a specified mechanism for asking/aggregating questions).

But while I often wish for an app that would do all these things, I also then argue with myself that it's accomplishable with a well-structured document (linking to various other documents and tools) and a rigorous practice of tending to it (probably sustained through the designation of responsibility to do so).

[Spike]

Noel is specing a system to manage most of this, it's a huge ask, but
common to us all.

Spike
openoakland.org
stealingbeautyphotography.com
@spjika
On Mar 8, 2015 10:12 AM, "greggish" [e-mail] wrote:

Is this an app?

I often think about the need for a project template to delineate the
fundamental elements (most of which you cover here; though I'd add that an
essential and often overlooked element is a specified mechanism for
asking/aggregating questions).

But while I often wish for an app that would do all these things, I also
then argue with myself that it's accomplishable with a well-structured
document (linking to various other documents and tools) and a rigorous
practice of tending to it (probably sustained through the designation of
responsibility to do so).

—
Reply to this email directly or view it on GitHub
#67 (comment)
.

[Andrew Hyder]

Is Code for Philly's Laddr close to what you're looking for?

Also, next Tuesday the 17th we're having an online discussion about minimum requirements most Brigades should have for their projects.

[Phil Wolff]

Is this an app?

@greggish it's the right question.

Yes. Let me share why I think so.

1. One data set, multiple views.
2. Scale.
3. Not a flat list.
4. IAM automation in our future.
5. Decision support.
6. future of brigades

One at a time...

A.
First, we want different views for different people and different user stories. Delivery leaders need a portfolio view of project status. Team leads need to see and edit a clean just-my-project view. Team members need to see and edit a burn down chart. People not on a team, looking for something to do for 20 minutes should be able to see the Help Wanted list across projects. Product managers should be able to help sequence work and, where teams work agile, slot them for sprints. Volunteers should be able to join a team or subscribe to updates.

People not on teams need to share project work with external stakeholders. The person doing fundraising should be able to pick 5 projects that represent different ways your brigade makes a difference, add language specifically for potential donors, and generate a showcase page tailored for sponsors. Same for the person who leads partner relationship and the person who works with the press.

Without a database, there's a ton of "manual labor" and friction in the brigade. The more friction we extract from the volunteer experience, the more people get done, the lower our churn, and the happier we all are.

B. Scale.

With six projects, not a problem for document or wiki page. Small brigades could find this overkill.

With dozens of activities and projects, the work multiplies. People who'd volunteer aren't finding out about ways they could contribute; and they're leaving before they get a few good experiences. Team members who miss a meeting or two find it hard to catch up and never rejoin their team. Our delivery leader couldn't just look and see a fresh list of active projects and their status. Members don't have an easy way to see the burn sheets of just their own projects.

C. Yeah. The data structure to do this is more than a simple list or spreadsheet.

D. When you join our brigade there's a bunch of signing up to do. We have to add you to google groups, slack, trello, meetup, github organization, etc. And when you join a project team, they'll have their own slack channel, their own trello board, google group, github repo, google drive, etc. Without some automation, provisioning accounts is slow, haphazard, and a barrier to slipping someone into the workflow. The same is true of deprovisioning when someone leaves. There are open source and commercial tools for IAM but they all need to know the people and what they're supposed to touch; which the PMO tool would know.

E. How do we lead without information?

Can we score projects on difficulty and see how our brigade is doing? Can we spot the behavior of potential leaders? Can we understand and explain how our project mix is serving our community? Or tabulate engagement statistics for fundraising reports? Can we find gaps in our skill set and actively recruit talent needed by the project teams? Could we compare similar projects to see why outcomes were different?

We solved these problems well enough when we had our first few projects. But how do you do this if, like Burlington you've dozens of projects or like Oakland you've had hundreds of volunteers through your doors?

F. You can't join OpenOakland without coming to a hack night and survivingcompleting an orientation. But what if you could? If you completed an orientation online, what would you need to participate virtually on a project the other 165 hours a week? Could we be open to homebound volunteers? Volunteers on extended deployments? People with time conflicts? They'd need to know what's going on in projects, the roles, the work, etc. And a PMO tool like this could make that possible.

thanks.