Low hierarchy project management

Low-hierarchy project management within our organisation Design Action Collective and Coko Foundation

Started with the Design Action example:

We used to be small and everyone would handle the whole process. But we were growing a lot.

Gunner said start with what makes your org important, rather than look to other organizations’ best practices for project management.

We brought in an external facilitator so that everyone could focus and participate. Entered into the process.

Thought maybe one of us needs to be the project manager. But then no one (of the designer/developers) wanted to be the project manager.

Mitigate that hierarchical relationship by distributing the task managing more evenly (we tell each other what to do)

Mini retreat. 2-3 hours. Kieran did preparation and followup work. Facilitator had worker owned cooperative experience. So made a list of recommendations out of the group session.

We looked at the jobs were we doing & the roles (development, design, project management) and found we were doing 5 roles at once, some people wanted to pare them down, to specialise, others preferred to do everything.

Decided we needed to come with shared tools & how we were going to use them

How to deal with projects that stalled & came back. A few things to work with. Started by changing those elements of our processes. Got to a better place, miles from where we were. Time spent on PM is reduced, with an effective tool and expectations of coworkers being aligned.

We decided we’d use a template and basecamp for every project. I can go to the project and expect to see the elements in the same places. E.g. Put your feedback in this one place, so everyone knows to look there for it.

Markers: Clearer expectations. Easier to pass of projects, e.g. if someone gets sick or has a problem. If you need to excuse yourself, you can pass it to someone else. It’s much less painful. Less fights between us.

Passing baton works better, less blaming.

Workflow is good but not perfect.

E.g. When you send out an estimate, and then additional features are added in, and expectation is we share all the files with project manager and developer before going to the client. To confirm what you designed isn’t changing scope, is within the estimate.

Shield the developer from getting into conversations with the client of additional features: “Yeah I can do that.” ;)

Design phase vs boiling down all the elements that it will contain. Enumerate the list of requirements that are required?

Collaborative Knowledge Foundation:

Meet with clients, design as simply as possible, thinnest slice of what’s needed.

One design session, take it back, create design brief of all core functionalities that needed to there, then have a video meeting with the designers and the developers.

Talking through the already existing document. Talk through it. Sit & think & speak. Enumerate very clearly what the requirements are for each specific step.

Make sure everyone is on board. Rather than capture all requirements at the front/beginning; do it throughout the process.

12 things not to do during a design review — medium.com. Savvy advice, says Grant. https://medium.com/@monteiro/13-ways-designers-screw-up-client-presentations-51aaee11e28c Example: Don’t ask them if they like it.

Scott: It’s always going to expand…

What are set in stone, what are goal posts and then we want creativity for developers and designers… where to leave that space.

What about when your projects are so different, and you can’t create one template, or you have to create lots or have exceptions? DAC has a lot of repetition, same things, clients have similar needs.

You can try to set up the template to have everything possible, all the standard things, and then it’s easier to hold back from (rather than add to). But it’s helpful to have similar client needs/projects.

Project management tools? Issue/bug trackers?

• Caveat: It’s not that one tool is great. It’s way we use it, not the tool itself, that makes it effective.
• Basecamp. Works. But you have to pay for it (over a small # of projects).
• Mantis. You can self-host or use a hosted one.
• Redmine (OS). You can self-host or use a hosted one.
• Gerund (not open source but do give away free licences).
• GitHub.
• Zenhub goes on top of GitHub and adds useful things to the tracker. Not open source but free to use for nonprofit projects. Have to pay for private internal projects. Very useful.
• Asana… you can do a lot of easy stuff without great technical knowledge.
• Trello (Kanban)
• Wekan (OS) — For those who like to host everything themselves. Several people here use it.
• Jira

Q&A

When you need various templates? Working agreements are a thing. Tasks we know are a thing. But, how to get that group agreement? Team check-ins, retrospectives, you can propose working agreements as you go. Simple lightweight social convention for making adjustments between team members on how everyone has to work. You don’t have to figure it all out in advance.

How to record these things? Documented policies, manuals. Use a high level template — we know we’re covering all the things we need to know when we decide — then scale it down as we can. Identify what the basic components are that are shared across all projects. Standardise that you record it some place. You know where to get it.

What about pro bono work? How to keep an eye on it? We have yet to find an answer for. We come to our decisions together as a collective. We decide we’re going to work on this 50 hours, stick to that. If it goes beyond, have to bring it back to the group. When it’s a shared business, we’re all looking at our collective finances. We have to all trust each other. That we’re working for the same goal.

Hours not milestones? Try to estimate the amount of time that something is going to take. As a project manager, learn to say no. Keep the scope tight.

What other negotiation tools when talking about scope? Give them a week. Make the group prioritise what things can get done within the week, make the tougher decisions.

You can work towards a minimum viable product. Another way to do it. Whenever there’s a new feature that comes up, does it meet that criteria. A multi-phased approach, too.

---

David — Whenever you add structure, you lose flexibility. E.g. Kanban is more flexible than Trello. Or dispense with all of that and use Slack. ;) Pin them to the channel. Mattermost = OS version. And pretty. But can be good to have a structured format. Keep consistency between projects. All about the expectations. It has been key to have the set structure. And know where to find different things. Or use GitHub for structure. Turn GitHub into Kanban using Poo (sp?) or GitHub itself does that… Redmine lets us customise and grow per project, choose a tool that allows flexibility as you grow your process

Contradictory truths of PM: 1) it’s everyone’s job to be a good PM, but 2) it’s usually good to delegate project leadership to one person, someone who’s taking point on certain responsibilities. How do you balance those two aspects?

Everyone takes responsibility for tracking/maintaining the project, but the PM takes ultimate responsibility

Particular tasks for particular roles, e.g. PM does budget and sets up the project, designer does the design brief

Write down a list of all the tasks the PM should do.

Flexibility versus structure. And the social conventions. The way developers use when you want to track every single bug etc, versus high level project managers use project management tools. You could have two: One board at 10000 ft for higher level thinking, versus one at 10 ft.

Everything has to be logged in the task manager or else it doesn’t exist. Vs higher level stuff (where not every detail have to be there).

Mantis can be good for client-facing stuff. Clients can use issues. Redmine is where we have all the detail: time and task tracking, stuff that would just be noise to the client.

Alternately, Redmine can be bigger buckets. Bigger things, hours, what work agreement a task is timed to. Mantis can be real issues that can be assigned to someone, finish the issue, close it.

Technically all these things can be done on all these platforms, but you can split it up logically. And that can work really well. (Murmur of agreement.)

Client perspective: We use Mantis, so we don’t need to email them every time something is bugging me (Civi on Drupal). It’s filed, it’s there, we can talk about prioritization later.

Agile. Several people here find it very useful. Software development philosophy. Structured/designed to build in tensions. Classes and certifications available. It’s a bit cultish.

Philosophy of developing projects… scrum masters, scrum ceremonies… what’s going to be done in 1-2 week period… make sure people who are doing tasks don’t get blocked (sequential tasks) … project manager’s job is to create and prioritise the tasks (e.g. features) … project owner wants to build as much stuff as they can, while scrum master wants to keep the development team working well. It’s an important tension. Make sure people are clear on those roles, and maintain the tension.

But the differentiation of labor can get hazy, e.g. documentation. Means we need to refine our processes. But it’s a very different framework from the client-deliverable stuff.

For larger projects… scrum role, PM role, product manager… tensions are key (echoed in room). Keep each other in check. Checks & balances.

How do people handle their project check-in meetings, so they don’t last forever? Internal teams.

Scrums can be amazing process. Stand up 10-15 minute meetings in the mornings. Then pair off for other collaborations. Work cycle.

What about tasks you don’t work on every day, not on the front burner? We can get in trouble. We have to go through our whole client list, so something doesn’t drop off.

Mattermost/Slack could help with that… You might not need a formal review, if you have that running updated conversation.

If you have a group in which teach team member managers a project… how do you have those guys check in with each other, e.g. I’m going to need Mark to do X and Y at Z time, checking in with each project, is he available?

RAD does a weekly overview at the beginning of the week. List the projects. Have a master list, and the project manager can raise projects that the individual doesn’t mention having specific tasks for, a good reminder / catch net. If there’s deeper discussion, you can do that later (that day, or next day).

You can also have 3 stand ups in one day, if you have different projects going on. What are you doing, what are you doing next, is anything blocking you from that next task? Then address that block. Recipe.

Any other tools for the client-facing? Done done has worked really well for someone. Also, many of these tools can be client-facing. Depends on the client. How much do they need to see. Decide based on that. Filter out the noise. Help the client use it without overloading them.

It’s not about the tool; it’s about the agreement to use it. :)

And tomorrow…

What happens when the expectations aren’t met…

The saga continues.